Feature planning

Use this skill before substantial implementation or when a request spans several components.

Procedure

1. Read the applicable AGENTS.md files and inspect the repository before proposing work.
2. Restate the requested outcome as observable acceptance criteria.
3. Identify affected boundaries: modules, services, browser surfaces, public APIs, protocols, schemas, migrations, security boundaries, and repositories.
4. Separate facts discovered in the codebase from assumptions that still need confirmation.
5. Build a dependency graph. Mark tasks as parallel only when they do not require concurrent writes to the same files/branch or an unresolved upstream contract.
6. Assign the smallest practical role to each task.
7. Define validation for every task before implementation starts.
8. Identify which independent review gates apply.

For a changed public or cross-component contract, read contract impact. Include documentation ownership and checks in the task graph. Sequence documentation attributes and runtime edits to the same source file.

Output

For delegated work, include a finite dispatch allowance covering required gates, at most two active children, at most two correction rounds, and run/attempt deadlines. One coordinator owns plan changes; freeze the plan for an evaluation run. See bounded coordination.

Produce a concise plan containing:

• goal and non-goals;
• acceptance criteria;
• affected boundaries;
• task IDs, owners, dependencies, and expected artifacts;
• worktree/branch ownership for writers;
• validation and review gates;
• unresolved assumptions and material risks.

For a consequential design choice, retain the decision, reason, supporting evidence, and conditions for revisiting it. Use the consuming repository's existing decision format; routine work does not need a new document.

Do not invent cloud services, containers, databases, frameworks, or dependencies merely to make the plan look complete.