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/yknnv/brownspec/tasksnpx skills add yknnv/brownspec --skill tasksgit clone --depth 1 https://github.com/yknnv/brownspecWhat 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.00059 | $0.00776 |
| Opus 5 | $0.00030 | $0.00388 |
| Sonnet 5 | $0.00012 | $0.00155 |
| Haiku 4.5 | $0.00006 | $0.00078 |
Grade A, and why
tasks 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 — 85 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Break the design into tasks
Input is spec.md and design.md under .brownspec/features/<slug>/. Output is
tasks.md from ${CLAUDE_PLUGIN_ROOT}/templates/tasks.md.tmpl, plus trace.json.
If the design's exit checklist does not pass, stop and say so. A task list built on an unfinished design encodes its gaps as work items and hides them.
Sizing
One task is one reviewable unit: half a day to a day for someone who knows the codebase, producing a diff a reviewer can hold in their head. Split anything larger. If a task cannot be sized because the approach is unclear, that is a design gap — name it and go back rather than papering over it with a vague task.
Ordering
By dependency, not by layer. The system stays deployable at every step:
- Expand — additive, breaks nothing (new columns, new endpoints, flag off)
- Implement — the behavior itself, behind the flag
- Migrate — move consumers and data over
- Contract — remove what is now dead
Mark what can run in parallel, and what must ship in one release together, with why.
Consumer migration from the design's blast radius becomes real tasks here. A breaking change with three known callers is four tasks, not one.
Each task carries
- A verb-first title
- The files or modules it touches — you have read the repo, be specific
- Which acceptance criterion from
spec.mdit advances - How it is verified: the test, the check, the observable outcome
- Its blockers, by task ID
Testing and observability are tasks, not footnotes. If the design says a metric is emitted, some task emits it.
trace.json
Write it alongside tasks.md, with files empty. It is filled in as work happens — the
agent implementing a task records what it actually touched. That record is what
/brownspec:drift will later compare against the spec.
{
"slug": "<slug>",
"spec": "spec.md",
"generated": "<date>",
"tasks": [
{
"id": "T1",
"title": "<verb-first title>",
"advances": ["A1"],
"expected_paths": ["app/api/orders.py"],
"files": [],
"status": "todo"
}
]
}
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 · 85 lines · 59 tokens per session scan A e3c19917de66
tasks is a skill published in the GitHub repository yknnv/brownspec (2 stars, last pushed 5d ago), licensed MIT. It adds 59 tokens to every session and 776 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 skills, from other repositories
prospec-verify
Verify Implementation - Run 5+1 dimension audit (tasks, spec compliance, constitution, knowledge-implementation consistency, tests, design consistency) and assign quality grade (S/A/B/C/D). Triggers: verify, audit, quality check, 驗證, 稽核, 品質檢查, 評級.
prospec-archive
Archive Changes - Archive completed changes, generate summary, sync requirements to feature specs, and gate archiving on Knowledge sync. Triggers: archive, spec sync, finalize change, 封存, 歸檔, 收尾, 規格同步.
prospec-knowledge-generate
Generate AI Knowledge - Read raw-scan.md, analyze project structure, autonomously decide module boundaries, and produce Recipe-First module READMEs and index. Triggers: generate knowledge, analyze project, module split, 產生知識, 知識庫, 分析專案, 模組拆分.
release
Cut a prospec GitHub release — bump version strings, tag, and publish release notes in the established format so the Release Binaries workflow attaches multi-platform binaries. Triggers: release, publish release, cut a release, ship a version, 發布, 發佈, 出版本, 發版, 版本發布, 發布 release.
submit-pr
Open a prospec pull request in the house format — push the change's two commits, write the Traditional Chinese body, and link it to its issue. Triggers: submit pr, open pr, 開 PR, 送 PR, 發 PR, pull request, 提交 PR.
submit-issue
Open a prospec GitHub issue in the house format — conventional-commit title, Traditional Chinese body (problem → solutions → acceptance criteria), downstream-compatibility block, series cross-links, and optional model-routing guidance. Triggers: submit issue, open issue, create issue, file issue, 開 issue, 發 issue, 建…