agentleFS
jordanhubbardjordanhubbard/nanolang/skills/releasing/documentation/SKILL.md

releasing-documentation

Skill628 starsChanged 4 months agoApache-2.0View on GitHub

Bring README, CONTRIBUTING, the user guide and the roadmap current before a NanoLang release is tagged. Use when make release-docs-check names one of them, or when preparing a release by hand.

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    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:

    Do not expand it into API documentation.

    line 33
  2. Very specific:

    Add a Watch to WATCHES in check_documentation.py:

    line 51
  3. Very specific:

    Do not add a checking *algorithm* here.

    line 65

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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

Release gate: user-facing prose

Owned by ../SKILL.md, which defines the order this runs in.

make release-docs-check          # or: python3 skills/releasing/documentation/check_documentation.py

What it asks

One question per document: did what it describes change since the last tag, while it did not? If both moved, or neither did, there is nothing to report. The check is in ../lib/staleness.py; check_documentation.py is only the manifest of which document watches which paths.

It cannot tell you whether the prose is correct -- only that its subject moved and nobody looked. Judgment is the part that stays here.

When a document is named

Open it and ask what this release changed about what it claims.

README.md — I state what I am and how to run me. A new release document, a changed instruction set, or a changed CLI entry point can each make it wrong. Do not expand it into API documentation; that is what --help and the user guide are for.

CONTRIBUTING.md — the rules a contributor is held to, and the commands that enforce them. Check both halves. In 4.0 the rules were stale in substance (no mention of the verifier, fuzzing, or the measurement policy) while the commands were fine, which is the easier half to miss. If a gate exists in Makefile.gnu and is not named here, a contributor learns it by failing it.

userguide/ — lessons about the surface language. A parser, type checker, or lexer change can strand one. Every example must still compile and pass its shadow tests.

docs/ROADMAP.md — anything the release document says shipped must not still be listed as pending.

Adding an artifact

Add a Watch to WATCHES in check_documentation.py:

Watch(
    document="path/to/doc.md",
    describes=["src/thing.c", "docs/POLICY_*.md"],
    why="one sentence a releaser can act on at 2am",
)

A pattern without a wildcard matches by prefix, so src/nanoisa covers everything beneath it. Write why for the person the gate interrupts: it is read at the least patient moment of the release.

Do not add a checking algorithm here. If the question is new, it belongs in ../lib/.

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.