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 escoffier-labs/skillet --skill sendbackgit clone --depth 1 https://github.com/escoffier-labs/skilletWrote 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/escoffier-labs/skillet/sendback)<a href="https://agentmods.dev/skills/escoffier-labs/skillet/sendback"><img src="https://agentmods.dev/badge/skills/escoffier-labs/skillet/sendback.svg" alt="Measured on agentmods" height="20"></a>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.00051 | $0.01015 |
| Opus 5 | $0.00026 | $0.00508 |
| Sonnet 5 | $0.00010 | $0.00203 |
| Haiku 4.5 | $0.00005 | $0.00102 |
Grade A, and why
sendback 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 — 56 lines — stays where its author put it; the contents beside it link to each section on GitHub.
sendback
A plate comes back from the dining room. The kitchen that survives is the one that checks the plate before remaking it: sometimes the dish is wrong, sometimes the ticket was wrong, sometimes the diner ordered the wrong thing. Remaking on reflex wastes the food; arguing on reflex loses the diner. This skill is that check, applied to review feedback: verify, then implement or push back, with technical reasons either way.
Core principle: review feedback is a set of claims to verify, not orders to follow and not an audience to perform for. Reviewer seniority changes nothing; the codebase is the authority.
The pattern
For every piece of feedback, in order:
- Read all of it before reacting to any of it. Items relate; item 4 can change what item 1 means.
- Clarity gate. Any item you cannot restate concretely ("the loader issue still needs handling" - which issue? handled how?) stops the batch. Ask about the unclear items before implementing the clear ones; a guessed interpretation is a design decision nobody made, and partial understanding implements the wrong thing confidently. The one exception: an item you can show is independent of every unclear item may proceed, and the reply states that is what happened.
- Verify each claim against the codebase. Does the suggestion break existing behavior or a documented contract? Does a test pin the current behavior on purpose? Is there a reason the code is the way it is? Run the check (a grep, a test, a five-line repro), do not adjudicate from memory.
- YAGNI gate for "should also support" items. Grep for callers. Nothing uses the proposed parameter, protocol, or flexibility? The answer is "nothing calls this - skip it (YAGNI)?", not speculative API surface. The reviewer and you both work for the user; unwanted features serve neither.
- Then act, one item at a time, in order: blocking issues, simple fixes, complex fixes. Test each before the next; taste applies to review fixes like any other change.
- Reply with substance. What was done and where, what was pushed back on and the technical reason, what awaits clarification. Evidence over adjectives.
What ships with it
2 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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 · 56 lines · 51 tokens per session scan A 65d75a0d7393
sendback is a skill published in the GitHub repository escoffier-labs/skillet (4 stars, last pushed 7d ago), licensed MIT. It adds 51 tokens to every session and 1,015 once invoked, about $0.0003 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-31.
Other skills, from other repositories
production-audit
Exhaustive production-readiness audit of any codebase or product. Runs diverse-angle discovery passes until two consecutive passes find nothing new, adversarially verifies every finding against the real code, and reports one flat severity-tagged list with file:line evidence. No summary, no hedging.
craft-audit
The front door to the craft skills — a whole-project production-readiness orchestrator that drives the ten per-domain craft skills (ux, frontend, backend, db, security, infra, observability, testing, lint, ai) instead of auditing one surface at a time. It discovers the project's shape, plans an audit per surface, and…
craft-backend
The Craftsman standard for building and reviewing backend code — API routes, request validation, the authentication boundary, service/business logic, error handling, route rate-limit middleware, third-party integrations, and background jobs. Use this WHENEVER the work touches the server side: adding or reviewing a…
review-work
Post-implementation gate review: run manual QA on the real surface yourself, then launch ONE gate reviewer (never a panel) to audit goal, constraints, code quality, security, missed context, and QA evidence. Use before a PR handoff or when the user explicitly asks to review completed work.
one-way-door
Flags irreversible decisions before commit. Use for data models, infra, auth boundaries, API contracts, event schemas, CI/CD.
critical-code-reviewer
Rigorously review code or pull requests for correctness, security, accessibility, maintainability, tests, and edge cases. Use when users request a critical code review, want a guided walkthrough of findings, need implementer-facing feedback, or want to prepare, create, or submit a GitHub pull request review.