agentleFS
Sign inStart free
voyager67voyager67/AgentFieldkit/skills/docs-sync/SKILL.md

docs-sync

Skill0 starsChanged 13 days agoMITView on GitHub

Bring documentation, examples, and configuration guides into agreement with the actual code. Use after behavior changes or when instructions may have drifted.

46 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use tdd, code-review and 2 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.
  • GoogleSkill

    tdd

    Test-driven development. Use when the user wants to build features or fix bugs test-first, mentions "red-green-refactor", or wants integration tests.

    Also in 4 projects that use this

  • GoogleSkill

    code-review

    Adversarial systems, concurrency, memory-model, and architecture code review protocol. Use this skill whenever asked to review code, PRs, diffs, or branches in Filament.

    Also in 5 projects that use this

  • MicrosoftSkill

    handoff

    Compact the current conversation into a handoff document for another agent to pick up.

    Also in 4 projects that use this

  • MicrosoftSkill

    release

    Use ONLY when the user explicitly asks to cut/publish a Huabu desktop release or tag a version. Performs an outward action — bumps the version in apps/desktop/package.json, commits + annotated-tags vX.Y.Z, and pushes the branch + tag. That tag push auto-builds the macOS/Windows installers and publishes a GitHub Release. Provides `status`, `bump`, `tag-push`, and a one-command `run` (bump → tag-push).

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

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

  • 0

    Common

    Most of the 36 edited versions we read keep these.

  • 9

    Distinctive

    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:

    Verify every claim against current code, tests, or executable commands.

    line 11
  2. Distinctive:

    Update the smallest set of docs that fully explains user-visible behavior: what changed, how to use it, constraints, errors, and migration …

    line 12
  3. Distinctive:

    Prefer runnable examples. When appropriate, execute code snippets or use a documentation build/test command.

    line 13
  4. Distinctive:

    Ensure defaults, environment variable names, flags, paths, supported versions, and output formats match implementation.

    line 14
  5. Distinctive:

    Remove obsolete instructions without deleting important historical migration context.

    line 15
  6. Distinctive:

    Check links and headings using existing tools if available.

    line 16
  7. Distinctive:

    Never invent capabilities, performance numbers, release dates, or guarantees.

    line 22
  8. Distinctive:

    Do not write documentation that claims an implementation is complete when it remains partial.

    line 23
  9. Distinctive:

    Avoid duplicating a large block of source documentation into several pages.

    line 24

“Common” is measured: kept by at least 6 in 10 of the 36 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

Documentation Sync

Procedure

  1. Find documentation entry points, API references, README instructions, examples, tutorials, CLI help, config samples, and changelog conventions.
  2. Verify every claim against current code, tests, or executable commands. Flag references that cannot be verified.
  3. Update the smallest set of docs that fully explains user-visible behavior: what changed, how to use it, constraints, errors, and migration steps.
  4. Prefer runnable examples. When appropriate, execute code snippets or use a documentation build/test command.
  5. Ensure defaults, environment variable names, flags, paths, supported versions, and output formats match implementation.
  6. Remove obsolete instructions without deleting important historical migration context.
  7. Check links and headings using existing tools if available. Do not introduce new dependencies just for a minor documentation check.

Deliverable

Summarize changed pages and cite checks actually run. Explicitly state any external links you could not validate.

Boundaries

  • Never invent capabilities, performance numbers, release dates, or guarantees.
  • Do not write documentation that claims an implementation is complete when it remains partial.
  • Avoid duplicating a large block of source documentation into several pages; prefer one canonical explanation.

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.

Reviews can't be read right now.

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.

Check your setup, free