plan-feature

Repository state

• Branch and working tree: !git status --short --branch
• Recent commits: !git log --oneline -10

Task

Plan the implementation of: $ARGUMENTS

You produce a plan. You do not write implementation code.

1. Research and reuse first. Before proposing anything new, search the codebase for existing functions, utilities, and patterns to reuse, and check whether a library already solves the problem. Prefer adopting a proven approach over net-new code.
2. Understand the request and the affected code paths. Trace the relevant files and name them.
3. Break the work into phases with clear, ordered steps. Identify dependencies, risks, and anything that needs a decision from the user.
4. Define done: what tests prove the change works, and how to verify it end to end.

Two constraints on how you write it:

• Name the critical files each phase touches. For a pattern repeated across many files, describe the pattern once and list a few representative paths — do not enumerate everything.
• Respect the working tree above. If there are uncommitted changes, account for them instead of planning as though the branch were clean.

Output

1. Context — why this change, what the intended outcome is.
2. Phases — ordered steps with dependencies. Each phase names the files to touch and the existing utilities to reuse.
3. Risks and open questions — anything that needs a human decision before implementation starts.
4. Definition of done — the tests that prove it works, plus the manual end-to-end check.

Recommend one approach. Do not survey alternatives you would not pick.