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/soulcodex/agentic/write-adrnpx skills add soulcodex/agentic --skill write-adrgit clone --depth 1 https://github.com/soulcodex/agenticWhat 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.00055 | $0.00435 |
| Opus 5 | $0.00028 | $0.00217 |
| Sonnet 5 | $0.00011 | $0.00087 |
| Haiku 4.5 | $0.00006 | $0.00044 |
Grade A, and why
write-adr 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.
What it actually says
Write ADR Skill
Create a well-structured Architecture Decision Record.
Step 1 — Gather Information
Ask the user (if not already provided):
- What decision was made?
- What was the context or problem that prompted it?
- What alternatives were considered?
- What are the trade-offs or consequences of this decision?
Step 2 — Determine the ADR Number
List existing ADRs in docs/adr/ and increment the highest number.
If the directory does not exist, create it and start at 0001.
Step 3 — Write the ADR
Use the template from adr-template.md. Fill every section:
- Title: short, imperative phrase describing the decision
- Status:
Acceptedfor a new decision - Date: today's date in YYYY-MM-DD format
- Context: the situation that made a decision necessary — be specific about constraints
- Decision: what was decided — use active voice ("We will use X")
- Consequences: both positive and negative outcomes; what becomes easier and harder
The ADR must stand alone — a reader unfamiliar with the decision must understand it fully from the ADR text without needing to ask follow-up questions.
Step 4 — Write the File
Save to docs/adr/NNNN-{kebab-case-title}.md.
Example: docs/adr/0003-use-postgresql-as-primary-store.md
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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 · 57 lines · 55 tokens per session scan A fe5f5b350855
write-adr is a skill published in the GitHub repository soulcodex/agentic (10 stars, last pushed 2d ago), licensed MIT. It adds 55 tokens to every session and 435 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
help
Use when asked what the capstone plugin can do - prints the usage block.
core
Internal to the capstone suite - carries the shared rules (references/) and scripts every capstone subcommand reads; it exists so npx-skills installs ship them alongside the command skills. Not meant to be invoked directly; when invoked anyway, run references/../scripts/help.sh and output its stdout verbatim.
feature
Use when the user wants one feature taken from idea to working code - "add a feature", "build X end to end", "take X from idea to shipped" - runs the feature chain groom -> plan -> implement consecutively, detecting the feature's stage and resuming at the first incomplete one. For the whole-product greenfield pipeline…
groom
Use when starting work on a feature or change for a project that already has capstone docs - "new feature", "add a feature", "implement X", "build X", "design a feature", "spec it out", "flesh out", "refine this idea", "let's work on X" - a doc-grounded one-question-at-a-time interview producing a traceable feature…
map
Use when asked to build, refresh, update, or check a codebase's architecture reference docs - "map the codebase", "document this repo", "are the docs current", "bring the docs in line with the code" - writes a docs/capstone/ index plus topic chapters, the logic/ business-logic map and the uiux/ surface map, then on…
review
Use when asked for an opinionated review of the codebase - architecture/backend findings, UI findings against the project's own design docs, or both - severity-ranked with evidence, written to docs/capstone/review.md. Bare "review" does both sides; "review backend" or "review frontend" does one. Opt-in judgment; never…