agentleFS
ProviderProtocolProviderProtocol/ai/.claude/skills/readme-updater/SKILL.md

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

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
  1. Distinctive:

    After implementing new features or modules

    line 14
  2. Distinctive:

    When APIs or interfaces have changed

    line 15
  3. Distinctive:

    Before releases to ensure docs match code

    line 16
  4. Distinctive:

    When documentation has drifted from implementation

    line 17
  5. Distinctive:

    Update sections in logical order (top-to-bottom)

    line 62
  6. Distinctive:

    Add new sections where needed

    line 64
  7. Distinctive:

    When reorganizing README content:

    line 97
  8. Distinctive:

    Keep related items together: Don't scatter API docs across sections

    line 100
  9. Distinctive:

    Code examples near relevant docs: Don't separate explanation from demonstration

    line 102
  10. Distinctive:

    Check README for provider documentation

    line 110
  11. Distinctive:

    Add Groq to supported providers list

    line 111
  12. Distinctive:

    Add Groq-specific configuration if unique

    line 112
  13. Distinctive:

    Update any provider count references

    line 113
  14. Distinctive:

    Always preserve user's existing README style and voice

    line 119
  15. Distinctive:

    Don't add sections that aren't warranted by actual code

    line 120
  16. Distinctive:

    Verify examples actually work before including them

    line 121

“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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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)..HEAD

Step 2: Spawn Analysis Sub-Agents

Deploy parallel sub-agents to analyze different aspects:

Sub-AgentTask
Structure AnalyzerReview current README structure, identify sections, assess organization
Codebase ScannerScan exports, public APIs, module structure, entry points
Change DetectorCompare README claims against current implementation
Example ValidatorVerify 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:

  1. Outdated sections - Content that no longer matches implementation
  2. Missing documentation - New features/APIs not documented
  3. Reorganization needs - Structural improvements for clarity
  4. Broken examples - Code samples that need updating

Step 4: Apply Updates

  1. Update sections in logical order (top-to-bottom)
  2. Preserve existing accurate content
  3. Add new sections where needed
  4. Remove deprecated information
  5. 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:

  1. Scan for Groq-related files and exports
  2. Check README for provider documentation
  3. Add Groq to supported providers list
  4. Add Groq-specific configuration if unique
  5. 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

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.