dist/claude/plugins/dev-workflow/skills/documenting-code/SKILL.md
Update project documentation based on code changes. Use when the user asks to update docs, document behavior, add README content, or align docs with recent implementation changes. NOT for extracting session learnings or authoring ADRs (use learning-patterns) or code-quality feedback (use reviewing-code).
npx skillsauth add alexei-led/claude-code-config documenting-codeInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Scope: documentation files only. Not for session-learning extraction (use learning-patterns) or code-quality review (use reviewing-code).
Update project documentation to reflect current code state. Do not delete or overwrite existing docs without confirmation. If verification fails or required evidence is unavailable, report the failure instead of claiming docs are current.
Detect your capability from your tools, not from prose:
git diff). Work from the changed-file list the caller supplies, read the relevant code and existing docs, then emit the stale or missing docs as a proposal in the Reviewer Output contract at the end. Apply nothing; run nothing.Use TaskCreate / TaskUpdate to track these 4 phases:
Ask one question at a time:
Use a documentation subagent when available; otherwise inspect and update docs directly.
Task with engineer agent:
"Update documentation for this project.
## Your Task
1. Analyze current state:
- Run `git diff --name-only HEAD~5` for recent changes
- Find existing docs: `find . -name '*.md' -o -name 'doc.go'`
- Check project structure and dependencies
2. Scope: {user's choice from Step 1}
3. Update focus:
- Accurate function/method documentation
- README sections matching current state
- API endpoint documentation
- Architecture notes if significant changes
4. Verify:
- No broken links
- Code examples compile/run
- Markdown renders correctly
## Output Format
DOCUMENTATION UPDATE
====================
Updated:
- file.md (what changed)
- pkg/doc.go (added GoDoc)
Verified: All links valid, examples compile"
Write-capable role only — a read-only reviewer skips Phase 4 and uses the Reviewer Output contract instead.
Independent verification (do not trust the agent's self-report):
When describing parent verification, explicitly mention checking runnable code examples or documented commands when practical. If examples/commands cannot be run, state why.
git diff --stat to confirm files were actually changedIf no recent changes are found or documentation scope is unclear, ask the user what to document rather than generating speculative documentation.
Report using this format:
## Documentation Update
Updated:
- <file> — <one-line change summary>
Verified:
- git diff confirmed N files changed
- <check>: passed / skipped (<reason>)
Issues: <issue> or "none"
Read-only role only. You applied nothing and ran nothing — emit the stale or missing docs as a proposal:
## Proposed Changes
### Change 1: <brief description>
File: `path/to/doc`
Action: CREATE | MODIFY | DELETE
Code:
<the doc content, with enough surrounding context to locate it>
Rationale: <which code change makes this doc stale or missing>
tools
Use when planning, executing, checkpointing, finishing, or inspecting lightweight spec-driven work. Runs one task at a time using `.spec/` markdown files and the bundled `specctl` helper. NOT for broad product discovery beyond a short requirement interview. NOT for generic implementation planning that does not read or write `.spec/` files.
development
Simple web development with HTML, CSS, JS, and HTMX. Use when working with .html, .css, or .htmx files, web templates, stylesheets, or vanilla JS scripts. NOT for React/Vue/Angular (use writing-typescript) or Node.js backends.
tools
Idiomatic TypeScript development. Use when writing TypeScript code, Node.js services, React apps, or TypeScript design advice. Emphasizes strict typing, boundary validation, composition, fast feedback, behavior tests, and project-configured tooling. NOT for Go, Python, Rust, plain HTML/CSS/JS, or server-rendered templates (use writing-web).
tools
Idiomatic shell development for POSIX sh, Bash, Zsh, Fish, hooks, CI shell steps, and scriptable CLI glue. Use when writing or changing `.sh`, `.bash`, `.zsh`, `.fish`, `.bats`, shell functions, shell pipelines, CI `run:` shell bodies, or command-runner recipes. Emphasizes portability, quoting, safe filesystem/process handling, non-TUI CLI tools, ShellCheck, shfmt, Bats, and ShellSpec. NOT for Python, Rust, TypeScript, Go, web code, or GitHub Actions workflow/job/permissions semantics; use operating-infra.