readme-updater
Skill4 starsChanged 10 months agoMITView on GitHub
Update and reorganize README documentation based on codebase changes. Use when adding features, refactoring modules, updating APIs, or when documentation drifts from implementation.
8 other projects use a version of this.
Adopted by
Most recently taken up by
- u9401066/zotero-keepertheir own version, first seen Nov 8, 2026
- u9401066/pubmed-search-mcptheir own version, first seen Oct 20, 2026
- patterson-agents/clitheir own version, first seen Oct 13, 2026
- paperclipai/companiestheir own version, first seen Oct 8, 2026
- patterson-agents/skillstheir own version, first seen Aug 12, 2026
- u9401066/asset-aware-mcptheir own version, first seen May 6, 2026
Other versions8 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 8
- paperclipai/companies★ 910same name
- u9401066/pubmed-search-mcp★ 28same name
- u9401066/zotero-keeper★ 7same name
- u9401066/nsforge-mcp★ 4same name
- u9401066/template-is-all-you-need★ 3same name
- patterson-agents/cli★ 2same name
- patterson-agents/skills★ 0same name
- u9401066/asset-aware-mcp★ 0same name
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 repository6 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- changelog-generatorSkill
- code-reviewSkill
- implementation-reviewSkill
- llms-md-updaterSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
16 rules. 0 are common, 16 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
16
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
After implementing new features or modules
- Distinctive: line 15
When APIs or interfaces have changed
- Distinctive: line 16
Before releases to ensure docs match code
- Distinctive: line 17
When documentation has drifted from implementation
- Distinctive: line 62
Update sections in logical order (top-to-bottom)
- Distinctive: line 64
Add new sections where needed
- Distinctive: line 97
When reorganizing README content:
- Distinctive: line 100
Keep related items together: Don't scatter API docs across sections
- Distinctive: line 102
Code examples near relevant docs: Don't separate explanation from demonstration
- Distinctive: line 110
Check README for provider documentation
- Distinctive: line 111
Add Groq to supported providers list
- Distinctive: line 112
Add Groq-specific configuration if unique
- Distinctive: line 113
Update any provider count references
- Distinctive: line 119
Always preserve user's existing README style and voice
- Distinctive: line 120
Don't add sections that aren't warranted by actual code
- Distinctive: line 121
Verify examples actually work before including them
“Common” is measured: kept by at least 6 in 10 of the 3 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
README Updater
Analyze codebase changes and intelligently update README documentation to reflect current implementation.
When to Use
- After implementing new features or modules
- When APIs or interfaces have changed
- Before releases to ensure docs match code
- When documentation has drifted from implementation
- User says "update readme", "sync docs", "readme is stale"
Instructions
Step 1: Determine Change Scope
Identify what has changed since README was last accurate:
# Find when README was last modified
git log -1 --format="%h %s" -- README.md
# Get commits since README update
git log $(git log -1 --format="%h" -- README.md)..HEAD --oneline --no-merges
# See what files changed
git diff --name-only $(git log -1 --format="%h" -- README.md)..HEADStep 2: Spawn Analysis Sub-Agents
Deploy parallel sub-agents to analyze different aspects:
| Sub-Agent | Task |
| Structure Analyzer | Review current README structure, identify sections, assess organization |
| Codebase Scanner | Scan exports, public APIs, module structure, entry points |
| Change Detector | Compare README claims against current implementation |
| Example Validator | Verify code examples still compile/work |
Prompt each sub-agent with:
"Analyze [scope] and report findings relevant to README accuracy. Focus on public-facing APIs, usage patterns, and installation/setup procedures."
Step 3: Synthesize Findings
Aggregate sub-agent reports into:
- Outdated sections - Content that no longer matches implementation
- Missing documentation - New features/APIs not documented
- Reorganization needs - Structural improvements for clarity
- Broken examples - Code samples that need updating
Step 4: Apply Updates
- Update sections in logical order (top-to-bottom)
- Preserve existing accurate content
- Add new sections where needed
- Remove deprecated information
- Validate code examples compile
Output Format
# README Update Report
## Analysis Summary
[One paragraph overview of changes needed]
## Sections Updated
| Section | Change Type | Description |
|---------|-------------|-------------|
| Installation | Updated | New dependency added |
| API Reference | Added | New `createClient()` function |
| Examples | Fixed | Updated import paths |
## Sections Reorganized
[Describe any structural changes and rationale]
## Code Examples Validated
- [x] Quick start example
- [x] API usage example
- [ ] Advanced configuration (needs fix)
## Changes Applied
[Summary of edits made to README.md]Organization Guidelines
When reorganizing README content:
- Order by user journey: Installation → Quick Start → API → Configuration → Examples → Contributing
- Keep related items together: Don't scatter API docs across sections
- Progressive disclosure: Simple usage first, advanced options later
- Code examples near relevant docs: Don't separate explanation from demonstration
Example
Input: User says "update the readme, I just added the Groq provider"
Action:
- Scan for Groq-related files and exports
- Check README for provider documentation
- Add Groq to supported providers list
- Add Groq-specific configuration if unique
- Update any provider count references
Output: Updated README with Groq documentation + report of changes made
Notes
- Always preserve user's existing README style and voice
- Don't add sections that aren't warranted by actual code
- Verify examples actually work before including them
- Cross-reference with existing documentation patterns in codebase
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.

