agentleFS
aws-samplesaws-samples/sample-apex-skills/skills/update-docs/SKILL.md

update-docs

Skill93 starsChanged 20 days agoMIT-0View on GitHub

Audit and update every documentation surface in the APEX repo against the current state of skills, steering workflows, README marker tables, and the Docusaurus site under misc/website/. After any change to a skill (rename, retire, add, edit description), walk the repo, re-run script-managed surfaces if their --check fails, and reason through every tracked prose *.md to catch references that need updating. Use after adding/removing/renaming a skill, after editing SKILL.md frontmatter, after editing README marker blocks, or before publishing a docs change. Also use when the user says "update docs", "sync docs", "check docs", "run update-docs", or mentions that documentation might be stale.

87 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use get-pr-reviews, push-everything and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • saffron-healthSkill

    get-pr-reviews

    Get nicely formatted output of the last review comments on a PR. Used internally by other skills.

    Also in 3 projects that use this

  • saffron-healthSkill

    push-everything

    Stage ALL changes in the repository (not just session changes), commit, and push. Use when you need to commit all pending changes.

    Also in 3 projects that use this

  • TheKREATORSSkill

    instinct-export

    Export instincts from project/global scope to a file

    Also in 3 projects that use this

  • TheKREATORSSkill

    instinct-import

    Import instincts from file or URL into project/global scope

    Also in 3 projects that use this

  • NVIDIASkill

    generate-spec

    Produce a feature specification covering API changes, backward compatibility, cross-language impact, performance, and a file-level change plan. Use when designing a new feature, planning a significant change, or the user asks to spec something out.

    Also in 3 projects that use this

  • belokonmSkill

    fullstack-developer

    End-to-end feature expert specializing in frontend-backend integration, system architecture, and complete application development

    Also in 4 projects that use this

  • +1 more from saffron-health
  • +1 more from TheKREATORS

The file

We split this skill into the rules it gives an agent

6 rules. 0 are common, 3 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 81 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Before opening a PR that touches skills/

    line 15
  2. Distinctive:

    If the user specifies a different scope ("since my last commit", "just the rename I did"), adjust the base accordingly.

    line 32
  3. Very specific:

    Run both --check commands.

    line 43
  4. Distinctive:

    Read each file in the candidate set below.

    line 47
  5. Very specific:

    Every skills/<name>/README.md where present

    line 66
  6. Distinctive:

    Always end with a summary table:

    line 94

“Common” is measured: kept by at least 6 in 10 of the 81 edited versions of this file we could read. “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 Docs

Walk the APEX repo after any content change and bring every documentation surface back into sync. Two categories of surface exist: script-managed (deterministic, re-runnable) and prose (requires reasoning). Handle both in a single pass.

When to use

  • A skill was added, removed, renamed, or had its frontmatter edited
  • A runbook under skills/apex/runbooks/ was added, removed, or renamed
  • README marker blocks were edited manually
  • Before opening a PR that touches skills/
  • The user asks to "check docs", "update docs", or "sync documentation"

Modes

Coding-agent mode (default in Claude Code): walk the repo, re-run scripts, propose diffs, ask before writing user-facing prose. Auto-apply mechanical fixes (script outputs, simple name substitutions in fenced code blocks).

Chat-only mode (no file-write tools available): emit the PASS/STALE table + a fix checklist of one-line commands. No file edits.

Step 1: Detect the change set

Determine what changed. Default comparison base is origin/main:

git diff --name-status origin/main...HEAD -- 'skills/**/SKILL.md' 'skills/apex/runbooks/*/*.md' 'devops-agent/**'

If the user specifies a different scope ("since my last commit", "just the rename I did"), adjust the base accordingly. Also include any paths the user explicitly names.

Step 2: Tier 1 — Script-managed surfaces

Two scripts own deterministic regeneration. Detect staleness and re-run them. Never duplicate their logic.

SurfaceStale whenFix
Marker blocks (README.md, skills/README.md)./misc/update-all-references.sh --check exits non-zero./misc/update-all-references.sh
Docusaurus wrappers, manifest, skills index./misc/update-pages.sh --check exits non-zero./misc/update-pages.sh

Run both --check commands. If either exits non-zero, re-run the corresponding script. In coding-agent mode, apply the changes directly. In chat-only mode, emit the fix command.

Step 3: Tier 2 — Prose ripple

Read each file in the candidate set below. Hold the change set in mind and look for stale references.

What "stale" looks like

  • A skill name in prose that no longer matches a skills/<name>/ directory
  • A frontmatter description that was edited, where the old phrasing still appears verbatim elsewhere
  • A retired runbook still referenced in a list
  • A skill count or coverage claim ("APEX ships six skills") that no longer matches reality
  • A path link skills/old-name/ after a rename
  • A removed or renamed concept still mentioned in contributor guidance

Candidate set (tracked files only — use git ls-files)

In scope:

  • README.md
  • CONTRIBUTING.md
  • CODE_OF_CONDUCT.md
  • THIRD_PARTY_NOTICES.md
  • skills/README.md
  • Every skills/<name>/README.md where present
  • Every skills/<name>/SKILL.md
  • Every skills/apex/runbooks/<skill>/*.md
  • devops-agent/README.md
  • Every devops-agent/<name>/SKILL.md
  • misc/README.md
  • misc/evals/README.md
  • misc/evals/_template/README.md
  • Every misc/evals/<skill>/README.md
  • misc/website/docs/intro.md
  • misc/website/docs/getting-started.md
  • misc/website/src/components/skillCatalog.ts and misc/website/src/pages/index.tsx (not markdown; skillCatalog.ts holds each skill's catalogue lines, index.tsx names the /apex router)
  • The SKILL_META table in misc/update-pages.sh (each skill's page title and summary, under 160 characters)

Excluded (generated by scripts — never hand-edit):

  • misc/website/docs/skills/*.md
  • misc/website/docs/skills/index.md
  • misc/website/static/manifests/skills.json
  • misc/website/static/llms.txt
  • misc/website/docs/skills/eks/index.md
  • misc/website/docs/skills/ecs/index.md

For each file, if you find stale content:

  • In coding-agent mode: propose the diff. For user-facing prose changes, ask before applying. For mechanical substitutions (path renames in code fences, skill-name swaps in lists), apply directly.
  • In chat-only mode: add to the checklist with file, line, and what to change.

Step 4: Final output

Always end with a summary table:

| Surface | Status | Action taken | Confirm? |
|---|---|---|---|
| Marker blocks | PASS | — | — |
| Docusaurus wrappers | STALE | Re-ran ./misc/update-pages.sh | — |
| README.md | STALE | Proposed diff | yes (line 42 prose) |
| CONTRIBUTING.md | PASS | — | — |
| skills/README.md | PASS | — | — |
| misc/evals/*/README.md | PASS | — | — |
| ... | | | |

Status values: PASS (no changes needed), STALE (changes applied or proposed), SKIP (file doesn't exist yet).

Rows marked Confirm? yes require the user's approval before the change is final. Wait for their response before moving on.

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.