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/fullymiddleaged/clawness/user-docsnpx skills add fullymiddleaged/Clawness --skill user-docsgit clone --depth 1 https://github.com/fullymiddleaged/ClawnessWhat 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.00119 | $0.01654 |
| Opus 5 | $0.00060 | $0.00827 |
| Sonnet 5 | $0.00024 | $0.00331 |
| Haiku 4.5 | $0.00012 | $0.00165 |
Grade A, and why
user-docs 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 — 141 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Write user documentation from the codebase
Good docs describe what the software actually lets someone do. This skill builds that picture from the code — the UI screens and the public API/CLI — then writes it up to a known modern standard, kept brief.
Two audiences, one standard. Software usually needs one or both:
- End-user docs — for the person using the product. Driven by the UI: screens, buttons, forms, settings. Non-technical, task-first.
- Developer docs — for someone integrating with or extending it. Driven by the public API/CLI/config: exports, endpoints, commands, flags, env vars.
Both are structured with Diátaxis — the framework Django, Cloudflare, and Gatsby use — and written in Google-style prose (second person, active voice, present tense, sentence-case headings, short sentences).
Say this before you start writing. This can produce a lot of files and it takes a
while. Whether the user typed /clawness:user-docs or you reached for this skill on
your own, the discipline is the same: scan, propose an outline, and stop for approval
before writing anything. Never author a docs tree uninvited.
Argument
/clawness:user-docs [end-user|dev] — which audience to document. With no argument,
detect what the project has (a UI, a public API/CLI, or both) and ask which to produce.
You can do both — run the flow once per audience.
The standard
Structure every page by its Diátaxis mode, and keep one mode per page:
| Mode | Answers | Shape |
|---|---|---|
| Tutorial | "get me started" | one guided first task, end to end |
| How-to guide | "how do I do X" | numbered imperative steps for one real task |
| Reference | "what is X exactly" | exhaustive, consistent, look-up-able |
| Explanation | "why does it work this way" | a concept and its rationale |
Never blend a tutorial with reference on one page — the reader is there for one thing. For an existing product, weight the effort toward how-to guides and reference; add explanation only where a concept genuinely needs it.
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 · 141 lines · 119 tokens per session scan A f87df64b15db
user-docs is a skill published in the GitHub repository fullymiddleaged/Clawness (3 stars, last pushed 3d ago), licensed MIT. It adds 119 tokens to every session and 1,654 once invoked, about $0.0006 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
self-assessment
Interactive skill assessment with personalized learning path generation.
project-life
Единый скилл ведения задач и жизни проекта: идеи/туду → планы/roadmap → раны → артефакты → прогресс/уроки. Use when user says info, справка, lane-stack:project-life info, туду, запиши, идея, backlog, потом, план, спланируй, планируем, пока план, не запускай, обсудим, roadmap, этапы, приоритеты, прогресс, урок, итоги …
lane-memory
SMA-style project fact corpus under .agents/memory/. Opt-in via adoc stages.memory.enabled. Use when user says память, lane-memory, corpus, CORE, почему бот забыл, or an agent needs durable non-code facts. Not PROGRESS/LESSONS dumps.
git-release
Draft release notes from merged PRs, propose a semver bump, and emit a copy-pasteable gh release create command. Use when preparing a tagged GitHub release.
post-mortem-learning
Analyze failures and suboptimal deliveries to identify root causes, contributing factors, and raw lessons. Activate after significant delivery failures, repeated QA failures, or when patterns of issues need to be understood.
ticket-compound
Compound-engineering capture + curation for a finished ticket — the engineering feedback loop. Harvests the Friction sections that phase agents left in their artifacts plus the git diff, writes a structured entry to the shared learnings store (thoughts/shared/learnings/), prunes/amends stale notes there autonomously…