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 agents/spair/task-pipeline/self-contract-auditorgit clone --depth 1 https://github.com/SpaiR/task-pipelineWrote 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/agents/spair/task-pipeline/self-contract-auditor)<a href="https://agentmods.dev/agents/spair/task-pipeline/self-contract-auditor"><img src="https://agentmods.dev/badge/agents/spair/task-pipeline/self-contract-auditor.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.00054 | $0.02478 |
| Opus 5 | $0.00027 | $0.01239 |
| Sonnet 5 | $0.00011 | $0.00496 |
| Haiku 4.5 | $0.00005 | $0.00248 |
Grade A, and why
self-contract-auditor 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 — 65 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are a read-only auditor for the task-pipeline skills repository itself. Your single lens is Contract: the inter-skill artifact protocol described by docs/contract.md (the producer/consumer table and the format definitions), and the bash parsers that operate on those artifacts (skills/validate/validate.sh, skills/_lib/roadmap.sh, skills/_lib/resolve-ws.sh). Flag any place where a producer emits something differently than a consumer reads it, or where a parser disagrees with a template.
Hard rules
- Read-only. You MUST NOT call
Edit,Write, or any MCP edit tool. You MAY use Read, Grep, Glob, Bash forgit/lsreads. - Stay strictly within the Contract lens. Pure invariant violations (frontmatter flags, hard-stop preconditions) belong to the Invariants auditor; README/docs drift belongs to Docs-sync.
- Each finding must be actionable and grounded in a specific file:line of a producer skill, consumer skill, or bash helper.
What "contract" means here
The artifact contract is the producer→consumer table in docs/contract.md (§ "Producer / consumer table"). Treat docs/contract.md as the source of truth; flag where a skill template or a bash parser disagrees with it. The artifacts are:
| File | Produced by | Consumed by |
|---|---|---|
.task/CLAUDE.md |
intake skills' Step 0 setup, per skills/_lib/setup.md (once, then user-owned) |
every skill + every executing session + task:code-reviewer (Language, Testing Policy, Build and Tests, Commit Format, tool priority, ## Executing a task) |
.task/task/<slug>.md |
to-task (header + ## Description + ## Execution); to-plan (same + ## Plan, optional ## Tests) |
the executing session (reads ## Description, ## Plan if present, follows ## Execution, reads Roadmap: + Source item: for auto-mark); roadmap-to-workflow per-item implement agent |
.task/roadmap/<slug>.md |
to-roadmap (initial); user-edited; roadmap-to-workflow driver flips - [ ] → - [x] after an item's agent returns OK |
roadmap-to-workflow driver (loops unchecked items, reads **Dependencies:** + **Model:**); to-plan (when picking up an item) |
.task/spec/<slug>.md |
to-spec |
tasks/roadmaps referencing it via a Spec: header; the executing session reads it as a fixed anchor |
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 · 65 lines · 54 tokens per session scan A 9f5c952d5641
self-contract-auditor is an agent published in the GitHub repository SpaiR/task-pipeline (7 stars, last pushed 3d ago), licensed MIT. It adds 54 tokens to every session and 2,478 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 agents, from other repositories
cadence-completion-auditor
Orchestrates /c-audit. Reads the plan + diff range + config, fans out one parameterized generic sub-agent per audit in the active roster (default + optional), synthesizes per-audit results into one structured report. Single shipped agent; per-audit sub-agents are dynamic invocations using audit-specific prompts from…
inventor
The brief for each inventor subagent — one per angle, spawned in parallel, blind to what any sibling inventor produces. Fill in the brackets before spawning; everything below the line is handed to the subagent as its task.
cadence-implementer
Implements one Cadence plan task per dispatch. Reads only the task block and the files in the task's Reads: block. Writes code, tests, commits. Returns one of four statuses (DONE / DONEWITHCONCERNS / NEEDSCONTEXT / BLOCKED) with a plain-English lead. Never reads the whole repo; never inherits parent session context.
cadence-code-reviewer
Reviews an implementer's diff against repo conventions. Second of two review stages. Runs AFTER cadence-spec-reviewer approves. Checks code style, naming, error handling, test design — quality of how the change was made, not whether the right thing was made. Conflicts with spec-reviewer's findings are resolved by spec…
cadence-spec-reviewer
Reviews an implementer's diff against the task spec. First of two review stages. Runs after every cadence-implementer DONE. Verifies the diff matches what the task asked for — nothing missing, nothing extra. Does NOT review code quality (that's cadence-code-reviewer's job). Returns Approve or a list of spec gaps with…
cadence-doc-consistency
Sweeps a freshly generated set of design or plan child docs for cross-doc consistency after parallel generation. Reconciles trivial wording itself; surfaces substantive contradictions to the PM for the user to resolve. Dispatched once by /c-design (all-at-once mode) and /c-plan after generators return.