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 agentmods add skills/donnfelker/loop-skills/dev-teamnpx skills add donnfelker/loop-skills --skill dev-teamgit clone --depth 1 https://github.com/donnfelker/loop-skillsWrote 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/donnfelker/loop-skills/dev-team)<a href="https://agentmods.dev/skills/donnfelker/loop-skills/dev-team"><img src="https://agentmods.dev/badge/skills/donnfelker/loop-skills/dev-team.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 | $0.00222 | $0.03485 |
| Opus 5 | $0.00111 | $0.01742 |
| Sonnet 5 | $0.00044 | $0.00697 |
| Haiku 4.5 | $0.00022 | $0.00348 |
Grade A, and why
dev-team 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 4d 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 — 166 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Dev Team — Dev → QA → Reviewer Loop
This skill drives one unit of work — a spec, ticket, finding, or change request — from its written spec to a committed, reviewed result. It does this by standing up a small agent team and running it through a bounded loop: a Dev implements, a QA verifies ("trust nothing"), a Reviewer does the code review and creates the commit. On any failure the loop sends the Dev the specific feedback, up to a cycle cap, then escalates. Fire it off and it builds the team for you.
It is the reusable core of a rigorous implementation flow. You can fire it off on whatever you're working on right now, and implement-full-spec calls it once per subtask before layering on its own stacking, PR, and review-response machinery.
When to use this skill
Use it when the operator wants a change implemented with rigor — built, independently verified, and code-reviewed before it lands — rather than a quick inline edit. Common phrasings:
- "Implement this spec with a dev → QA → review loop."
- "Fire off the dev team on this task."
- "Use agents to build this and verify it before committing."
- "Drive this change through dev, then QA, then code review."
It is the wrong skill when:
- The change is a one-line tweak you can make and verify directly — the loop's overhead buys nothing.
- The work is a parent ticket with many subtasks that each want their own PR → use
implement-full-spec, which calls this loop per subtask. - The operator wants synchronous pair-programming → just work alongside them.
What this loop needs (the contract)
Before dispatching the first agent, pin these. They are the inputs every role agent inherits — the prompt is the contract, so gather them up front:
| Input | What it is |
|---|---|
| Workspace | The absolute path the agents work in (a worktree or a checkout) and the branch. Agents must stay inside it. |
| Verbatim spec | The full spec for this unit of work — severity, file paths, description, impact, and every remediation bullet. Never summarize; the prompt is the contract. |
| IN/OUT-of-scope partition | For every remediation bullet, mark it IN SCOPE or OUT OF SCOPE (with a proposed follow-up name). Bullets needing infrastructure outside the repo are OUT OF SCOPE. |
| Canonical checks | The exact commands the operator expects to be green: typecheck, lint, the specific test suites, integration tests if any. |
| Commit terminus | The loop ends at a commit on the branch. Pushing / opening a PR is the caller's job — the loop does not push. (implement-full-spec pushes and opens the PR after the loop returns.) |
What ships with it
1 file 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.
- 4d ago First seen · 166 lines · 222 tokens per session scan A a2464f619966
dev-team is a skill published in the GitHub repository donnfelker/loop-skills (18 stars, last pushed 1mo ago), licensed MIT. It adds 222 tokens to every session and 3,485 once invoked, about $0.0011 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
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
auto-perf-optimize
Run agent-driven VS Code performance or memory investigations. Use when asked to launch Code OSS, automate a VS Code scenario, run the Chat memory smoke runner, capture renderer heap snapshots, take workflow screenshots, compare run summaries, or drive a repeatable scenario before heap-snapshot analysis.
chat-perf
Run chat perf benchmarks and memory leak checks against the local dev build or any published VS Code version. Use when investigating chat rendering regressions, validating perf-sensitive changes to chat UI, or checking for memory leaks in the chat response pipeline.
chat-pet-sprite-creation
Use when creating or changing VS Code chat pet sprite art, sprite sheets, state animations, eye treatments, Stable/Insiders variants, or pet transitions under src/vs/workbench/contrib/chat/browser/widget/media/chatPet.
cpu-profile-analysis
Analyze V8/Chrome CPU profiles (.cpuprofile) and DevTools trace files (Trace-.json). Use when: profiling performance, investigating slow functions, comparing code paths, finding bottlenecks, analyzing timeToRequest, understanding call trees from sampling profiler data, analyzing layout/paint/rendering, investigating…