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/designnpx skills add yknnv/brownspec --skill designgit clone --depth 1 https://github.com/yknnv/brownspecWrote 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/skills/yknnv/brownspec/design)<a href="https://agentmods.dev/skills/yknnv/brownspec/design"><img src="https://agentmods.dev/badge/skills/yknnv/brownspec/design.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.00064 | $0.00973 |
| Opus 5 | $0.00032 | $0.00487 |
| Sonnet 5 | $0.00013 | $0.00195 |
| Haiku 4.5 | $0.00006 | $0.00097 |
Grade A, and why
design 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 — 89 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Design the change
Input is .brownspec/features/<slug>/spec.md. Output is design.md beside it. If the
spec is missing or its exit checklist does not pass, say so and run /brownspec:spec
instead — designing against an unfinished spec produces a document nobody trusts.
Read .brownspec/conventions.md first. A design that departs from how this codebase is
written needs a written reason, not silence.
Phase 1 — Blast radius
This is the phase that earns the document. The spec named where the change lands;
now find everything that depends on those points. Run level 3 of the repo-reading
skill against them — and only them.
For each point of change: callers (direct, then one hop out), importers, contract consumers across process boundaries, data touched, tests currently covering it.
Record the provenance at the top of the dependency section, verbatim:
**Dependency source:** graph (complete within static analysis)
**Dependency source:** text-search (may be incomplete — misses import aliases,
re-exports, and dynamic dispatch)
If the change touches code using getattr, decorators, registries, or runtime attribute
assignment, say so next to the list. Neither a graph nor a grep sees those, and a reader
deciding how carefully to review needs to know which kind of list they are holding.
An unmarked dependency list reads as complete. Never leave one unmarked.
Phase 2 — Propose, don't ask
Unlike the spec phase, most design questions have a defensible default once the spec is
settled and the blast radius is known. Read the affected code, pick an approach, and
present it as a recommendation with the alternatives you rejected and why. Fill in
${CLAUDE_PLUGIN_ROOT}/templates/design.md.tmpl and write it to disk before discussing.
Ask only where the choice is genuinely the user's: cost, risk appetite, migration window,
or an org constraint invisible from the repo. One question per message, and rewrite
design.md after each answer.
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 · 89 lines · 64 tokens per session scan A 26419e7ef334
design is a skill published in the GitHub repository yknnv/brownspec (2 stars, last pushed 6d ago), licensed MIT. It adds 64 tokens to every session and 973 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, 建…