agentleFS
DGouronDGouron/review-flow/.claude/skills/update-docs/SKILL.md

update-docs

Skill42 starsChanged 6 months agoMITView on GitHub

Update documentation after code changes. Scans git diff to find affected docs and updates them for consistency.

87 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use get-pr-reviews, push-everything and 10 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.
  • saffron-healthSkill

    get-pr-reviews

    Get nicely formatted output of the last review comments on a PR. Used internally by other skills.

    Also in 3 projects that use this

  • saffron-healthSkill

    push-everything

    Stage ALL changes in the repository (not just session changes), commit, and push. Use when you need to commit all pending changes.

    Also in 3 projects that use this

  • TheKREATORSSkill

    instinct-export

    Export instincts from project/global scope to a file

    Also in 3 projects that use this

  • TheKREATORSSkill

    instinct-import

    Import instincts from file or URL into project/global scope

    Also in 3 projects that use this

  • NVIDIASkill

    generate-spec

    Produce a feature specification covering API changes, backward compatibility, cross-language impact, performance, and a file-level change plan. Use when designing a new feature, planning a significant change, or the user asks to spec something out.

    Also in 3 projects that use this

  • belokonmSkill

    fullstack-developer

    End-to-end feature expert specializing in frontend-backend integration, system architecture, and complete application development

    Also in 4 projects that use this

  • +1 more from saffron-health
  • +1 more from TheKREATORS

The file

We split this skill into the rules it gives an agent

12 rules. 0 are common, 7 are distinctive, and 5 are very specific to this project.

  • 0

    Common

    Most of the 81 edited versions we read keep these.

  • 7

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read .claude/roles/documentalist.md — adopt this profile and follow all its rules.

    line 17
  2. Distinctive:

    Search for those terms in the doc content

    line 43
  3. Distinctive:

    Read the entire doc and the modified source code

    line 61
  4. Distinctive:

    Update only the affected sections

    line 62
  5. Distinctive:

    NEVER add content that exists in another doc — link instead

    line 63
  6. Very specific:

    Update last-updated in the frontmatter

    line 64
  7. Very specific:

    Verify that related entries are up to date (add new files if needed)

    line 65
  8. Very specific:

    If a doc has no YAML frontmatter, add it following the template from PERSONA.md.

    line 69
  9. Distinctive:

    Do not translate existing French docs unless explicitly requested

    line 87
  10. Distinctive:

    Do not restructure an entire doc — modify only what is affected

    line 88
  11. Very specific:

    If a doc is massively obsolete, recommend /audit-docs first

    line 89
  12. Distinctive:

    Always keep the existing structure unless it violates the template

    line 90

“Common” is measured: kept by at least 6 in 10 of the 81 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

Update Documentation

Activation

This skill activates for:

  • Updating docs after a code change
  • Synchronizing documentation with the current code state
  • /update-docs

Persona

Read .claude/roles/documentalist.md — adopt this profile and follow all its rules.

Workflow

Step 1: Identify Code Changes

# Default: last 5 commits. The user can specify a range.
git diff --name-only HEAD~5

Filter relevant files (ignore: tests, configs, lock files).

Step 2: Map Changes to Docs

Two strategies, in this order:

Strategy A — Frontmatter related (priority):

# Read the frontmatter of each doc
Glob docs/**/*.md
# Look for modified files in the `related` field

Strategy B — Keyword search (fallback):

  • Extract entity/module names from modified files
  • Search for those terms in the doc content
  • E.g., if mcpServerStdio.ts changed, search for "mcp", "server", "stdio" in docs

Step 3: Evaluate Impact

For each potentially affected doc:

QuestionIf Yes
Has the documented behavior changed?Update required
Has a documented API/interface changed?Update required
Only internal implementation changed?No update needed
Has a new concept appeared?Suggest /create-doc

Step 4: Update

For each doc to modify:

  1. Read the entire doc and the modified source code
  2. Update only the affected sections
  3. NEVER add content that exists in another doc — link instead
  4. Update last-updated in the frontmatter
  5. Verify that related entries are up to date (add new files if needed)

Step 5: Add Missing Frontmatter

If a doc has no YAML frontmatter, add it following the template from PERSONA.md. This is a progressive migration — no need to do everything at once.

Step 6: Report

List the modifications made:

## Docs Updated

| File | Changes | Reason |
|------|---------|--------|
| docs/MCP-TOOLS-REFERENCE.md | Updated tool parameters | mcpServerStdio.ts changed |
| docs/ARCHITECTURE.md | No update needed | Internal refactor only |

Rules

  • Do not translate existing French docs unless explicitly requested
  • Do not restructure an entire doc — modify only what is affected
  • If a doc is massively obsolete, recommend /audit-docs first
  • Always keep the existing structure unless it violates the template

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.