plan

/plan: from idea to build-ready work

Input ($ARGUMENTS): a feature or project description, however rough.

Outcome: a plan the user has explicitly approved, expressed as right-sized, build-ready tasks the inner loop can consume one at a time. The quality bar is high on purpose: first-pass quality is the dominant predictor of loop output (see docs/DESIGN.md), and the spec is where first-pass quality is decided.

1. Understand before proposing

Interview the user, as many rounds as it takes, until you can state without guessing: the goal and why now, the user-visible behavior, constraints (stack, compatibility, performance, security), what is explicitly out of scope, and how success is verified. The plan must be grounded in the codebase as it actually is, not as assumed. Challenge vague answers instead of absorbing them: "proper auth" is not a requirement; "email+password login with session cookies, no OAuth yet" is. Surface the decisions the user hasn't realized they're making.

2. Propose, then iterate to approval

Present the plan: approach, decomposition, ordering with dependencies, and open risks. Iterate until the user explicitly approves. Create nothing before approval.

Size tasks by cohesion. One task is a chunk an implementer can carry to a coherent, finished state and a human can still review in one sitting; it leaves the app releasable and is verifiable on its own. Splitting costs a spec, a branch, a review loop and a merge, and the seams are where incoherence enters, so a split needs a reason — typically:

• a hard dependency (one task's output is another's input),
• a risky unknown worth landing on its own, so it can be judged or reverted in isolation,
• a diff a human could no longer review honestly in one pass.

A coherent surface — a page, a user flow, a design system, a resource end-to-end — is the natural unit: build it whole while the diff stays reviewable. Slicing a UI by section is the classic failure, five PRs that each pass review and together look like five different products; when a surface genuinely outgrows one task, split it so the design is still decided once — its foundation lands first and later tasks conform to it.