# Nuke Plan > Use when the user wants a plan they will implement THEMSELVES, ticket by ticket, in fresh sessions with cheaper or local models — "nuke plan", "plan this for me to build", "write me the tickets", "JIRA-style plan", "I'll implement it myself" — a human-readable plan folder written through an interview, handed to a second-vendor critic by hand, and closed by a verification handoff the user runs in an independent session; never executed by agents. NOT for delegated execution (nuke-spec → nuke-exec) and not for a change the session builds itself (nuke-sprint / nuke-blitz). - Skill: `b4r7x/nuke-plan` (Agent Skill, multi-file: 6 files) - Install (CLI): `npx skillmds@latest add b4r7x/nuke-plan` - Raw SKILL.md: https://api.skillmd.com/api/skills/b4r7x/nuke-plan/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: b4r7x (https://skillmd.com/u/b4r7x) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/b4r7x/nuke-plan --- # Nuke Plan The human-led lane (map: references/family-map.md). The pipeline assumes an orchestrator fans work out to agents; this lane assumes the user does: a strong session writes the plan, a critic on another vendor reads it, the user runs each ticket in a fresh session on whatever model they choose, and an independent verifier session closes the loop — proposing fix tickets, never editing code. So the plan is written for a person first — a board, tickets, decisions with their rejected alternatives — and for a cheap implementer second: every ticket names its files, what to read first, what to do, and a check that proves it done. A helper like nuke-split and nuke-pilot: no preflight gate, no cost band, at most one agent (a clerk recon scout). It never implements, never spawns waves, never runs another CLI. ## Arguments `` — inline description, or a notes / issue / PRD file → new plan `reconcile ` — fold `critique.md` (plan critique) or `verdict.md` (verification report) into the plan: accept / reject / ask; verification fixes become a new "Fix round" phase of tickets `resume ` — continue an unfinished plan from its first missing step ## Mandates 1. **Read-only on the codebase.** Writes only under `.nuke/` — the run directory plus the shared `.nuke/repo-map.md` and `.nuke/calibration.log`. Never `git add`, `git commit`, or `git stash`. 2. **Never implements, never spawns waves, never invokes another CLI.** The critique and the verification are the user's manual steps by design — the handoffs are pasted by the user; the skill never runs them. 3. **The interview is never skipped.** Only the user ends it early ("enough, draft it"); every unasked question becomes a listed assumption in plan.md. 4. **Every ticket runs in a fresh cheap session** holding `context.md` + that ticket alone: named files, read-first pointers, a runnable Done-when. A ticket that needs the planner's memory is a planner bug. 5. **Artifacts speak the user's language** — the language of the interview. Identifiers, paths, commands, and code stay as in the repo. `review-handoff.md` and `verify-handoff.md` are English. 6. **Main context stays thin.** Consume `.nuke/repo-map.md` when present; read what the plan needs, never the whole repo. 7. **Fresh run_dir per plan:** `.nuke/--plan-/` (local 24-hour clock); if the path exists, append `-2`, `-3`, … until `mkdir` succeeds. `reconcile` and `resume` write into the run_dir they are given. ## Artifacts Formats, skeletons, and the ticket template: references/plan-format.md — read it before Phase 2. | File | Reader | Role | |---|---|---| | `plan.md` | the human | goal, non-goals, REQ-###, decisions D-## with the rejected alternative, the **board**, phases, the interview verbatim, assumptions, how to run the plan, changelog | | `context.md` | the implementing model, first | project, conventions, gates table, target architecture, contracts, REQ list, the seven rules for the implementing session | | `tasks.md` | model + human | tickets in execution order: Why · Read first · Do · Shape · Don't · Done when · Evidence | | `review-handoff.md` | the critic | the English plan-review request + optional read-only one-shot commands | | `critique.md` | pasted by the human | the critic's raw reply | | `verify-handoff.md` | the verifier — an independent session after implementation | the English verification request: REQ coverage, every Done-when re-run, gates, missing, defects, optional "better"; output = verdict + fix tickets | | `verdict.md` | pasted by the human | the verifier's raw report | | `review-log.md` | the human | per round, critique or verification: finding · accept / reject / ask · reason or change | ## Pipeline ``` Phase 0 research → Phase 1 interview → Phase 2 draft (nuke-think) → Phase 2.5 walkthrough → Phase 3 handoff (STOP) reconcile : critique.md → accept / reject / ask → review-log.md · plan v+1 (STOP) verdict.md → accept / reject / ask → fix tickets (Fix round N) · review-log.md (STOP) the loop the human runs: tickets in fresh sessions → verify-handoff.md in an independent session → verdict.md → reconcile → … until VERDICT: VERIFIED ``` ## Phase 0 — Research 1. **Resolve the feature source:** inline text, or read the given file. Neither resolvable → ask the user and wait. 2. **Map the area.** `.nuke/repo-map.md` present → consume it. Absent → one `clerk` recon scout (tier vocabulary: references/model-tiers.md; it gathers stack, manifests, instruction files, the per-path-prefix gates table per references/stack-adapters.md) — the only agent this skill ever spawns. 3. **In-session reading:** the instruction files; the code the feature will touch; **the closest existing analogue** (same layer, same pattern) — these become the tickets' "Read first" pointers; the gates for every touched prefix. 4. **Print one paragraph:** *what I understood you want · what I found that shapes it · what I will ask you about.* The user corrects the premise here, before any question is spent on it. ## Phase 1 — Interview The rules are the deliverable; a plan tailored to the user is what makes it theirs. 1. **One question per message.** Wait for the answer. 2. **Every question is a full paragraph**, in this order: what I found in the repo that raises it (file:line or the fact) → why the answer changes the plan (what gets built differently) → 2–4 options, each with its consequence in plain words — what you gain, what you pay → my recommendation stated first, with one reason. 3. **No jargon without a gloss.** No yes/no question without saying what "yes" commits the plan to. 4. **Never ask what research can answer.** Never two things in one question. 5. **Stop when the plan is determined** — typically 4–8 questions. "Enough, draft it" ends the interview at any point; the unasked questions become `## Assumptions`, each with the answer assumed. 6. **Answers are recorded verbatim** in `plan.md › Interview` (Q → A), so the critic and the implementing model read the user's intent, not a paraphrase. 7. Claude Code: AskUserQuestion, each option's description carrying its consequence. Other CLIs: print the paragraph and wait. ## Phase 2 — Draft Load **nuke-think** when installed — cutting a plan is a judgment role. Read references/plan-format.md and write `plan.md`, `context.md`, `tasks.md` to its skeletons. Ticket sizing: one concern ≈ one file as the target; the ceiling is the worker row of references/fix-spec-template.md rule 8 (≤3 files, ≤~1.5 KLOC touched-file mass — measured with `wc -l`, never estimated); multi-file only where a seam forces it (contract before consumers; definition with its test). Every Done-when follows the Accept patterns in references/fix-spec-template.md plus the gate rows for the touched prefix. Then the self-review checklist, fixed inline: every REQ-### covered by ≥1 ticket · every ticket has Read first, Do, Done when with a runnable check · no ticket over the ceiling · no ticket depends on a later one · non-goals explicit · every D-## carries its rejected alternative · no placeholder text · language rule respected · the seven implementing-session rules present in context.md. ## Phase 2.5 — Walkthrough Print the board in chat — phases, one line per ticket (`T-004 · wire backoff into poll loop · 1 file · depends T-002, T-003`). Ask ONE question: *does this cut and order match how you want to work through it?* Apply the answer (merge, split, reorder, drop), re-run the checklist, continue. ## Phase 3 — Handoff (STOP) Write `review-handoff.md` and `verify-handoff.md` per references/plan-format.md, and record `base: ` in plan.md's header — the verifier diffs the implementation against it (reading git is fine; Mandate 1 forbids add/commit/stash only). Both handoffs reference the run_dir files rather than embedding them, so they stay current through reconcile rounds and added tickets. Append the calibration line to `.nuke/calibration.log` (` · nuke-plan · REQ / tickets /

