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/mvschwarz/openrig/development-teamnpx skills add mvschwarz/openrig --skill development-teamgit clone --depth 1 https://github.com/mvschwarz/openrigWhat 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.00018 | $0.01422 |
| Opus 5 | $0.00009 | $0.00711 |
| Sonnet 5 | $0.00004 | $0.00284 |
| Haiku 4.5 | $0.00002 | $0.00142 |
Grade A, and why
development-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 2d 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 — 157 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Development Team
You are part of the development pod. Your shared job is to turn product direction into working software without guesswork, hidden assumptions, or skipped review gates.
Startup sequence
Before the pod starts real implementation:
- load the packaged skills named in your role startup checklist
- run
rig whoami --json - confirm who is playing implementer, QA, and design in this run
- wait for the orchestrator's real assignment instead of freelancing off a partial guess
The development pod should feel like a real working pod, not three isolated agents improvising alone.
Pod shape
The development pod may include:
- an implementer who writes the change
- a QA partner who gates every edit
- a designer who clarifies product behavior and UX before implementation fills in the blanks
Some starters only launch the implementer and QA. Others also launch a designer. The workflow stays the same: clarify first, implement deliberately, verify independently.
Shared loop
This is the default loop for product work:
1. Clarify the work and the acceptance criteria
2. Implementer sends a pre-edit proposal to QA
3. QA approves or rejects with specifics
4. Implementer changes code with TDD
5. Implementer sends the diff and verification output back to QA
6. QA approves or rejects with specifics
7. If commit authority is enabled, the implementer may commit
8. If commit authority is not enabled, stop at a QA-approved working tree and report that state clearly
Skip no gates. If the task is ambiguous, resolve the ambiguity before editing.
Chunk size points up — keep TDD's shape, not its ping-pong cadence (2026-08). Frontier agents handle
large, long-horizon, goal-oriented chunks — an hour-plus of complex work — without fragmenting. So don't
default to tiny pieces: keep TDD's shape (two sets of eyes, the guard structure, red before green)
but treat chunk size and cadence as a configured LEVER, not a habit. Classic small back-and-forth
ping-pong is unnecessary overhead when the loop's own gates (QA, review, guards) already bound a larger
chunk's risk. The sweet spot is task-dependent, much larger than it used to be, and rising. See
test-driven-development for the shape that stays fixed.
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.
- 2d ago First seen · 157 lines · 18 tokens per session scan A 5baee21f46d2
development-team is a skill published in the GitHub repository mvschwarz/openrig (64 stars, last pushed 3d ago), licensed Apache-2.0. It adds 18 tokens to every session and 1,422 once invoked, about $0.0001 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
ap-manager
L2 optional manager - coordinates a multi-lane slice, builds compact pointer envelopes, and dispatches disjoint L3 work without executing it.
ap-feature-coordinator
L1 feature coordinator - drives approved ROADMAP.md lanes through their required build/review/verification gates and owns the run-wide feature frontier.
triage
Triage a GitHub repository's open issues by finding exact duplicates, rejecting evidenceably off-base requests, requesting concrete clarification, applying only existing labels, and opening a linked root-cause issue when multiple reports share one underlying invariant failure. Use when a maintainer asks to triage…
yao-board
Kanban board and task query expert. ALWAYS invoke this skill when the user asks about boards, tasks, task status, or project progress. Do not guess task state — use this skill first.
change-manager
name: change-manager description: Used when the user adds a feature or incrementally changes an existing project that already has Product-Spec.md. Runs the changes/ workflow (propose, apply, verify, archive), aligned with OpenSpec-style SDD while delegating implementation to dev-planner and dev-builder. version: 1.1.0…
dispatcher
Use when you want the orchestrator to pick the next repo to work on across your whole portfolio — it enumerates candidate repos below the confinement root, resolves free/busy from each repo's session.lock lease, ranks the FREE ones by backlog priority × staleness × readiness, recommends the single most worthwhile one…