Update docs
Use when a ticket requires documentation to reflect a change — a README, API reference, changelog, or runbook — or when an acceptance criterion says "document X". Invoke for "update the docs for the new endpoint", "add a changelog entry", or "the README is now wrong".From its SKILL.md
npx -y skills add tmj-90/gaffer --skill update-docsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
1.8 KB, 332 tokens by cl100k_base, as published. Nobody here has run it
Update the docs
Bring documentation back in line with the code. Keep it accurate and matched to the repo's existing docs structure — don't spawn a parallel doc system.
Steps
- Find the source of truth and the docs that reference it. Identify what changed
(a route, a config key, a CLI flag, a schema) and locate every doc that describes it:
README,
docs/, API reference, changelog, inline examples. - Read the lore if the change touches a convention —
search_lore(Memory MCP) for docs/style conventions (changelog format, where API docs live, voice). - Update only what the change affects. Correct commands, signatures, payloads, and examples so they match the code exactly. Add a changelog entry in the repo's format if one exists. Don't rewrite unrelated sections.
- Verify the examples are real — run any documented command or sample request and confirm it produces what the doc claims. Fix drift you find.
- Evidence: the changed doc files and (where applicable) the command output proving an
example works. Then use the
record-evidenceskill (diff_summary) and submit for review.
Rules
- Docs must match the code exactly; verify commands and examples actually run.
- Edit existing docs in place; don't introduce a new docs framework or location.
- Keep scope tight — only the sections the change touches.
- Run on a branch (the
create-branchskill), never a protected branch.
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.
Gives 0 of the 12 instructions most readme changelog skills give in 332 tokens
Counted across 472 of the 478 authors here whose files we hold, read 2026-08-07
- Follow the keep a changelog formatin 31 of 472, across 26 files
- Run from the git repository rootin 20 of 472, across 7 files
- Save output directly to CHANGELOG.mdin 20 of 472, across 7 files
- Group commits into logical categoriesin 19 of 472, across 6 files
- Review the generated changelog before publishingin 19 of 472, across 6 files
- Omit empty sectionsin 19 of 472
- Apply changelog guidelines and brand voicein 18 of 472, across 5 files
- Exclude internal commits like refactoring and testsin 18 of 472, across 5 files
- Specify date ranges for focused changelogsin 17 of 472, across 4 files
- Convert technical commits into customer languagein 17 of 472, across 4 files
- Provide a migration guide for breaking changesin 15 of 472, across 10 files
- Group commits by conventional commit typein 13 of 472
Said here and by no other author read
- identify the code change and locate referencing docs
- search lore for documentation style conventions
- update affected commands, signatures, payloads, and examples
- add a changelog entry in the repo's format
- verify documented commands or sample requests run correctly
- fix any drift found in the documentation
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.