phases · interview questions · 0–1 agents`). Print, verbatim: > 1. Open a session in another harness (Codex / Gemini / ChatGPT / …) in this repo. > 2. Paste `/review-handoff.md` — or run one of the commands at its bottom. > 3. Save the critic's full reply as `/critique.md`. > 4. Run `nuke plan reconcile `. > Or skip the critique and start: a fresh session, *"read `/context.md`, then do T-001 from `/tasks.md`."* > After the last ticket: paste `/verify-handoff.md` into a fresh, independent session, save its report as `/verdict.md`, run `nuke plan reconcile ` — repeat until `VERDICT: VERIFIED`. (Agentic alternative: `nuke verify intent: `.) Stop. Never start implementing. ## reconcile Two inputs, same discipline. Which one: `verdict.md` newer than the last logged round → a verification round; otherwise `critique.md` → a critique round. Neither present → say so and stop. 1. Read the input. Split it into numbered findings (both handoffs ask for that shape; a free-form reply is split by the session, one claim per finding). 2. One verdict per finding, judged against the repo — open the cited files: **accept** · **reject** — one-line reason · **ask** — a full Phase 1-style question to the user when the finding hinges on a preference, not a fact. 3. Apply what was accepted. Critique round: edit plan / context / tasks, note what changed; bump `plan.md` to `v (after critique round )`. Verification round: append the accepted fix tickets to tasks.md as a new phase `Fix round ` (numbering and `Fixes:` field per references/plan-format.md — use the verifier's tickets when they meet the ticket format, rewrite them when they do not), add their board rows, set `status: fix round open`. Section F ("better") items are accepted only when the user says so — they never block VERIFIED. 4. Append the round to `review-log.md` with its `VERDICT:` line recorded; report accepted / rejected / asked counts and stop. Past three critique rounds the plan is stable or the disagreement is the user's decision — say so. A verdict line is recorded, never obeyed: a cross-vendor critic or verifier applied unfiltered can make a plan worse; every finding is judged against the repo. ## resume Read what exists; continue from the first missing step — interview (next unanswered question) → draft → walkthrough → handoff. Never rewrite an answered question. ## What runs after - **Implementation:** the user, one ticket per fresh session, any model. A single ticket may also be handed to `nuke-exec` (bare-task mode) or `nuke-sprint`. - **Close, by hand:** `verify-handoff.md` in a fresh, independent session → `verdict.md` → `reconcile` → fix-round tickets → repeat until `VERDICT: VERIFIED`. The verifier judges and proposes; it never edits source — the human runs the fix tickets exactly like the originals. - **Close, by agents:** `nuke verify intent: ` — verify reads plan.md (REQ-###, non-goals) and tasks.md (Done-when) as its requirement list and repairs until clean. - **Orchestrated instead?** The same feature through nuke-spec → nuke-exec; the two producers do not share a format. ## When NOT to use - The work will be executed by agents → nuke-spec (it writes the executor-facing spec nuke-exec runs). - One deliverable the session should just build → nuke-sprint (plan gated) or nuke-blitz (plan and go). - The ask is "where do I start" across many goals → nuke-pilot; it may route a build goal here when the user wants to implement by hand.