agentleFS
26zl26zl/universal-agent-skills/skills/docs-consolidation/SKILL.md

docs-consolidation

Skill2 starsChanged 39 days agoMITView on GitHub

Keep project documentation in a small set of canonical files; extend an existing document instead of creating a new Markdown file, and merge overlapping documents rather than adding another. Use when writing, updating, or reorganizing documentation, or when a task would create a new .md file such as a summary, notes, plan, or per-feature guide; do not use to merge files a convention requires to stand alone, such as README, LICENSE, CHANGELOG, or generated references.

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 6 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Every documentation topic gets one canonical home.

    line 9
  2. Distinctive:

    Before creating any documentation file, check whether the README or an existing document already covers the topic.

    line 13
  3. Distinctive:

    Create a new file only when the user asks for one or the content serves a clearly distinct audience or lifecycle, such as an API reference …

    line 14
  4. Very specific:

    Never leave unrequested working files in the repository: summaries, notes, plans, implementation reports, and task lists belong in the …

    line 15
  5. Distinctive:

    Do not duplicate instructions across files.

    line 16
  6. Distinctive:

    When existing documents overlap, merge them into the canonical one, delete the leftovers, and update inbound links.

    line 17
  7. Very specific:

    Keep conventional standalone files as they are: README, LICENSE, CONTRIBUTING, CHANGELOG, SECURITY, CODE_OF_CONDUCT, and generated …

    line 18
  8. Distinctive:

    Before finishing, list every documentation file the change adds.

    line 23

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

Docs Consolidation

Every documentation topic gets one canonical home. A reader should find setup, usage, or design in one predictable place, not reconstruct it from a pile of overlapping Markdown files.

Rules

  • Before creating any documentation file, check whether the README or an existing document already covers the topic. Extend that document instead.
  • Create a new file only when the user asks for one or the content serves a clearly distinct audience or lifecycle, such as an API reference next to a contributor guide.
  • Never leave unrequested working files in the repository: summaries, notes, plans, implementation reports, and task lists belong in the conversation, not in SUMMARY.md, NOTES.md, PLAN.md, or similar files.
  • Do not duplicate instructions across files. Link to the canonical section instead of restating it.
  • When existing documents overlap, merge them into the canonical one, delete the leftovers, and update inbound links.
  • Keep conventional standalone files as they are: README, LICENSE, CONTRIBUTING, CHANGELOG, SECURITY, CODE_OF_CONDUCT, and generated documentation.
  • Match documentation size to the change: a small feature earns a section, not a document tree.

Review

Before finishing, list every documentation file the change adds. Each one must be explicitly requested or justified by a distinct audience; fold anything else into an existing document and remove the extra file.

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.