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 mushroomTW/MushroomTW-Skills --skill excellent-project-docsgit clone --depth 1 https://github.com/mushroomTW/MushroomTW-SkillsWrote 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/mushroomtw/mushroomtw-skills/excellent-project-docs)<a href="https://agentmods.dev/skills/mushroomtw/mushroomtw-skills/excellent-project-docs"><img src="https://agentmods.dev/badge/skills/mushroomtw/mushroomtw-skills/excellent-project-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/mushroomtw/mushroomtw-skills/excellent-project-docs"><img src="https://agentmods.dev/badge/skills/mushroomtw/mushroomtw-skills/excellent-project-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.00168 | $0.03504 |
| Opus 5 | $0.00084 | $0.01752 |
| Sonnet 5 | $0.00034 | $0.00701 |
| Haiku 4.5 | $0.00017 | $0.00350 |
Grade A, and why
excellent-project-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 yesterday.
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 — 163 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Excellent Project Docs
A repository's documentation is a hub and its satellites. The README is the hub: an entry point, not a complete manual, that helps the reader decide “Is this for me?” and reach a first success without reading source code. Companion documents — CONTRIBUTING.md, SECURITY.md, ARCHITECTURE.md, and the others in companion-documents — are satellites: each holds one topic that would bloat the README, and the README links to it. Put disqualifying prerequisites and limitations early; helping a non-fit reader leave quickly is success.
Work modes
First identify the requested outcome:
- Create: the target document does not exist; build a first draft from repository facts.
- Improve: preserve correct content while fixing structure, clarity, gaps, and drift. Prefer in-place edits. 🔴 CHECKPOINT before a full rewrite of any existing document: inventory its unique content and wait for explicit approval; without it, edit in place.
- Audit: do not edit first; report evidence, problems, risks, and priority-ordered recommendations across the whole document set.
- Synchronize: update facts affected by code or configuration changes in every document that states them; treat drift as functional damage.
If the user does not specify a mode, default to “improve and verify.” If the user names no document, the README is the target and companion documents enter only through the proposal checkpoint in step 3. Unless explicitly requested, do not turn any document into a complete documentation website.
Treat translated variants as one document: update every variant you can write accurately and report any divergence. For new variants use BCP 47 names (README.zh-TW.md, CONTRIBUTING.zh-TW.md) with English in the base file; preserve an established repository naming scheme.
Invariants
- Evidence first: gather facts from the repository before writing. Never invent features, commands, versions, environment variables, deployment methods, performance numbers, badges, screenshots, license details, contribution rules, security contacts, or release history.
- Reader-led: order information around the reader's decisions, not the author's implementation order. The top of the README must independently explain the project's purpose and smallest useful path; the top of each companion document must state its one topic and who it is for.
- Cognitive funnel: move from broad to specific: one-line purpose → minimal runnable example → installation → configuration and limitations → API or architecture details → contribution, license, and acknowledgements. Once a stage outgrows the README, it moves to a companion document and the README keeps a summary plus a link.
- Runnable: commands must trace to repository files, scripts, CLI help, or tests. Run examples that need no network, credentials, paid services, dependency installation, or data changes. Otherwise 🔴 CHECKPOINT for authorization; absent approval means
unrun, never passed. - Single source of truth: one fact lives in one file. The README does not restate a companion document, a companion document does not restate the README's quick start, and neither copies information that readers can directly inspect in the environment and that is likely to drift. Use prose for background, rationale, limitations, and workflows that the files do not reveal.
- Right-sized: candidate sections and candidate companion documents are options, not a completeness score. Keep small projects to a README; add companion documents only when the evidence in companion-documents justifies each one.
- Propose, then create: a companion document the user did not name is created only after the user approves it at the step 3 checkpoint. A document the user named is handled directly.
- Honest gaps: 🔴 CHECKPOINT and ask before choosing a license, contribution channel, security contact, code-of-conduct standard, or roadmap. If nobody can answer, omit the section or document and report the question; never ship
TODO:. State adoption-relevant absences (for example, no LICENSE) as facts, not placeholders. Omit rather than invent.
What ships with it
6 files 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.
- yesterday First seen · 163 lines · 168 tokens per session scan A 4e1eaafc8c68
excellent-project-docs is a skill published in the GitHub repository mushroomTW/MushroomTW-Skills (0 stars, last pushed 2d ago), licensed MIT. It adds 168 tokens to every session and 3,504 once invoked, about $0.0008 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-09-12.
Other skills, from other repositories
a-philosophy-of-software-design
Apply John Ousterhout-inspired software design rules when reducing complexity, designing module boundaries, or reviewing APIs and abstractions.
brooks-sweep
Full-sweep mode: runs a unified analysis across all quality dimensions — code decay, architecture, tech debt, and test quality — then applies fixes directly to the codebase. Safe changes are auto-applied; risky changes are confirmed before execution. Drawing on twelve classic engineering books. Triggers when: user…
llm-friendly-context
Clarifies inputs, outputs, success criteria, decisions, and unresolved conditions so downstream consumers can execute without guessing. Use when writing or revising LLM-facing prompts, handoffs, planning artifacts, reviews, reports, or generated instructions.
ring:exploring-codebases
Exploring a codebase across phases: scopes the target, detects architecture, components, and layers, deep-dives each discovered perspective, then synthesizes findings into actionable guidance with file:line evidence. Use to understand how a feature or system works before planning changes, or to orient on an unfamiliar…
ring:mapping-feature-relationships
Mapping how features relate and phasing the work: categorizing PRD features, grouping them into domains, charting cross-feature journeys, dependencies, and integration points, and defining the binding Phases that plan.md mirrors one-to-one at Gate 7. Gate 2 of ring:planning-large-features; runs after…
megalinter-check
Collect MegaLinter lint errors for the current repository. Use when the user wants to know if the code passes linting, why the MegaLinter CI job fails, or before/after fixing lint errors. Two modes - watch a CI job (GitHub Actions, GitLab CI, Azure Pipelines, Bitbucket Pipelines) and parse its logs, or run MegaLinter…