feature-plan

name	feature-plan
description	Phase 1 of the feature flow, standalone: the plan gate (the plan is the spec). Use when the user says /feature-plan, "plan this feature", "spec this out", or wants a plan gate without committing to the full flow. Not for building — that is /feature-build.
argument-hint	[feature description]
allowed-tools	Bash(git *) Bash(gh *) Bash(pnpm *)
model	inherit

The plan ✋ — spec and plan, one gate

One document, the plan: it is the spec and the plan at once. Seed from $ARGUMENTS or the conversation, then work the steps in order.

1. Preflight

• Read AGENTS.md + the .claude/rules/ files for the areas the ask touches.
• The slice comes from the user's ask — never self-served from the backlog issue list.
• Scratch lives in .feature/ (self-gitignoring: mkdir -p .feature && printf '*\n' > .feature/.gitignore).

2. Clear the thinking — before any drafting

1. Invoke first-principles-thinking seeded with the raw ask first — this phase's thinking gate, not optional. It strips the ask to its load-bearing problem and the minimal rebuild; its concluded action IS the confirmed ask.
2. Still rambling / multi-directional after that → interview one question at a time, each with your best-guess answer attached, until the ask is coherent.
3. Direction still genuinely unknown → idea-refine (save-path override .feature/).

These are conversations, not sign-offs — the ✋ gate in step 5 is this flow's only approval gate.

3. Plan the slice

3a. Consider approaches — internally, present none

1. Weigh 2–3 candidate approaches through four lenses: risk-first, YAGNI-minimal, vertical-slice, verification-first.
2. Big/architectural slices → run the lenses as 3–4 parallel sketch-agents; smaller slices → weigh them inline.
3. Decide the single best approach yourself. The alternatives are how you choose, not what you present — they never enter the final plan. Sketches die here.

3b. Draft your plan — inline

Authored right here in the chat, inheriting the session's model; never delegated to a subagent. Before writing, read every file the ask touches and Grep for callers and contracts rather than guessing; never propose anything a hard guard forbids. Your plan:

• Definition of done, up top — summarized however reads clearest: a short paragraph, a bullet list, or both. This is the slice's contract; feature-ship's triage measures every "fix now" against it.
• Only the decided approach — the plan, not a menu of options.
• In scope / Deferred split:
  1. Everything the user asked for together is in scope — multiple asks in one breath (a minimal UI tweak and a major schema change) are one slice on one branch, not a forced split.
  2. Deferred is only for work that is a substantial related slice in its own right, genuinely better built after this one lands — not a catch-all for incidental additions.
  3. Incidental "while we're here" ideas the plan itself surfaces (not asked for) → drop or note for backlog; never inflate the slice.
• Build steps for a zero-context engineer: file map first; bite-sized tasks with exact file ownership + interfaces + the .claude/rules/ skills each implementer must invoke (feature-build copies them into briefs); full code in non-obvious steps; NO placeholders. Split tasks only where a reviewer could reject one and approve its neighbor.

4. GATE ✋

Paste the full plan into chat (never a file pointer). Revise until the user's explicit go. On approval, pipe the approved plan — exactly as pasted — into .claude/skills/feature/scripts/start.sh "<feature name>" on stdin (heredoc; no file argument): cuts ft/<issue#> from clean main, opens the issue with the plan as body (capture the issue number — its only stdout line). The issue is now the single source of truth.

Rules: scope freezes at this gate. Planning docs never enter the repo — the issue body is the record.