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 DanielC000/loom --skill loom-doc-hygienegit clone --depth 1 https://github.com/DanielC000/loomWrote 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/danielc000/loom/loom-doc-hygiene)<a href="https://agentmods.dev/skills/danielc000/loom/loom-doc-hygiene"><img src="https://agentmods.dev/badge/skills/danielc000/loom/loom-doc-hygiene.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.1 | $0.00064 | $0.00809 |
| Opus 5 | $0.00032 | $0.00404 |
| Sonnet 5 | $0.00013 | $0.00162 |
| Haiku 4.5 | $0.00006 | $0.00081 |
Grade A, and why
loom-doc-hygiene 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 8d 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 — 30 lines — stays where its author put it; the contents beside it link to each section on GitHub.
doc-hygiene
Rules to apply on every documentation edit. Docs are a living source of truth, not an append-only log. A reader should be able to trust that what a doc says now is what is true now.
Rules
-
No contradictions. A document must not assert two things that cannot both be true. Before adding a statement, scan the surrounding doc for anything it conflicts with and reconcile them in the same edit.
-
Rewrite in place — never append "UPDATE:" notes. When information becomes outdated, debunked, or false, edit the original sentence/section to be correct. Do not leave the stale text and bolt on "UPDATE:", "EDIT:", "Note (2026):", "
struck-throughnow actually…", or a trailing correction. Replace the wrong content with the right content as if it had always been right. (Git history preserves what changed — the doc itself should read clean.) -
Tidy loose ends. Resolve dangling references, half-finished sentences, TODOs that are now done, and links to things that moved or were deleted. If a section is now empty or redundant, remove it.
-
Keep docs bounded. Don't let a doc grow without limit. Prefer revising existing sections to adding new ones. Consolidate duplicated explanations into one canonical place and link to it. Length should track the size of the subject, not the number of times it was touched.
-
Shallow, stable structure for a notes collection. In a multi-note vault/docs tree, keep a one-level folder taxonomy — don't pile notes flat, and don't nest deeply. Fixed-path / canonical docs (ones referenced by exact path — a resume log, a note a
CLAUDE.mdpins by path) stay at the collection root; every other note lives in a taxonomy folder. Maintain an_Index.mdmap-of-content at the root: read it to locate a note instead of Globbing, and update it when you add or move one. -
One line per paragraph — never hard-wrap prose. Write each paragraph, list item, or table row as a single physical line and let the editor soft-wrap it. Do not insert manual line-breaks to hold prose to a column width (~80/100 chars). Hard-wrapping fights the one-line-per-block model editors like Obsidian assume, produces noisy reflow diffs when a sentence is later edited, and re-wraps unpredictably across viewers. Deliberate markdown breaks are still fine — a blank line between blocks, or a trailing
\/ two trailing spaces for an intentional hard break — but column-width wrapping is not.
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.
- 8d ago First seen · 30 lines · 64 tokens per session scan A ba3a0f0effab
loom-doc-hygiene is a skill published in the GitHub repository DanielC000/loom (7 stars, last pushed yesterday), licensed MIT. It adds 64 tokens to every session and 809 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
holon-runtime-ops
Operate and diagnose Holon runtimes with metadata-only patrol reports, incremental error analysis, and sanitized bug escalation.
github-review
Review a GitHub pull request by collecting GitHub context, applying evidence-backed review rules, and optionally publishing one review.
ops
Operate servers and services with read-only-first diagnosis, explicit authorization, auditable inventory, operation records, rollback, and verification.
github-pr-fix
Fix a GitHub pull request by addressing feedback or CI failures, pushing changes, and publishing replies.
session-summary
You summarise ONE work-burst of a developer's coding-agent session. The goal is to capture what the developer actually worked on, and why it mattered, so that a PM, a teammate, or the developer themselves can immediately understand the purpose and the outcome at a glance — without reading the transcript.
reduce
Use when asked to simplify, clean up, tidy, or refactor code for clarity without changing what it does, or when the user says "simplify this", "clean this up", "make it readable", "reduce the complexity", or "tidy this". Behavior-preserving only; not a bug or security audit (use bug-hunt or security-sweep for those).