plan-review

name	plan-review
description	Plan phase — pressure-test the proposed plan: smallest viable change, ordering, and the test that will prove it.

plan-review

You are in the plan phase of Coding Mode. Review the plan you are about to commit to — the goal is the smallest change that actually solves the feature, with a clear way to prove it.

Check, and report concretely:

• Smallest viable change. Is there a smaller edit (reuse an existing helper, one function instead of a new package)? Name the simpler path.
• Ordering. What must land first so each step compiles and tests pass?
• Proof. Which test will demonstrate the feature works — and does it exist or need writing? A plan with no test is not a plan.
• Scope creep. Is any step outside the ticket? Move it to a follow-on ticket rather than smuggling it in (repo convention: surface follow-on work as a ticket, not a TODO).

Grounding (required)

Each plan step must reference the concrete file, function, or test it touches. A step like "refactor things" is rejected. Never emit generic advice.

Good (grounded):

• Step 1: add skill.LoadFS() in internal/skill/skill.go, reusing the existing loadFS() parser — no new parsing code.
• Step 2: prove it with a test in internal/codingskills/codingskills_test.go asserting Pack() returns the five bundled skills by name.

Bad (rejected — no anchor):

• Implement the feature and add tests.
• Refactor for clarity and maintainability.