agentleFS
Sign inStart free
ZeeshanSultanZeeshanSultan/DocGov/skills/affected/SKILL.md

affected

Skill0 starsChanged 2 months agoMITView on GitHub

Analyze which documents a code change affects and produce the documentation change manifest — required updates, optional updates, and the PR-ready review comment. Use before committing, when opening a PR, or for "what docs do I need to update".

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 0 are distinctive, and 1 is 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.

  • 1

    Very specific

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

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

    For a PR,: run docgov checklist --pr and post the output as a comment.

    line 27

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

Change impact

Impact and manifest

!docgov affected --json --compact $ARGUMENTS 2>&1 | head -c 10000

What to do

  1. Report the required list first. Entries with required: true and updated: false are the work. Everything else is context. Lead with the short list of files the user actually has to touch.
  2. Update them. For each, read the document, find the part the change invalidates, and make the minimal correct edit. Do not rewrite a document because one sentence is wrong.
  3. Write the manifest with docgov checklist. It lands in .docgov/checklist.yaml as a deterministic checklist that survives across sessions and CI — and is deleted after merge. Use it rather than holding the list in your head.
  4. For a PR, run docgov checklist --pr and post the output as a comment. It states the code impact, the documentation impact, what is covered and what is outstanding.
  5. If a required document genuinely does not need updating, say why, explicitly, in the PR comment or the commit message. "No documentation change needed because the refactor preserved the documented behaviour" is a legitimate answer. Silence is not.

Signals worth reacting to

  • securityChanged — the security architecture and threat model are almost always affected and almost always forgotten. Check them specifically.
  • apiChanged without a contract change — either the contract is now wrong, or the change was internal and the signal is a false positive. Work out which.
  • behaviorChanged without testsChanged — not a documentation problem, but worth saying out loud once.

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