Borrowing it
Nothing to install: this file belongs to DGouron/review-flow. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/DGouron/review-flow/master/.claude/skills/update-docs/SKILL.mdgit clone --depth 1 https://github.com/DGouron/review-flowWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/dgouron/review-flow/update-docs)<a href="https://agentmods.dev/skills/dgouron/review-flow/update-docs"><img src="https://agentmods.dev/badge/skills/dgouron/review-flow/update-docs/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/dgouron/review-flow/update-docs"><img src="https://agentmods.dev/badge/skills/dgouron/review-flow/update-docs.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00024 | $0.00591 |
| Opus 5.5 | $0.00010 | $0.00236 |
| Sonnet 5.5 | $0.00005 | $0.00118 |
| Haiku 4.5 | $0.00002 | $0.00059 |
Grade A, and why
update-docs scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 91 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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.tschanged, search for "mcp", "server", "stdio" in docs
Step 3: Evaluate Impact
For each potentially affected doc:
| Question | If 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:
- Read the entire doc and the modified source code
- Update only the affected sections
- NEVER add content that exists in another doc — link instead
- Update
last-updatedin the frontmatter - Verify that
relatedentries 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 |
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2mo ago First seen · 91 lines · 24 tokens per session scan A 5e21c3fdd62a
update-docs is a skill published in the GitHub repository DGouron/review-flow (44 stars, last pushed today), licensed MIT. It adds 24 tokens to every session and 591 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
release
Cut a brooks-lint release: set the version in package.json, propagate it across all four plugin manifests and every version-bearing text file (README badges, docs site metadata), write the CHANGELOG entry, validate, then commit, push, tag, and publish the GitHub release. Triggers when the maintainer asks to "release"…
address-review
Read PR review comments from GitHub, evaluate, address, and reply.
git-workflow
Git workflow and conventional commits. Use when working with git, branches, commits, pull requests, code review, or version control strategy.
code-review
Review PR, branch, commit or working-tree changes for concrete defects and fidelity to intended behavior. Also use when explicitly asked to independently challenge a prepared plan, diagnosis or verification claim.
workflow-pr-review
Use when reviewing a remote GitHub PR — a first-pass peer review, or a followup re-check after the owner has addressed feedback. Fetches into an ephemeral worktree, runs the reviewer agent against the updated diff with a Review Decision footer instruction, deduplicates findings against existing review threads (±5-line…
workflow-address-feedback
Use when a PR owner wants to address review feedback — fetches outstanding threads and general comments, presents a per-item triage (ADDRESSED / CLARIFIED / DEFERRED), applies fixes via the Edit tool, commits via workflow-commit-and-pr, resolves review threads via GraphQL resolveReviewThread (those without a thread…