Claude-skill-registry docs-check
Documentation check checkpoint for conductor gates. Analyzes code changes to determine if documentation needs updating. Returns structured result with pass/fail status and documentation suggestions.
install
source · Clone the upstream repo
git clone https://github.com/majiayu000/claude-skill-registry
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/docs-check" ~/.claude/skills/majiayu000-claude-skill-registry-docs-check && rm -rf "$T"
manifest:
skills/data/docs-check/SKILL.mdsource content
Docs Check Checkpoint
Documentation checkpoint that verifies docs are up-to-date with code changes.
What This Skill Does
- Analyzes what changed in the code
- Identifies documentation-relevant changes
- Checks if corresponding docs exist and are current
- Suggests documentation updates if needed
- Writes result to checkpoint file
Workflow
Step 1: Get Changed Files
# For uncommitted changes git diff --name-only HEAD git diff --name-only --cached # For branch diff git diff --name-only main...HEAD
Step 2: Categorize Changes
Identify what type of changes were made:
| Change Type | Documentation Impact |
|---|---|
| New API endpoint | API docs needed |
| New CLI command | Usage docs needed |
| Config schema change | Config docs needed |
| Breaking change | Migration guide needed |
| New feature | README/feature docs |
| Bug fix | Usually no docs needed |
| Refactor (no API change) | No docs needed |
Step 3: Check Existing Documentation
Look for docs that might need updates:
# Common doc locations ls README.md CHANGELOG.md docs/ *.md 2>/dev/null # API docs ls docs/API.md docs/api/ swagger.yaml openapi.yaml 2>/dev/null # Check if changed files have corresponding docs # e.g., if routes/api.js changed, check docs/API.md
Step 4: Analyze Documentation Gaps
For each significant change, check:
- API changes - Is there API documentation? Does it cover new endpoints?
- Config changes - Are new config options documented?
- Breaking changes - Is there a migration guide?
- New features - Is the feature documented for users?
- CHANGELOG - Is there a changelog entry?
Step 5: Create Structured Result
{ "checkpoint": "docs-check", "timestamp": "2026-01-19T12:00:00Z", "passed": true, "changes_analyzed": 5, "suggestions": [ { "type": "api", "file": "docs/API.md", "message": "New endpoint POST /api/spawn should be documented", "priority": "high" }, { "type": "changelog", "file": "CHANGELOG.md", "message": "Consider adding changelog entry for new feature", "priority": "medium" } ], "summary": "2 documentation suggestions. None are blocking." }
Result Fields:
: true if no critical documentation missingpassed
: number of changed files analyzedchanges_analyzed
: array ofsuggestions{type, file, message, priority: "high"|"medium"|"low"}
: brief human-readable summarysummary
Step 6: Write Checkpoint File
mkdir -p .checkpoints cat > .checkpoints/docs-check.json << 'EOF' { "checkpoint": "docs-check", ... } EOF
Decision Criteria
Pass if:
- No critical documentation gaps
- Minor suggestions are acceptable
Fail if:
- Breaking changes without migration guide
- New public API without documentation
- README claims features that don't exist
Suggestion priorities:
: Should be documented before mergehigh
: Should be documented soonmedium
: Nice to have, not blockinglow
Documentation Patterns to Check
API Changes
If files like
routes/*.js, api/*.ts, endpoints/* changed:
- Check
or similardocs/API.md - Look for OpenAPI/Swagger specs
- Verify new endpoints are documented
Configuration Changes
If files like
config.js, .env.example, settings.json changed:
- Check README configuration section
- Verify new options are documented
- Check for breaking config changes
CLI Changes
If argument parsing or command files changed:
- Check
output accuracy--help - Verify README usage section
- Check man pages if applicable
Breaking Changes
Indicators of breaking changes:
- Removed or renamed exports
- Changed function signatures
- Modified config schema
- Database migration files
CHANGELOG
For any user-visible change:
- Should have CHANGELOG entry
- Entry should mention issue ID if applicable
- Breaking changes should be clearly marked
Example Usage
When invoked as
/docs-check:
Running Docs Check checkpoint... Analyzing changed files... Found 8 changed files: - backend/routes/api.js (modified) - backend/modules/spawn-handler.js (new) - extension/hooks/useSpawn.ts (new) - README.md (modified) - docs/API.md (not modified) Checking documentation coverage... API changes detected: - New endpoint: POST /api/spawn - docs/API.md does not document this endpoint New feature detected: - Spawn functionality added - README.md was updated (good!) Result: { "passed": true, "suggestions": [ { "type": "api", "file": "docs/API.md", "message": "Document POST /api/spawn endpoint", "priority": "high" } ], "summary": "1 high-priority suggestion: API docs need update" } Checkpoint result written to .checkpoints/docs-check.json
Files to Always Check
| Project Type | Doc Files |
|---|---|
| Node.js | , , , |
| Python | , , , |
| Rust | , , |
| Go | , , |
Notes
- This checkpoint is advisory by default (suggestions don't block)
- For strict projects, configure to fail on high-priority suggestions
- Always check CHANGELOG for any user-visible changes
- Breaking changes MUST have documentation before merge