repo-docs
Skill36 starsChanged 17 days agoBSD-3-ClauseView on GitHub
Where a fact belongs in this repo's docs, and the shape each file expects - README tools reference, generated token-cost blocks, MIGRATING, CLAUDE.md and DEVELOPING.md. Use when documenting a tool, parameter or response field, or when a doc figure no longer matches the code.
16 other projects use a version of this.
Adopted by
Most recently taken up by
- teacupuk/tpstacktheir own version, first seen Nov 8, 2026
- korya/swd-skillstheir own version, first seen Nov 1, 2026
- ndthanhdev/aiotheir own version, first seen Oct 25, 2026
- bsene/skillstheir own version, first seen Oct 25, 2026
- rohanhong/tmpl.general-repotheir own version, first seen Oct 11, 2026
- OneDro1d/dark-factorytheir own version, first seen Oct 8, 2026
Other versions16 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 16
- YurunChen/repo-docs-skills★ 457same name
- IndelibleVivi/repo-docs-curator★ 10same name
- phanghonghao/THU-Awesome-Skills★ 8same name
- vbonk/repo-template★ 8same name
- bsene/skills★ 7same name
- OneDro1d/dark-factory★ 4same name
- rohanhong/tmpl.general-repo★ 3same name
- korya/swd-skills★ 2same name
- IsthisLee/agent-context-manager★ 1same name
- IsthisLee/agentic★ 1same name
6 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository3 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- changelog-entrySkill
- lean-mcp-toolsSkill
The file
Files
Repo docs
Voice comes from the developer-writing skill. This skill says which file a fact belongs in and
what shape that file expects. Changelog entries have their own rules - use changelog-entry.
One fact, one file
| Fact | File |
| What a tool returns, its parameters, its response fields | README.md, Tools Reference |
| What a 1.x caller must change | MIGRATING.md |
| What a reader of the released package can see changed | CHANGELOG.md (changelog-entry skill) |
| The rules every change follows, and how to build and release | DEVELOPING.md - rules only, no evidence |
| Why code is the way it is: a measurement, a rejected alternative | a doc comment on that code |
| How Salesforce behaves, tested in an org | .claude/rules/<topic>.md, dated, with the issue link; the code links to it |
| What a contributor or agent needs before touching the code | CLAUDE.md |
| Why a budget number is what it is | the comment beside it in scripts/eval.mjs |
Response-shaping policy never reaches the wire: not a .describe(), not a tool description. It is a
contributor fact.
README shape, per tool
The Tools Reference gives each tool, in this order:
- One paragraph of what it answers and what it is best for - the served tool description in README voice, not a copy of it.
- The generated
shape-<tool>block: every response field and its columns. - Hand-written prose for what the block cannot say - what a column means, what makes one conditional, what an extra table joins to.
- The generated
params-<tool>block.
A new parameter regenerates its own row. Write prose for it only if it changes what the rows carry.
Generated blocks - never hand-edit
README.md holds these blocks between markers, all written by the eval run:
token-cost-summary- the line on what keeping the server connected coststoken-cost-definitionsandtoken-cost-answers- the two token tablestoken-cost-v1-tools- what the tools that replaced 1.x's cost nowparams-<tool>- the parameter table, from the schema the client is served, for every toolshape-<tool>- the response fields, from the fixture the figures are measured against, for the analysis tools only
pnpm run build && pnpm run eval:update regenerates them with the goldens. pnpm run eval fails
when they drift, so a hand edit is a CI failure, not a saving.
The prose around those tables is hand-written and does not regenerate - the paragraph naming
what the unsliced 19.7 MB sample log costs is measured with
node scripts/eval.mjs --report <log> and has to be re-measured by hand when a response shape
moves. It is the one figure in the file nothing checks.
Figures in prose
Any figure a reader can check must match the code: percentages against 1.x, token counts, corpus
sizes, row caps such as NAME_LIMIT and the page budget. When a change moves one, grep the docs for
the old number before you commit - README.md, CLAUDE.md and MIGRATING.md quote them, and so
do doc comments in src/.
MIGRATING
One section per thing a 1.x caller must do, each with a mapping table where the change is a rename, and a sentence naming what to grep for in their own prompts, agents and skills. No rationale - that is the changelog's job and the issue's.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.