Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add tomascupr/sous-chef --skill servegit clone --depth 1 https://github.com/tomascupr/sous-chefWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/tomascupr/sous-chef/serve)<a href="https://agentmods.dev/skills/tomascupr/sous-chef/serve"><img src="https://agentmods.dev/badge/skills/tomascupr/sous-chef/serve.svg" alt="Measured on agentmods" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 1 finding, up to medium
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- medium Excessive Agency · line 76 Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.Fix: Add human-in-the-loop confirmation for destructive, irreversible, or high-impact operations. Never auto-execute commands that modify files, send data, or alter system state.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00074 | $0.01639 |
| Opus 5 | $0.00037 | $0.00820 |
| Sonnet 5 | $0.00015 | $0.00328 |
| Haiku 4.5 | $0.00007 | $0.00164 |
Grade A, and why
serve scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 119 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 8d ago First seen · 119 lines · 74 tokens per session scan A 0ec33dfc3ffb
serve is a skill published in the GitHub repository tomascupr/sous-chef (76 stars, last pushed 1mo ago), licensed MIT. It adds 74 tokens to every session and 1,639 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
b3os-report
A team reporting skill that turns approved markdown and HTML reports into entries in an internal reports portal. HTML becomes the main view when available, while markdown remains the source and download version.
b3os-ai-code-safety
As code and logic grow, the cost is not the happy path — it is coupling: a change ripples into places you did not touch, and a "small fix" breaks something unrelated. This skill is a code-structure and refactoring guide: structure well from the initial design so a change stays local, apply operational safety where…
b3os-team-inbox
A team message-bus client for sending, receiving, and recalling messages between AI teammates. It also supports replying to a specific message thread and sending final reports to the team lead.
b3os-team-member-lifecycle
Use when adding, testing, disabling, offboarding, or archiving a b3rys team member across Claude Code channel, OpenClaw, Hermes Agent, or future runtimes.
b3os-bwf
A basic workflow for carrying a team task from planning through completion. BWF means b3os workflow; it is the overall process, not a harness, which is a method for splitting work among helper agents.
b3os-scheduler
A durable scheduler for recurring and one-time reminders that keeps running independently of an agent session.