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 skills add fullymiddleaged/Clawness --skill user-docsgit clone --depth 1 https://github.com/fullymiddleaged/ClawnessWrote 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/fullymiddleaged/clawness/user-docs)<a href="https://agentmods.dev/skills/fullymiddleaged/clawness/user-docs"><img src="https://agentmods.dev/badge/skills/fullymiddleaged/clawness/user-docs/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/fullymiddleaged/clawness/user-docs"><img src="https://agentmods.dev/badge/skills/fullymiddleaged/clawness/user-docs.svg" alt="Reviewed on agentmods" width="80" 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.1 | $0.00119 | $0.01654 |
| Opus 5.5 | $0.00048 | $0.00662 |
| Sonnet 5.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 1mo 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.
- 1mo ago First seen · 141 lines · 119 tokens per session scan A f87df64b15db
user-docs is a skill published in the GitHub repository fullymiddleaged/Clawness (5 stars, last pushed 13d ago), licensed MIT. It adds 119 tokens to every session and 1,654 once invoked, about $0.0005 per session on Opus 5.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
linked-intent-dev
Guide for linked-intent development (LID). Consult for ALL code changes. Walks changes through a mode-aware six-phase workflow (HLD → LLD → EARS → intent-narrowing edge audit → tests-first → code) with mandatory stops between each phase. Bugs walk the arrow like any other change — no short-circuit. Enforces cascade…
update-lid
Configure or reconcile a project for linked-intent development (LID). Dispatches on project state — fresh bootstrap, append directives to an existing agent-instructions file (AGENTS.md or CLAUDE.md), add missing mode marker, reconcile convention drift, or run mode transitions. Invoked as /update-lid. For fresh…
lid-coach
Review a project's current linked-intent-development (LID) usage against LID's own principles and produce a prioritized report of recommendations for getting more out of the methodology. Invoke when the user runs /lid-coach, asks for a LID review, asks how they could use LID better, wants feedback on their LID setup…
arrow-maintenance
Navigation and audit overlay for linked-intent development. Use when working with docs/arrows/ — orienting via index.yaml, auditing spec-to-code coherence, detecting reverse orphans and drift, splitting/merging/renaming/re-parenting segments. Dual-mode: ambient guidance when the overlay is present…
map-codebase
Bootstrap LID in an existing (brownfield) codebase. Deep-reads every file in the declared scope, offers lens-based clustering options, generates skeleton LLDs/HLD/EARS bottom-up, then creates arrow docs and prompts the user to flesh out the skeletons. Token-intensive by design. Use when asked to map a codebase…
review-depth
Experimental declared review depth for linked-intent development. Use when a LID project's instruction file declares a review depth in prose (e.g. "Review depth - I review through LLD; below that, consolidate to one review") or the user asks to batch phase reviews, consolidate stops, or let go below a phase depth.…