tomascupr/sous-chef/serve

Claude Code and agent skill by tomascupr/sous-chef

Trust tier 3
  • community
Source check pending

Checking that the SKILL.md file is still in the repository.

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.

Install

npx vskill@latest install tomascupr/sous-chef/serve

SKILL.md

Serve - the whole line, one order

Serve is fire, taste, and refire composed into one autonomous pass. Each stage follows its sibling skill exactly; serve adds only what connects them: a run state file that outlives your context, and an autonomy contract that replaces the per-stage conversation.

Run state - the ticket on the rail

Before stage 1, mint one run dir: RUN=$(mktemp -d "$SCRATCHPAD/serve-XXXXXX"). Each stage mints its job dir per its sibling skill, but inside $RUN (substitute $RUN for $SCRATCHPAD in the sibling's mktemp) - even with a stale state file, ls "$RUN" reconstructs the run. Keep $RUN/state.md, a few self-describing lines rewritten in full at every stage transition:

task: <one line>
started: <UTC ISO-8601 of stage 1's fire>
budget: 5
runs_used: 2 (fire, taste)
stage: taste plated; next: refire
baseline: <abs path to stage 1's pre-fire.patch>
findings: <abs path to taste's findings.md>
job: <abs path to the job dir currently cooking, if any>

Bump runs_used when a run is launched, not when it lands - a compaction while a job is in flight must not un-spend the budget. The conversation is not the ledger of this run; state.md is. After compaction, or on any doubt about the count, read it before firing anything. (A /clear or session death mints a new scratchpad - serve is a single-session promise and does not survive that; the working tree and job dirs still hold the work.)

Choosing the worker

If the arguments begin with --with <worker> (see fire's worker table), the choice applies to the whole line: fire and refire run on that worker; taste stays on Codex read-only when available, which makes the review cross-model when the worker is not Codex. Record the worker in state.md (worker: sonnet).

Whenever implementer and reviewer share a lineage, say so in the final report. The default all-Codex line always does: Codex reviews its own diff (fresh context - codex exec carries no session memory - but same lineage), so Claude's validation pass is the only cross-model check in that run.

The pipeline

  1. Fire - per /sous-chef:fire: preflight, ticket, backgrounded run, plating with

your own verification. Record the job's pre-fire.patch path as baseline: in state.md - later stages scope against it. If plating fails verification, one delta round (it counts against the serve budget). The pipeline advances only on green verification: still red after the delta means fix it yourself if a surgical fix will do, otherwise stop and report honestly - tasting a known-broken implementation wastes the remaining budget.

  1. Taste - per /sous-chef:taste: read-only cross-review scoped to the delta

against the baseline: patch in state.md - the user's pre-existing WIP is not part of this order - then your validation pass; record the resulting findings.md path as findings:. Skip only if the diff is trivial (a few lines); say so in the final report.

  1. Refire - per /sous-chef:refire: if the findings: file lists any CONFIRMED

findings, one scoped fix run, then re-verify each finding at its cited location.

  1. Plate - run the verification commands one final time and serve.

Stage transitions inherit fire/refire's changed-files-vs-<files> concurrent-edit check; outside-list paths are named, warned, and excluded from the stage delta.

Autonomy contract

  • Announce ONCE before stage 1: the task, the model, and that this is a full serve

(typically 2-3 Codex runs, expect 15-45 minutes at high reasoning effort). Then run the pipeline without asking anything between stages; a one-line tick as each stage completes ("fire plated, checks green - tasting now") keeps a long serve legible. No-asking is the contract, not silence.

  • Progress ticks are on by default: while a run cooks, keep ticks armed per fire's

"While it cooks" - event wakes on the worker's milestone notebook where a Monitor is available, the self-paced wakeup loop as fallback - one distilled line every few minutes, disarmed the moment the run exits. Each tick reads $RUN/state.md (its job: line names the job dir whose stream/log to check) plus the repo's .sous-chef/progress.md for milestones, not conversation memory, so ticks survive compaction. A serve asks for 15-45 unattended minutes; the ticks are what make that tolerable.

  • Only interrupt the user for hard blockers: a failed run with an error they must act

on (auth, quota), verification still red after stage 1's delta (and any surgical fix of your own), a finding that survived its refire, or preflight failures.

  • Every safety rule of the underlying skills still applies: background always, never

poll, per-job dirs, outcome checks before trusting results, baseline-aware diffs.

  • Budget: at most 5 Codex runs total (fire, one delta if needed, taste, refire,

optional confirmation taste). The count lives in $RUN/state.md, not in your context. Failed runs and retries count - the budget is quota spend, not useful output - so when a retry eats a slot, the confirmation taste is the first thing dropped; say so in the final report. If the work is not done inside the budget, stop and report honestly where it stands; if what remains is goal-shaped (a check command that must pass), offer to continue as /sous-chef:simmer rather than overrunning.

The final report

One message: what shipped (files, summary), what taste found (confirmed findings and how the refire resolved them; refuted count), the verification output you ran yourself, and anything OPEN. If all stages came back clean, say so plainly - two models in agreement, checks green, plate served.

Then write the run's receipt to .sous-chef/receipts/ per ../receipts/references/receipt-template.md and, when the verdict is verified, end the report with its shareable summary line. Receipt numbers come from the job logs, your own verification, and the diff against baseline: - a line you can't back with a measurement gets dropped, not guessed.

When NOT to serve

  • Ambiguous design work: resolve the approach first, then serve.
  • Goal-loop work ("iterate until the benchmark improves"): that is /sous-chef:simmer.
  • When the user wants to review between stages: use fire, taste, refire individually.

Security

  • Security scanPassed, 95 of 100Pattern checks on the skill's files.
  • Model reviewPassed

Quality evaluation

  • Task evaluationNot runNo evaluation yet. Run one in Skill Studio.

Source

Popularity

7-day trend score
0

Not refreshed yet.

Works with

Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.

  • Claude Code
  • Cursor
  • GitHub Copilot
  • Windsurf
  • Codex
  • Gemini CLI
  • Cline
  • Amp
  • Roo Code
  • Goose
  • Continue
  • Kilo Code
  • Junie
  • Trae
  • OpenHands
  • Qwen Code
  • AI Agent
  • Tabnine Chat
  • Sourcegraph Cody
  • Amazon Q
  • Firebase Genkit
  • Sweep
  • Devin
  • Phind
  • Mentat
  • Claude Desktop
  • Aider
  • GPT Pilot
  • Plandex
  • bolt.new
  • v0
  • Replit Agent
  • Anse
  • TypingMind
  • BetterChatGPT
  • LibreChat
  • Warp AI
  • Pieces
  • Fig AI
Embed badge
vskill VERIFIED badge
[![vskill VERIFIED](https://verified-skill.com/api/v1/skills/tomascupr/sous-chef/serve/badge)](https://verified-skill.com/skills/tomascupr/sous-chef/serve)

Something wrong with this skill or its page? Tell us.