Use before committing staged changes when you need to verify all related documentation is current - systematically checks README, CLAUDE.md, CHANGELOG, API docs, package metadata, and cross-references rather than spot-checking only obvious files
Systematically verifies all documentation is current before committing staged changes - checks README, CLAUDE.md, CHANGELOG, API docs, package metadata, and cross-references to prevent outdated docs from reaching production.
/plugin marketplace add thurstonsand/thurstons-claude-skills/plugin install project-management@thurstons-skillsThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Before committing staged changes, systematically verify ALL documentation that might reference those changes.
The problem: We naturally check the "obvious" doc (README.md) but miss CLAUDE.md, CHANGELOG, API documentation, package metadata, and cross-references in related docs.
Use this skill when:
Required trigger: Before every commit with functional changes.
This skill checks documentation consistency for STAGED changes only.
Do NOT stage additional files during this process. Only verify if documentation for your staged changes is current.
Follow this checklist in order. No skipping "obvious" items.
git diff --staged --name-only
git diff --staged
Note: What was added? Modified? What does it affect?
If nothing is staged: Stop. Tell user to stage their changes first, then return to this skill.
Check EVERY one that exists in the repo (no rationalization):
This list is not comprehensive. If the project has other documentation, check those too. Examples: TESTING.md, DEPLOYMENT.md, SECURITY.md, project-specific guides.
If a core doc doesn't exist: Note its absence but don't create it as part of this commit.
IMPORTANT: When you find a documentation file, read it in its entirety. Do not skim or spot-check - read the complete file to understand its full context and identify all potential references to your changes.
Check documentation specific to this project type:
For libraries/packages:
For web services:
For other projects:
docs/, documentation/, or similar directoriesConsistency check: If you find multiple related files (like package.json and README.md version numbers), verify they're consistent.
Search for files that might reference your changes:
# Search for direct feature name
grep -r "exact-feature-name" --include="*.md" --include="*.json"
# Search for related terms (if changing auth, search: auth, login, session)
grep -r "related-concept" --include="*.md" --include="*.json"
# Search for command names if you modified commands
grep -r "command-name" --include="*.md" --include="*.json"
Check cross-references:
Search depth limit: Check one level of cross-references. If doc A references feature B, check doc B. Don't recursively check doc B's references.
Update higher-level docs (README, package metadata, CHANGELOG) if your change:
Do NOT update higher-level docs if your change:
When in doubt: Check if a user relying on current high-level docs would be surprised by your change. Surprised = update needed.
For each outdated doc:
Stage updates after sweep: Note what needs updating during the sweep, then stage those documentation changes after you've completed the full checklist.
If you discover unrelated outdated docs during your sweep:
If you're thinking any of these, you're about to skip necessary docs:
| Rationalization | Reality |
|---|---|
| "It's just a small change" | Small changes break outdated examples. Check anyway. |
| "Nothing actually changed" | Even if smaller than expected, complete the sweep to verify consistency. |
| "If related docs existed, I'd know" | You don't know until you search. Search systematically. |
| "That file is technical config" | Plugin manifests ARE user-facing. Check them. |
| "User is waiting" | 3 minutes now saves 30 minutes debugging confusion later. |
| "I already checked the main README" | README ≠ all documentation. Follow the full checklist. |
| "Other skills wouldn't reference this" | They might. Search, don't assume. |
| "The change is in the code itself" | Code ≠ documentation. Users read docs, not your diff. |
| "I found unrelated outdated docs, I should fix those" | Note for later. Stay focused on staged changes. |
| "Found one issue, good enough" | One issue doesn't mean you're done. Complete the sweep. |
| "I'll just skim the file for relevant parts" | Skimming misses context. Read the entire file to catch all references. |
All of these mean: Continue with the systematic sweep.
Any red flag = Start over with full checklist.
Without systematic sweep:
With systematic sweep:
Before committing, have you:
git diff --staged)All checked? You're ready to commit or stage documentation updates.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.