docs-sync
Skill7 starsChanged 17 days agoMITView on GitHub
Reconciles README, docs, CLAUDE.md, and agent prompts with what the code does.
46 other projects use a version of this.
Adopted by
Most recently taken up by
- julianosirtori/skillstheir own version, first seen Nov 8, 2026
- voyager67/AgentFieldkittheir own version, first seen Nov 8, 2026
- kekzl/imptheir own version, first seen Nov 7, 2026
- sunholo-data/ailangtheir own version, first seen Nov 6, 2026
- jackneil/claude-jackedtheir own version, first seen Nov 5, 2026
- yasik/agentlanetheir own version, first seen Nov 1, 2026
Used with
Projects with it also use tdd, code-review and 2 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
GoogleSkilltdd
Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.
Also in 4 projects that use this
GoogleSkillcode-review
Adversarial systems, concurrency, memory-model, and architecture code review protocol. Use this skill whenever asked to review code, PRs, diffs, or branches in Filament.
Also in 5 projects that use this
MicrosoftSkillhandoff
Compact the current conversation into a handoff document for another agent to pick up.
Also in 4 projects that use this
MicrosoftSkillrelease
Use ONLY when the user explicitly asks to cut/publish a Huabu desktop release or tag a version. Performs an outward action — bumps the version in apps/desktop/package.json, commits + annotated-tags vX.Y.Z, and pushes the branch + tag. That tag push auto-builds the macOS/Windows installers and publishes a GitHub Release. Provides `status`, `bump`, `tag-push`, and a one-command `run` (bump → tag-push).
Also in 3 projects that use this
Other versions46 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 46
- openai/openai-agents-python★ 31ksame name
- redis/node-redis★ 18ksame name
- redis/ioredis★ 15ksame name
- fossasia/visdom★ 10ksame name
- Kiln-AI/Kiln★ 5.3ksame name
- danielmeppiel/apm★ 4.2ksame name
- microsoft/apm★ 4.2ksame name
- openai/openai-agents-js★ 4ksame name
- pnp/powershell★ 912same name
- strands-agents/box★ 503same name
36 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 repository15 other files it gives its agents.
- askamaSkill
- cargo-toml-optimizationSkill
- clean-codeSkill
- clean-flutterSkill
- clean-rustSkill
- clean-shellSkill
- emulator-testingSkill
- maudSkill
- mcp-statelessSkill
- name-checkSkill
- ratatui-patternsSkill
- terminal-uxSkill
- todoSkill
- ux-patternsSkill
- webapp-testingSkill
The file
We split this skill into the rules it gives an agent
3 rules. 0 are common, 1 is distinctive, and 2 are very specific to this project.
0
Common
Most of the 36 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 33
Verify the executable bits: Every command, flag, env var, config key, and file path quoted in docs must exist.
- Very specific: line 36
Reconcile before the change counts as done, not after: Never leave the reconciliation diff uncommitted, and never ship a code commit …
- Distinctive: line 44
Leave media placeholders alone (ASCII art, screenshots, gif slots).
“Common” is measured: kept by at least 6 in 10 of the 36 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Docs Sync
Reconcile prose with code. Every claim in the docs must match what the code does today. Accuracy pass only; no restructuring.
Delegate by default: spawn the tech-writer agent with mode: reconcile (one per repo) and pass it the change description if the pass is scoped. Outside a tech-writer agent, run inline only for a single small doc; a tech-writer agent never hands the pass to another tech-writer. If that agent def is missing in this environment, run the pass inline rather than blocking or trying to create it; the agent is an optional context-saver, not a prerequisite.
Scope
README.md,wiki/,docs/*.md,CLAUDE.md/AGENTS.md(gitignored, still sync them).wiki/+README.mdare the default committed, user-facing docs.- Agent-visible prompt files that enumerate a tool's surface: the
plugin/,commands/,agents/dirs plus skill and agent prompt.md. A prompt that lists a tool's response fields or flags breaks silently when that surface changes, since the model keeps following it and reading fields that no longer exist. Sweep these on any output-shape or API change (field renames, dropped flags), alongsideREADMEanddocs. - Other repo-root docs (
CONTRIBUTING.md,SECURITY.md,.github/*.md, etc.) are in scope only for the parts that make code-derived claims (build/test commands, flags, supported versions). Pure-policy prose with no code claim (CODE_OF_CONDUCT.md, license text, a security-reporting address) is out of scope, same reasoning as code comments below. - Not in scope: code comments (including doc-comments like docstrings, JSDoc, rustdoc; those track code but are the code author's surface, not a doc file), CHANGELOG/release notes (a release-notes convention owns those), README section structure (a readme convention owns that), and bare copyedits (a typo or wording fix carrying no code-derived claim needs a plain edit, not a reconciliation pass).
Procedure
Never run this from a worktree. git worktree add checks out tracked files only; gitignored docs/, CLAUDE.md, .claude/ exist in the main checkout alone, so a pass spawned into a worktree finds nothing to reconcile and reports a false clean. Run from the main checkout. A spawned agent that must not write the main checkout (spawned-agent write bans, unrelated edits the main session owns) works read-only against it: it reads the main-checkout docs, produces the corrected text as a patch (diff -u) or wrong->right pairs, and the main session applies them; a spawned agent never edits a main-checkout path.
- Explore code first, docs second. Build the real feature/flag/command surface from source. For large repos, fan out subagents per subsystem and collect claims.
- Diff claims against reality. For each doc statement, classify: accurate / stale / missing / overpromising.
- Fix:
- Stale → correct it to current behavior.
- Missing feature → add the minimum line that covers it.
- Overpromising (doc describes what code doesn't do) → delete or rewrite. Never leave aspirational claims; if it reads like a roadmap item, flag it to the user instead of silently keeping it.
- Verify the executable bits. Every command, flag, env var, config key, and file path quoted in docs must exist. Run
--helpor search the source (rg) rather than trusting the old text. - Check paraphrases, not just quotes. A README that paraphrases (rather than quotes) a changed description defeats a text search. Diff the frontmatter/source text itself and check the paraphrase still covers what the new wording foregrounds.
- Pin dropped names so the sweep can't be forgotten. Agent-visible strings compiled into source count too: retiring a tool or flag leaves them green and wrong. Pin the dropped names in a retired-names const with a test that scans every rendered string for them, so the check runs on its own instead of relying on memory.
- Reconcile before the change counts as done, not after. Never leave the reconciliation diff uncommitted, and never ship a code commit without a matching docs commit.
wiki//READMEupdates land as a follow-updocs:commit.
Style Rules
- Edit and shorten over adding. Collapse feature lists, merge near-duplicate sections, cut filler. Net diff should trend negative unless real features were missing.
- A deletion sweep needs a repo-wide reference search first. Before removing a heading, a documented flag/symbol/path, or a whole file, search the repo (
rg) for inbound references and resolve every hit: update the referencing doc, or keep a stub. Never leave a dangling pointer. - Merging near-duplicates: diff each copy against the source, never against each other. The authoritative-looking copy (a design doc, anything marked locked) drifts hardest, since nothing re-reads a settled doc against code, so deleting the scruffy duplicate promotes its wrong claims to sole truth. A doc's self-asserted verification (
e2e-verified,tested,both states compile) is unfalsifiable prose: search for the test before you trust it or delete it. - Match the doc's existing voice and formatting, except wrapping: a paragraph you rewrite goes on one line; this is a sync, not a rewrite.
- Leave media placeholders alone (ASCII art, screenshots, gif slots); the user replaces those manually.
- Version numbers: only touch ones the code/Cargo.toml/pyproject contradicts.
- A minimum-version claim belongs to the API surface it was measured on. Upstream states a floor per surface. A program calling a second, newer surface inherits the newer floor, and the old number keeps reading as verified in every doc that copied it. Check which surface upstream attaches the number to, then check every surface the code calls. Where upstream states no floor for one of them, name the source of whatever number you ship.
- A durable doc names its artifact, never points at one. "the old X",
HEAD~3, "the previous wording" rot the moment anything lands after them. Quote the literal string, or pin an immutable ref (sha/tag) that still resolves in a year. - A dated record reconciles against its own date, never today's code. Release notes and applied audit rows describe a past state. Rewriting one to match current code destroys the record; every check still reads green. Before touching a citation inside a dated artifact,
git show <sha>:<path>as of the date it claims. Leave it standing if it was true then, and note separately that the file is since gone. docs/todo.mdcarries OPEN work only. A landed item gets propagated into its owning test or doc, then deleted. Never restated as a shipped record.
Output
Report a short reconciliation list, one bullet per fixed claim:
<file>: said X, code does Y →<what changed>
Plus a separate flagged list for anything ambiguous (intentional roadmap? feature half-built?) that needs a user call.
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.

