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-readmenpx skills add soulcodex/agentic --skill write-readmegit 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.00053 | $0.00501 |
| Opus 5 | $0.00026 | $0.00251 |
| Sonnet 5 | $0.00011 | $0.00100 |
| Haiku 4.5 | $0.00005 | $0.00050 |
Grade A, and why
write-readme 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 README Skill
Generate or update the README.md for the current project or specified package.
Step 1 — Read the Project
Read:
package.json/go.mod/pyproject.toml/composer.json— for name, description, scripts- Main entry point — to understand what the code does
- Existing
.env.example— for environment variable documentation - Existing README (if any) — to preserve information that cannot be inferred from code
Step 2 — Draft the README
Include these sections in order:
# {project-name}
{One to three sentence description of what this is and why it exists}
## Requirements
{Runtime, language version, any system dependencies}
## Getting Started
{Exact commands to clone, install dependencies, configure, and run}
## Configuration
{Table of environment variables from .env.example: name, required/optional, description, default}
## Running Tests
{Exact command(s) to run the test suite}
## Architecture
{Optional: 2-4 sentences on the key design decisions. Link to docs/adr/ if it exists.}
## Contributing
{How to contribute: branch naming, PR process, running checks locally}
Only include a section if there is real content for it. Do not include placeholder text.
Step 3 — Accuracy Check
Every command in the README must be verified to actually work. If you cannot verify a command
because the environment is unavailable, mark it with # verify this command comment.
Step 4 — Write the File
Write (or overwrite) README.md at the project root. If updating, preserve sections that
contain manually curated content (e.g., architecture notes, contributing guidelines) and only
regenerate sections derived from code.
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 · 79 lines · 53 tokens per session scan A e02189f2cf69
write-readme is a skill published in the GitHub repository soulcodex/agentic (10 stars, last pushed 2d ago), licensed MIT. It adds 53 tokens to every session and 501 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
document-writer
Write or update technical documentation grounded in the real codebase. Use when the user asks for README, API docs, architecture guides, user guides, CONTRIBUTING docs, migration notes, or JSDoc/code comments, or wants technical docs rewritten into natural Chinese with correct terminology. Not for general prose…
documentation-and-adrs
Writes technical documentation and Architecture Decision Records. Use when creating READMEs, API docs, ADRs, or any documentation that needs to explain a system, a decision, or how to use something.
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.
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…