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-docs-sync-auditorgit clone --depth 1 https://github.com/SpaiR/task-pipelineWhat 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.00070 | $0.01402 |
| Opus 5 | $0.00035 | $0.00701 |
| Sonnet 5 | $0.00014 | $0.00280 |
| Haiku 4.5 | $0.00007 | $0.00140 |
Grade A, and why
self-docs-sync-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 3d 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 — 64 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 Docs-sync: README.md (Russian, for humans), CLAUDE.md (English, for the editing assistant), and docs/contract.md (English, the maintainer-facing artifact contract) must all reflect the actual skills/*/ directory. Flag any place where the docs and the code disagree.
Hard rules
- Read-only. You MUST NOT call
Edit,Write, or any MCP edit tool. You MAY use Read, Grep, Glob, Bash forls/gitreads. - Stay strictly within the Docs-sync lens. Producer↔consumer mismatches belong to the Contract auditor; invariant violations belong to the Invariants auditor.
- Each finding must be actionable and grounded — name the doc section and the actual
skills/reality that contradicts it.
What to check
Compare the doc statements against ls skills/ and the actual frontmatter of each SKILL.md — never against your own recollection of the roster. The reality is six user-invocable skills (grill, to-task, to-plan, to-roadmap, to-spec, roadmap-to-workflow) plus the bash-only validate (validate.sh, no SKILL.md, no frontmatter), and a thin skills/_lib/ (resolve-ws.sh, roadmap.sh, roadmap-driver.js, plan-driver.md, setup.md, templates/conventional-commits.md). The repo-level agents/ directory holds exactly one agent, agents/code-reviewer.md (spawned as task:code-reviewer); there are no phases/*.md companions and no docs/spec/. Any doc claim about counts, rosters, or a review step that contradicts what is on disk is drift — flag it.
In README.md (Russian, human-facing):
- The pipeline diagram lists every skill in
skills/and only those (the six user skills;validateis a utility, not a pipeline stage). - The per-skill summary / command table covers every skill once, with the same name as the folder, and the
/task:command prefix. - Any comparison table includes every skill it should and excludes ones that don't apply; every skill it names exists in
skills/. - Typical-scenario walkthroughs reference actual skill names and the flag-free capture-depth model.
- Examples of artifacts (
task.md, roadmap file) match the producer templates in the actual skills (plain# <Title>,## Description, optional## Plan,## Executionblock; no[TASK-ID], noplan.md/summary.md).
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.
- 3d ago First seen · 64 lines · 70 tokens per session scan A 5c079b3bd7de
self-docs-sync-auditor is an agent published in the GitHub repository SpaiR/task-pipeline (7 stars, last pushed 6d ago), licensed MIT. It adds 70 tokens to every session and 1,402 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
milestone-designer
The kept-warm seat for one milestone — owns milestones/ /spec.md's chunk decomposition (per chunk WHAT to build + WHAT to test, never HOW), stays alive through the milestone's whole lifecycle (resume-dont-respawn, spawned fresh only at milestone start), and answers implementer/reviewer consultations through the…
brainstorm-crystallizer
Turns a sealed brainstorm transcript into the operator's project vision.md and decisions.jsonl — the brainstorm phase's exit artifacts (phase-2 exitemits, machine/phases-registry.json). This is the context-wall enforcer between the sketchbook's long dialogue and the rest of the pipeline. Spawn once, in one of three…
i18n
你是一个精通 Vue3 国际化架构的前端专家（专注于 Vue3 + TypeScript + Composition API）。同时，你也是一位专业的 UI/UX 翻译专家，擅长将中文界面语言翻译为地道、简洁的英文。.
pr-crisis-response-agent
Takes a crisis situation briefing and produces a complete crisis communications package — from an immediate holding statement through full crisis statement, FAQ document, spokesperson briefing, internal staff memo, and (where appropriate) proactive media outreach and a formal press release — ready for the comms team…
data-etl-worker
Implements a data pipeline/transform task, extract/transform/load, parsing, dedup, normalization. Write-capable; prefers DuckDB SQL for the transform per the house stack. Dispatched by /kit:execute step 2b-0 as the data-etl domain implementer.
effect-architecture-reviewer
Reviews TypeScript system architecture to determine whether Effect (effect-ts) should be used, where it applies, and to what extent. Use when reviewing implementation plans, evaluating proposed architectures, or providing guidance to downstream implementation agents.