back
loading skill details...
Use when a written implementation plan is ready to execute, when the user says "fire", "execute the plan", "build it", or hands over a plan file to implement...
--- name: fire description: Use when a written implementation plan is ready to execute, when the user says "fire", "execute the plan", "build it", or hands over a plan file to implement. The step after recipe. --- # fire The expeditor calls "fire" and the line cooks the order: exactly as the ticket reads, station by station, nothing leaving the pass unchecked and nothing improvised on the line. This skill executes a written implementation plan task by task. The plan is the ticket; its checkboxes are the board. ## Preconditions - A plan with discrete tasks exists ([recipe](../recipe/SKILL.md)'s output, or equivalent). No plan? Run recipe first; fire cooks what is written, it does not compose. - Never on the default branch. Create a feature branch (`fire/<plan>-<date>`), or isolate in a worktree: prefer the harness's native worktree tool; fall back to `git worktree add` only without one, and verify the worktree directory is gitignored first. - Green baseline. Run the suite before touching anything and read the output; on a failing baseline, stop and report, because you cannot tell new breakage from old. ## Read the ticket before firing Read the entire plan critically against the actual code before executing anything. Stale line numbers, helpers the plan names that the code lacks, tasks that contradict each other: find them now, while the tree is clean, not mid-task with it half-changed. Surface concerns and get them resolved before task 1. A plan that references structure that does not exist is a planning gap that goes back to its author, not an invitation to improvise. ## Execution Two modes, same discipline. Pick brigade mode when subagents are available and the plan has more than a couple of tasks; solo otherwise. - **Brigade mode:** dispatch a fresh implementer subagent per task, one at a time, in plan order. Give it the full task text and the scene-setting context in the prompt; never make it read the plan file. Read its diff and test output between tasks before dispatching the next. Implementer-only is the default; add reviewer passes for high-risk work or when asked, not as ceremony on every task. - **Solo mode:** execute inline, treating each task boundary as a checkpoint: tests green, committed, boxes ticked, then the next. Per task, either mode: 1. Follow the steps exactly, including the run-it-watch-it-fail steps. They are how you tell a broken step from a broken codebase. 2. Verify as the plan specifies and read the output. Evidence, not assertion. 3. Commit per task as the plan says. 4. Tick the task's checkboxes in the plan file. The plan is the live worklist; an executed plan with clean checkboxes is a board nobody can read. 5. Blocked, or reality diverges from the plan? A moved line number or renamed local is a plan typo: fix the plan's reference and continue. A missing helper, absent module, or contradicted design is structural: stop the task, revert any partial change, and take it back to the plan's author. Never blind-retry, and never invent API surface the plan does not define; in brigade mode, a blocked subagent gets something changed (more context, a smaller piece, a more capable model) before any redispatch. Execute continuously. No "should I continue?" between tasks and no progress check-ins; the user asked for the plan to be executed. The only stops are: a structural divergence, a blocker you cannot resolve, verification that fails twice on focused attempts, or the last task done. ## The finish After the last task: 1. Run the full suite one last time and read the output ([check](../check/SKILL.md)). Failing? Fix before offering anything. 2. Present exactly these options and wait: 1. Merge back to the base branch locally (re-verify the suite on the merged result before calling it done) 2. Push and open a pull request ([pass](../pass/SKILL.md) gates the filing) 3. Keep the branch as-is 4. Discard the work (requires the user to type `discard`; show what gets deleted first) 3. Cleanup: remove a worktree only for options 1 and 4, only if fire created it, and only after stepping out of it. Options 2 and 3 keep the worktree alive for iteration. Never remove a workspace the harness manages. ## Rules - The plan is the contract. Steps execute as written; disagreement with the plan is a conversation with its author, not a silent rewrite. - Never skip a watch-it-fail step because the implementation "obviously" works, and never weaken a test to get to green. - One implementer at a time. Tasks in one plan share state by design; parallel execution of independent work is [stations](../stations/SKILL.md)' job, not fire's. - Checkbox state is part of the deliverable. Tick as you go, not in a batch at the end. - Flagging a deviation in the final report is not the same as stopping at it. The author decides about structural changes before they are built, not after. ## Common mistakes - Executing on the default branch because the plan looked small. - Skipping the critical read, then meeting the plan's stale assumptions mid-task with the tree half-changed. - Silently inventing the helper the plan references but the code lacks, then calling it "honoring the plan's intent". That is design-by-improvisation; the plan author never saw the design. - Leaving every checkbox unticked, so nobody, including the resumed session after a crash, can tell where execution stopped. - Ending with "done" on the feature branch instead of the four finish options. - Pausing between tasks to ask whether to continue, when the instruction was to execute the plan.
don't have the plugin yet? install it then click "run inline in claude" again.
added explicit inputs section with edge cases (rate limits, auth expiry, flaky tests, empty results, timeouts), broke execution into numbered procedure steps with clear input/output per step, formalized brigade vs solo decision as decision point, added blocker handling decision tree, defined output contract with file locations and verification state, and clarified outcome signals for all finish paths.
the expeditor calls "fire" and the line cooks the order: exactly as the ticket reads, station by station, nothing leaving the pass unchecked and nothing improvised on the line. this skill executes a written implementation plan task by task. the plan is the ticket; its checkboxes are the board.
fire executes a finalized, written implementation plan against a codebase with discipline and precision. use this skill when a plan exists (typically from recipe), the user says "fire", "execute the plan", "build it", or hands over a plan file. fire does not compose plans or improvise: it cooks exactly what is written. each task runs in sequence, verified and committed before the next begins. stop immediately if the plan's assumptions diverge from reality (stale line numbers, missing helpers, contradicted design) and take it back to the plan's author. this is the execution phase; planning happens upstream.
required context:
optional inputs:
git worktree add as fallback.environment assumptions:
edge cases to note:
input: plan document, local repo state.
steps: 1.1. verify the baseline is green: run the full test suite and read the output. if any test fails, stop and report the failure. do not proceed with fire until baseline is clean.
1.2. ensure the repo is on a non-default branch. if on default (main, master, trunk), create a feature branch named fire/<plan-slug>-<date> (e.g., fire/auth-refactor-2025-01-15). if the harness provides a worktree tool, use it; otherwise use git worktree add <path> -b fire/<plan-slug>-<date> and verify the worktree directory is in .gitignore before proceeding.
1.3. read the entire plan before executing any task. check for: stale line numbers (grep the code to confirm referenced functions and file paths exist), helpers the plan names that the code lacks, contradictory instructions, and design assumptions that conflict with the actual codebase. surface all concerns in a summary before task 1.
output: clean baseline confirmed, branch created or worktree isolated, critical read complete with concerns (if any) logged. proceed only if concerns are resolved with the plan's author or are minor typos in line numbers (which fire fixes as it goes).
input: plan task count, subagent availability.
decision: if subagents are available and the plan has more than two tasks, use brigade mode. otherwise, solo mode.
brigade mode prep: prepare a subagent dispatch template with: full task text, scene-setting context (file names, recent commits, test names), and baseline state. the subagent does not read the plan file; fire provides only the task at hand.
solo mode prep: prepare to execute inline, using task boundaries as checkpoints.
per task, both modes:
3.1. read the task exactly as written. do not reinterpret or combine steps. if the plan says "run this command first, watch it fail, then fix X", follow that order.
3.2. perform the implementation. in brigade mode, dispatch the subagent with the task prompt and current codebase context. in solo mode, execute the steps locally. follow every instruction, including watch-it-fail steps; they reveal broken steps vs. broken code.
3.3. verify as the plan specifies. run the test command or validation step the plan names. read the output. do not assert "this obviously works"; read the evidence. if the plan says "check that function X returns type Y", verify the actual output.
3.4. review the diff. read all changes (in brigade mode, read the subagent's diff; in solo mode, git diff). if changes contradict the plan or introduce unplanned side effects, stop and revert. do not proceed.
3.5. commit per task. use the commit message the plan specifies, or a clear summary if the plan does not prescribe one. commit once per task; do not batch. the commit is the checkpoint.
3.6. tick the checkbox in the plan file (mark the task complete in the original plan document). update the plan document itself and commit that update separately, or as part of the task commit if the plan is inline. the plan is the live worklist; checkboxes are evidence of progress.
3.7. handle blockers: if a task is blocked (e.g., a missing helper, a named function does not exist, a design assumption is wrong), stop. do not retry blindly or invent API surface. revert any partial changes and take the blocker back to the plan's author. in brigade mode, do not redispatch the same subagent on the same task; instead, add more context or break the task smaller before a fresh dispatch.
3.8. move to the next task without asking for confirmation. no "should I continue?" between tasks. the user asked for the plan to be executed.
input (per task): task text, current code state, prior commit hash.
output (per task): committed changes, checkbox ticked, tests passing. ready for next task.
input: all tasks complete, feature branch with all commits and ticked plan.
4.1. run the full suite one last time. use check or equivalent. read the output. if any test fails, identify the failure, fix it, commit the fix, and re-run. do not offer finish options until suite is green.
4.2. present exactly these options and wait for user input:
discard to confirm. this is irreversible.4.3. cleanup (after user chooses):
output: feature branch merged to base (option 1), pushed with PR filed (option 2), frozen for review (option 3), or discarded (option 4).
branch isolation: if on default branch, create fire/<plan-slug>-<date> feature branch before any code change. if harness provides worktree support, use that; fall back to git worktree add only if harness has no native tool, and verify worktree path is gitignored first.
mode selection: if subagents available and plan has >2 tasks, dispatch in brigade mode (one subagent per task, sequential, with diff review between tasks). otherwise execute solo, treating task boundaries as checkpoints.
blocker handling: if a task diverges from plan (missing helper, wrong line number, contradicted design), stop immediately. do not invent API surface or silently fix the plan. revert partial changes and escalate to the plan's author. in brigade mode, a blocked subagent does not retry the same task; fire provides more context or a smaller scope before redispatch.
verification failure: if tests fail after a task, identify the root cause. if the cause is the task itself, fix and re-test. if the cause is a plan assumption that was wrong, stop and report. do not weaken tests to reach green.
plan accuracy: if the plan references a stale line number (e.g., "change line 42"), fire corrects the reference as it goes. if the plan references a missing function or contradicts the actual design, fire stops and does not continue.
finish state: after all tasks, suite must be green before offering finish options. if suite fails, fix the failure, commit, and re-verify. offer finish options only on green.
on completion, deliver:
fire/<plan-slug>-<date>) with one commit per task, in order.file locations: all commits live in the feature branch. plan file is the single source of truth for execution state (checkbox marks). worktree (if used) is isolated and independent of base branch until merged or discarded.
the user knows fire worked when: