メニュー
Turns confirmed findings from a taste into one scoped fix run, then re-verifies each finding at its cited location. Use after /sous-chef:taste when the user says to fix the findings, apply the review, or refire it. Not for new feature work - that is a fresh /sous-chef:fire.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | refire |
| description | Turns confirmed findings from a taste into one scoped fix run, then re-verifies each finding at its cited location. Use after /sous-chef:taste when the user says to fix the findings, apply the review, or refire it. Not for new feature work - that is a fresh /sous-chef:fire. |
A refire is a fix run whose spec already exists on disk: the findings.md a taste
wrote after validating every finding. That is what makes the ticket unusually
precise - file, line, failure scenario, prescribed fix, all confirmed against the
code. Your job is to carry that precision through and then prove each finding is
actually gone.
findings.md the most recent /sous-chef:taste wrote - its report
names the path; inside /sous-chef:serve it is the findings: line in the run's
state.md. (Lost the path? It's the newest findings.md under $SCRATCHPAD.)Same as fire, and for the same reasons:
git rev-parse HEAD).test -f ~/.codex/sous-chef.config.toml; missing means stop and offer
/sous-chef:mise (Codex silently ignores a missing profile).JOB=$(mktemp -d "$SCRATCHPAD/refire-XXXXXX")
($SCRATCHPAD is your session scratchpad directory; substitute its absolute path).git diff and git status --short into $JOB as the
baseline. The tree is usually dirty here (it holds the diff that was just tasted);
that is expected; the baseline is what separates the tasted diff from the refire's
changes.$(git rev-parse --short HEAD)+$(idx=$(mktemp -u); GIT_INDEX_FILE=$idx git add -A && GIT_INDEX_FILE=$idx git write-tree | cut -c1-12)
and compare it to the tree: line in the findings' header. On mismatch - or no
tree: line at all - the tree has moved since the taste and the cited line numbers
may have drifted: say so, then treat the file as an unvalidated review (the Inputs
rule above) - revalidate each finding at its cited location before writing the
ticket, dropping any that no longer hold.Write $JOB/ticket.md with the fire template's XML blocks, specialized:
<task>: "Fix the review findings below. Each is confirmed against the code."
Then one block per finding: file:line, the defect in one sentence, the evidence
(quoted code), and the prescribed fix. Taste's findings.md is already in this
shape - carry its CONFIRMED blocks over near-verbatim; its refuted audit-trail
section is not refire input.<done_when>: every listed finding resolved at its cited location, plus the repo's
verification commands passing.<files>: touch only files named in the findings. Everything else is off limits.<constraints>: fix ONLY the findings; no drive-by improvements, no refactors of
surrounding code, no reformatting.<verification>: the repo's check commands.<output_contract>: CHANGED / VERIFIED / OPEN, with a per-finding line under
CHANGED stating how each was resolved.Identical to fire, backgrounding rule included: backgrounded profiled run from the
repo root, announce it in one line (what, which model, expected minutes, log path,
cancel offer), no polling. Fire's ledger line applies too, with "skill":"refire".
At plating, in addition to fire's outcome checks (exit code, result file present, sandbox banner):
<files> Touch list, using fire's concurrent-edit rule. Name outside-list
files, warn concurrent edit detected - these changes are NOT part of this run's review, exclude them from the refire-attributed delta, and revert or flag worker
out-of-scope changes./sous-chef:taste; two clean models in a row
is the strongest ship signal this kitchen produces.One refire per taste. If a finding survives its refire, do not loop: fix it yourself or bring it back to the user with what was tried. (Same diminishing-returns rule as fire's two-delta cap.)
Cross-model code review - Codex reviews the diff read-only, then Claude validates every finding against the code before presenting it. Use when the user asks for a review, a second opinion, or a cross-model check. Offer it for large or risky diffs; invoke it directly only when the routing policy is autonomous.
Runs the whole line autonomously - implement via Codex, cross-review, fix confirmed findings, verify, report once at the end. Use when the user wants a task done end to end ("serve this", "just get it done"), or as the default for spec-able implementation when the routing policy is autonomous. Announces once; stops only for hard blockers.
Delegates a well-specified implementation task to Codex CLI (or, via --with, Claude Sonnet 5 or opt-in GLM-5.2) in the background. Use when the user asks to hand work to Codex, or for substantial spec-able work - features, refactors, migrations, boilerplate; offer first unless the routing policy is autonomous. Not for small fixes or ambiguous design; never fire silently.
Mise en place - setup and health check. Verifies Codex CLI and auth, installs the delegation profile, scaffolds AGENTS.md, and offers the routing policy. Re-run anytime, and after plugin updates to refresh the profile. Use when the user asks to set up sous-chef, or when another sous-chef skill fails because Codex or the profile is missing.
Prints the check - reads .sous-chef/receipts/ and renders the last 10 run receipts as a table with a savings total, and can reprint any receipt's shareable summary. Use when the user asks for receipts, costs, or savings, or invokes /sous-chef:receipts. Receipts are written automatically at the end of every serve and simmer.
Runs a goal loop - Codex implements fresh laps while Claude verifies each against a machine-checkable goal, until it passes or the budget runs out. Use only when the user explicitly asks for a loop ("simmer this", "loop until tests pass", "iterate until green") - it creates a branch and checkpoint commits, so confirm the contract first.