From sous-chef
Turns confirmed findings from a taste into a scoped fix run, then re-verifies each finding at its cited location. Use after /sous-chef:taste to apply fixes.
How this skill is triggered — by the user, by Claude, or both
Slash command
/sous-chef:refireThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A refire is a fix run whose spec already exists on disk: the `findings.md` a taste
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.)
2plugins reuse this skill
First indexed Jul 9, 2026
npx claudepluginhub tillda/sous-chefTurns confirmed findings from a taste into a scoped fix run, then re-verifies each finding at its cited location. Use after /sous-chef:taste to apply fixes.
Lands verified fix items from review-research into authorized files with regression checks. Use when confirmed fixes need to be applied accurately.