agentleFS
xsovad06xsovad06/sova/.agents/skills/sova-update-docs/SKILL.md

sova-update-docs

Skill3 starsChanged 4 days agoApache-2.0View on GitHub

Update all project documentation to match current code state. Portable across projects.

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
  1. Distinctive:

    Ensure all documentation matches the current code state.

    line 8
  2. Distinctive:

    Read the project's CLAUDE.md or AGENTS.md to understand documentation conventions and which files track counts.

    line 24
  3. Distinctive:

    Run the project's actual count verification commands and compare against documented values.

    line 28
  4. Distinctive:

    Search documentation files for count references and compare:

    line 39
  5. Distinctive:

    Tests added/removed: verify test counts in all docs

    line 56
  6. Distinctive:

    CLI commands changed: verify command lists and help text references

    line 57
  7. Distinctive:

    Configuration changed: verify config docs, env var references, default values

    line 58
  8. Distinctive:

    API endpoints changed: verify API references, request/response shapes

    line 59
  9. Distinctive:

    Only check docs related to the changed code paths.

    line 61
  10. Distinctive:

    Read the full current file

    line 66
  11. Distinctive:

    Update only the factual content.

    line 68
  12. Distinctive:

    Minimal changes: don't reorganize or reformat docs that aren't stale

    line 101
  13. Distinctive:

    Scope-driven: only check docs related to changed code paths, not the entire project

    line 103
  14. Distinctive:

    NEVER use emojis in any output

    line 104

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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"
done

Also 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:

  1. Read the full current file
  2. Identify the specific section(s) that need updating
  3. Update only the factual content; never rewrite prose
  4. 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 --stat

Report 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

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.