kickoff-phase

If your tooling has a plan mode, enter it now and stay in it through the investigate-and-confirm steps below — no edits until I approve. Recon prompt-hygiene (plan mode prompts on any shell it can't prove read-only): prefer the dedicated read tools (Read/Grep/Glob) over shell; keep shell recon to plain single-purpose read-only commands — ls/cat/grep/git log and simple chains of them auto-approve via the bundled plan-mode hook — and route loop-heavy sweeps through read-only sub-agents, so I'm not walled with permission prompts. Read the plan at the path in $ARGUMENTS (and any roadmap/README it points to) in full. Implement only the named chunk.

Before writing any code, interview me — but interview SHARP. Re-verify the plan's claims for this chunk against the actual code (the code is ground truth; the plan is a snapshot) — and confirm any external framework/SDK/CLI setup against current docs (Context7/web), not memory. Then split the open decisions into two kinds and handle them differently — never quiz me on something a senior engineer would just decide:

• Engineering calls → DECIDE and proceed (don't ask). Anything settle-able from the code + best practice: route/file/module placement, data shape, library choice, error handling, where logic lives, naming, API surface. Make the call a senior software engineer shipping a production app would make — industry-standard, durable, correct; never an MVP / prototype / temp-workaround unless I explicitly asked for one. State the decision + a one-line rationale and move on. When two options trade off, first check whether the best answer combines them — don't present a forced either/or that hides a superior unified design. Escalate an engineering call to a question ONLY if it's genuinely hard to reverse and you're truly torn, or it secretly carries a product/cost choice.

• Judgment calls → ASK (batched, ONE AskUserQuestion round). Only what needs my preference, priorities, or authority: product/UX behaviour, scope or priority trade-offs, cost/vendor choices, anything with a business dimension, and steps only I can do (credentials, dashboards, go/no-go). Don't invent constraints — name the gaps. Phrase every option OUTCOME-FIRST — the user flow, how it feels, the real-world result (upload speed, drop-off, conversion, cost) — THEN append a one-line technical note in parentheses for technical users (the mechanism / trade-off). Lead with the outcome, never the jargon: "uploads feel instant but cost a little more (optimistic client writes vs server-confirmed)". A non-technical owner decides on the outcome; a technical one still sees the how. I decide on outcomes; the code is yours. Label each option's authority — "In plan" / "Engineering alternative" / "Out of scope" — and flag any MVP/temp-shortcut option as a shortcut (never present one as co-equal with the production-grade choice). Don't mark "Recommended" anything that contradicts the active plan.

Follow the plan; auto-defer (and record in the plan) any in-plan item that won't fit the session budget and regresses nothing — don't ask, just log it. Don't re-decide what the plan settled. If the plan's approach is wrong or a genuinely better architecture exists, say "recommend changing the plan" and cite the exact line. Batch every real question into one round; proceed on your own production-grade judgment for everything else.

Once I answer: present the concrete approach for this chunk — with an executor named per workstream (builder/codex/runner/main-loop, per my CLAUDE.md roles table) — and get my approval to exit plan mode (ExitPlanMode). Only then implement on a dedicated branch, routing each workstream to its named executor: the main loop DRIVES, delegates TYPE. Keep on the main loop only taste-carrying (UI/copy) or genuinely interdependent pieces, one-line justification each; announce every offload (→ codex: <what> / builder spawn) as you dispatch it. Not delegating a workstream the plan routed away is a plan deviation — say so out loud. The brief always feels more expensive than it is; typed code is re-read every turn forever. Exiting plan mode authorizes EDITING, not committing — get my explicit sign-off before EVERY git commit and EVERY push (pause and summarize what you'd commit each time). Then prove it by running it, not by reading the diff — use /verify to confirm the chunk behaves as intended and /run to boot and drive the live app, whenever the change is actually runnable (pick what fits: pure logic → /verify against a test; UI/API → /run + a real browser/curl pass). Review per the owner's CLAUDE.md review ladder — default ONE fresh-eyes pass; the full battery only for dangerous diffs.