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/ribeirogab/specwright/deliverynpx skills add ribeirogab/specwright --skill deliverygit clone --depth 1 https://github.com/ribeirogab/specwrightWhat 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.00086 | $0.02542 |
| Opus 5 | $0.00043 | $0.01271 |
| Sonnet 5 | $0.00017 | $0.00508 |
| Haiku 4.5 | $0.00009 | $0.00254 |
Grade A, and why
delivery 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 — 224 lines — stays where its author put it; the contents beside it link to each section on GitHub.
delivery — conduct many changes to done
Take an outcome too large for one pull request and carry it to done: one change per PR, each conducted by its own owner, several at a time.
The orchestrator is a pure conductor. It reads and writes delivery state, dispatches owners, tracks, reports, and escalates. It never touches code — not one file outside the delivery folder. If you catch yourself about to implement something, stop: that work belongs to a change owner.
Announce at start: "Conducting the delivery."
Resolve bundled resources
Resolve SW_PLUGIN_ROOT as the other skills do — PLUGIN_ROOT, else
CLAUDE_PLUGIN_ROOT, else two parents above this loaded skills/delivery/
directory — and require templates/delivery.md beneath it when decomposing.
Start or resume
$ARGUMENTS points at a requirements document (a PRD, a technical design, an
external ticket) and no delivery exists yet → decompose it first. Read the whole
document, then write .specwright/deliveries/YYYY-MM-DD-<slug>/delivery.md from
the template: the outcome's why, its success criteria, and the change table
with its dependency order. Write one shallow proposal.md per decomposed change,
each with delivery: pointing at the delivery folder.
Keep the decomposition shallow on purpose. Each change's own plan is written later by its owner, which lets it use what the earlier changes discovered. Planning everything up front spends effort on plans that the first shipped change will invalidate.
Show the decomposition and get approval before dispatching anything.
Otherwise → locate the delivery: $ARGUMENTS names a slug, or exactly one
delivery has unshipped changes (found through their delivery: frontmatter). Ask
which when several match. Read delivery.md and every member change's proposal.md
frontmatter.
All state lives in those files. That is what makes a fresh session able to resume with this skill and nothing else.
Commit mode
if git check-ignore -q .specwright/deliveries; then
mode=local
[ -d .specwright/deliveries ] || { echo "local-mode vault not found in this checkout; conduct from the checkout where specwright was initialized"; exit 1; }
else
mode=shared
fi
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 · 224 lines · 86 tokens per session scan A 06710bfb54af
delivery is a skill published in the GitHub repository ribeirogab/specwright (3 stars, last pushed 24d ago), licensed MIT. It adds 86 tokens to every session and 2,542 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-31.
Other skills, from other repositories
review-depth
Decide how much review a change has earned, before reviewing it. Selects quick, standard, or deep from stated signals (reviewable changed lines, directory spread, trust-boundary risk flags, blast radius, documentation-only scope), reports the signal table and the rule that fired, then runs house-review at the selected…
doc-sync
Use when code has moved and the documentation may not have, or when a documentation set needs auditing for stale claims. Detects documentation drift by checking prose claims against repository facts, classifies every document as current-state (correctable), contract (report-only, human-owned) or ledger (skipped), and…
init-worktracking
Scaffold a portable, agent-optimized spec-driven work-tracking system into the current repository: AGENTS.md (global rules + agent reading protocol), a .tasks/ directory of atomic task files, and (by tier) ROADMAP.md, CHANGELOG.md, a validate.py checker, and thin CLAUDE.md/Cursor/Copilot pointers. Choose a footprint…
reconcile-worktrees
Safely consolidate one or more isolated git worktrees (for example left behind by parallel background agents, or from the fix-batch skill) into the main working tree, without committing or merging blindly. Use whenever asked to "reconcile the worktrees", "merge these agent branches", "bring the worktree changes back…
verifier-agent
Use before reconciling or landing an implementation to independently verify it against its approved spec and its task's acceptance criteria. Runs the declared verification commands and records each exact outcome, composes the spec-conformance lens so a contract divergence fails the run even when every command passes…
spec-author
Use when turning a raw idea, feature request, or bug into a persistent behavioral spec before any tasks or code. Drafts a scenario-based spec (problem, goals, non-goals, constraints, Given/When/Then scenarios with stable S-NNN ids, proposed surface, open questions), composes the spec-quality lens to self-check and…