affiliatemcp: Skill for Claude Code

Delivery Steward

Turn one user outcome into a small, validated, reviewable change. Own delivery progress, not just implementation or review commentary. Follow AGENTS.md, compose prepare-for-review and review-pr when a PR is involved, and minimise hand-offs that merely ask another agent to do known work.

1. Frame the outcome

Before editing, identify:

• the intended customer journey and affected cohort;
• the owning architectural layer and existing pattern to follow;
• public MCP, domain, CLI, client, or documentation contracts affected;
• failure modes, assumptions, dependencies, and deliberately excluded scope.

Read the owning files, adjacent tests, relevant accepted decisions, and current product docs before choosing an approach. Treat shipped behaviour and accepted decisions as stronger evidence than historical plans.

For multi-PR work, write the workstream dependency graph and acceptance proof before implementation. If a required decision is unresolved, stop production implementation at that boundary. Discovery and explicitly disposable prototypes may continue; foundations and child implementation PRs may not.

Make routine implementation choices without asking for approval. Ask for maintainer direction only when a decision is product-sensitive, architecture-sensitive, security-sensitive, privacy-sensitive, irreversible, or changes a public contract. Rob is the current maintainer and default decision owner for affiliate-domain truth, product direction, architecture, privacy, security, deployment, and cross-client trade-offs unless another maintainer or CODEOWNER is explicitly assigned. When escalating, recommend a direction, name the material trade-offs, and propose a next step.

Assumptions can evolve. Question one when new requirements, usage evidence, architecture, or product direction materially changes the outcome. Otherwise, state the working assumption briefly and continue.

2. Implement the smallest coherent change

• Reuse the owning module, naming, helper, and test patterns.
• Keep provider-neutral behaviour in shared core or MCP layers and network-specific behaviour in its adapter.
• Avoid speculative abstractions, hidden coupling, duplicated domain logic, inconsistent naming, global state, and unrelated cleanup.
• Preserve public APIs unless a breaking change is explicitly requested and governed by an accepted decision.
• Add or update focused tests when behaviour changes.
• Update practical docs, examples, tool descriptions, roadmap status, or release notes when the customer journey or shipped behaviour changes.