From cf-powers
Inventories git changes after feature/fix/refactor completion to map updates needed in docs/, README, CHANGELOG, inline docs before PRs or marking done.
npx claudepluginhub cloudfieldcz/cf-powers --plugin cf-powersThis skill uses the workspace's default tool permissions.
Code without matching documentation rots into "what does this do?" within weeks. Catch drift the moment implementation finishes, while the change is still in your head.
Mandates invoking relevant skills via tools before any response in coding sessions. Covers access, priorities, and adaptations for Claude Code, Copilot CLI, Gemini CLI.
Share bugs, ideas, or general feedback.
Code without matching documentation rots into "what does this do?" within weeks. Catch drift the moment implementation finishes, while the change is still in your head.
Core principle: When code changes, the docs that describe it must change too — or you must say why not.
This is a soft gate. It surfaces affected docs and prompts the user. It does not block completion. The user decides: update now, defer, or skip.
Announce at start: "I'm using the documenting-changes skill to keep docs in sync."
Always run before:
finishing-a-development-branchSkip only when:
git diff <base>...HEAD --stat
git diff <base>...HEAD -- '*.md' # what's already covered
Answer:
For each change identified, walk all five layers:
| Layer | What to check |
|---|---|
docs/ | Architecture, guides, references, ADRs, plans |
README.md | Overview, install, quick-start, feature list (root + subdirectory READMEs) |
CHANGELOG.md / release notes | Entry under current/next version |
| Inline (JSDoc, TSDoc, docstrings, Go doc comments) | Signatures, parameter docs, examples at definition sites |
| Plugin/skill metadata | .claude-plugin/*, skills/*/SKILL.md description fields, version fields |
Each change resolves to exactly one of:
"Internal" alone is not a justification. "Refactored cache eviction in src/internal/cache.ts; no exported API, config, or behavior changed" is.
Documentation review for this work:
UPDATES NEEDED:
- docs/architecture.md — describe new event flow
- README.md — add "MyFeature" to feature list
- CHANGELOG.md — entry for v1.6.0
NEW DOCS:
- docs/guides/myfeature.md — usage guide for new MyFeature
INLINE:
- src/api/handler.ts — JSDoc on handleRequest() reflects new param
SKIPPED (internal-only):
- src/internal/cache.ts refactor — no public surface or behavior change
Update docs now (recommended), defer, or skip?
Wait for the user's choice.
TODO(docs) comment at the change site, or note "docs pending" in the CHANGELOG/PR body. Don't let it disappear.| Change type | Likely doc actions |
|---|---|
| New public API/CLI flag | UPDATE README + CHANGELOG + inline docstring; consider docs/ guide |
| New feature (user-facing) | CREATE docs/guides/.md + UPDATE README feature list + CHANGELOG |
| Behavior change of existing feature | UPDATE relevant docs/ page + CHANGELOG; check README quick-start |
| Renamed/removed export | UPDATE inline docs at new site + CHANGELOG (breaking?) + grep docs/ for old name |
| Bugfix (no behavior change beyond fix) | CHANGELOG entry; SKIP rest with justification |
| Internal refactor | SKIP all with one-line justification per affected module |
| New skill / plugin command | CREATE SKILL.md or command doc + UPDATE plugin manifest + CHANGELOG |
Skipping inline docs
grep for the symbol you changed and check the doc comment at its definition"I'll update docs in a follow-up PR"
Updating only docs/
README.md and inline docs still show old usage; users hit them firstVague justification for skip
New feature with no doc home
docs/guides/<name>.md and link from README, even if shortdocs/docs/Called by:
finishing-a-development-branch (Step 1.5) — between test verification and presenting merge/PR optionsverification-before-completion — completion claims include "docs reviewed"Independent invocation: Any time after a non-trivial change, even mid-work, to keep drift from accumulating.