sova-update-docs
Skill3 starsChanged 4 days agoApache-2.0View on GitHub
Update all project documentation to match current code state. Portable across projects.
In this repository44 other files it gives its agents.
- AGENTS.mdAGENTS.md
- templates/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- templates/CLAUDE.mdCLAUDE.md
- dashboard-designSkill
- database-patternsSkill
- design-systemSkill
- design-tasteSkill
- issue-templateSkill
- sova-address-prSkill
- sova-after-mergeSkill
- sova-agent-readinessSkill
- sova-audit-instructionsSkill
- sova-debugSkill
- sova-develop-explainSkill
- sova-develop-fullSkill
- sova-developSkill
- sova-extract-knowledgeSkill
- sova-find-taskSkill
- sova-health-auditSkill
- sova-ingest-reviewSkill
- sova-integrate-prSkill
- sova-issueSkill
- sova-new-featureSkill
- sova-optimize-knowledgeSkill
- sova-prSkill
- sova-rearrange-commitsSkill
- sova-researchSkill
- sova-review-fullSkill
- sova-review-prSkill
- sova-reviewSkill
- sova-simplifySkill
- sova-specSkill
- sova-standupSkill
- sova-statusSkill
- sova-testSkill
- testing-patternsSkill
- visual-auditSkill
- dashboard-designSkill
- database-patternsSkill
- design-tasteSkill
- issue-templateSkill
- testing-patternsSkill
- visual-auditSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
14 rules. About 0 are common, 14 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈14
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 8
Ensure all documentation matches the current code state.
- Distinctive: line 24
Read the project's CLAUDE.md or AGENTS.md to understand documentation conventions and which files track counts.
- Distinctive: line 28
Run the project's actual count verification commands and compare against documented values.
- Distinctive: line 39
Search documentation files for count references and compare:
- Distinctive: line 56
Tests added/removed: verify test counts in all docs
- Distinctive: line 57
CLI commands changed: verify command lists and help text references
- Distinctive: line 58
Configuration changed: verify config docs, env var references, default values
- Distinctive: line 59
API endpoints changed: verify API references, request/response shapes
- Distinctive: line 61
Only check docs related to the changed code paths.
- Distinctive: line 66
Read the full current file
- Distinctive: line 68
Update only the factual content.
- Distinctive: line 101
Minimal changes: don't reorganize or reformat docs that aren't stale
- Distinctive: line 103
Scope-driven: only check docs related to changed code paths, not the entire project
- Distinctive: line 104
NEVER use emojis in any output
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Update Documentation
Ensure all documentation matches the current code state. Updates both git-tracked docs (committed) and local-only docs (e.g., CLAUDE.md files if gitignored).
Context: the arguments provided when this skill is invoked
Phase 1: Discover What Changed
# Find the base branch
BASE=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's@^refs/remotes/origin/@@')
BASE=${BASE:-main}
# Changed files on this branch (determines which docs to check)
CHANGED=$(git diff --name-only $(git merge-base HEAD origin/$BASE)..HEAD)
echo "$CHANGED"Read the project's CLAUDE.md or AGENTS.md to understand documentation conventions and which files track counts.
Phase 2: Verify Structural Counts
Run the project's actual count verification commands and compare against documented values. Adapt the commands below to the project's structure.
# Tests (Python): every tracked test file, wherever the layout keeps it (top-level
# tests/, per-app tests/ packages, or test files next to the code they cover)
TEST_COUNT=$(git ls-files -z '*test_*.py' '*_test.py' | xargs -0 grep -HcE '^[[:space:]]*(async )?def test_' | awk -F: '{s+=$NF}END{print s+0}')
# Tests (JS/TS)
# TEST_COUNT=$(find src \( -name '*.test.ts' -o -name '*.spec.ts' \) -exec grep -c 'it(\|test(' {} + 2>/dev/null | awk -F: '{s+=$2}END{print s+0}')Search documentation files for count references and compare:
for f in README.md CLAUDE.md AGENTS.md docs/*.md .claude/rules/*.md; do
[ -f "$f" ] && grep -niE '(tests|services|routers|templates|steps|commands|pages|modules|models|subcommands)[[:space:]]*:?[[:space:]]*[0-9][0-9,]*\+?|[0-9][0-9,]*\+?[[:space:]]*(tests|services|routers|templates|steps|commands|pages|modules|models|subcommands)' "$f"
doneAlso check the project's vision or roadmap doc, if AGENTS.md or README.md links one and it lives outside the paths above.
Flag any documented count that doesn't match the actual count.
Phase 3: Check Scope-Specific Docs
Based on which files changed, check related documentation:
- Source code structure changed (new files, renamed modules): verify architecture docs, module lists, project tree
- Tests added/removed: verify test counts in all docs
- CLI commands changed: verify command lists and help text references
- Configuration changed: verify config docs, env var references, default values
- API endpoints changed: verify API references, request/response shapes
Only check docs related to the changed code paths. Skip unchanged areas.
Phase 4: Apply Updates
For each stale doc:
- Read the full current file
- Identify the specific section(s) that need updating
- Update only the factual content; never rewrite prose
- Preserve the existing format and structure
Phase 5: Stage and Report
# Stage tracked docs only
git diff --name-only | grep '\.md$' | while read f; do
git ls-files --error-unmatch "$f" 2>/dev/null && git add "$f"
done
# Show what changed
git diff --cached --statReport what was updated:
## Docs Updated
### Tracked (will be committed)
- <file>: <what changed>
### No changes needed
- <file>Rules
- No approval gate: runs as an automated step
- Only update factual content: counts, lists, names, values. Never rewrite prose
- Idempotent: running twice produces no diff
- Two-tier staging: stage tracked docs; update local-only docs on disk without staging
- Minimal changes: don't reorganize or reformat docs that aren't stale
- Preserve structure: match existing format and section headers
- Scope-driven: only check docs related to changed code paths, not the entire project
- NEVER use emojis in any output
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

