agentleFS
Sign inStart free
gannonhgannonh/kata-code/.agents/skills/readme/SKILL.md

readme

Skill1 starsChanged 39 days agoMITView on GitHub

Write or rewrite a project README as plain factual documentation covering what the tool is, how to install and run it, what it touches, and how to undo it. Use when the user asks to create, write, rewrite, improve, or review a README, complains their README is too long, too marketing-heavy, or buries the install instructions, or says "make a README" / "fix my README".

32 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use favicon, build and 6 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.
  • cpiprintSkill

    favicon

    Generate favicons from a source image

    Also in 3 projects that use this

  • Microsoft AzureSkill

    build

    Build the TypeSpec Rust emitter from source. Run this after cloning the repo, after pulling changes, or when TypeScript source files have been modified.

    Also in 3 projects that use this

  • GitHubSkill

    refactor

    Surgical code refactoring to improve maintainability without changing behavior. Covers extracting functions, renaming variables, breaking down god functions, improving type safety, eliminating code smells, and applying design patterns. Less drastic than repo-rebuilder; use for gradual improvements.

    Also in 3 projects that use this

  • BlockSkill

    plan

    Draft a TDD, PRD, or lightweight plan in the conversation without committing it.

    Also in 3 projects that use this

  • GoogleSkill

    prototype

    Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.

    Also in 3 projects that use this

  • SentrySkill

    commit

    Create commit messages following Sentry conventions. Use when committing code changes, writing commit messages, or formatting git history. Follows conventional commits with Sentry-specific issue references.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 3 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 31 edited versions we read keep these.

  • 3

    Distinctive

    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. Distinctive:

    Facts over adjectives: Delete "powerful", "simple", "elegant", "blazing fast", "seamless".

    line 14
  2. Distinctive:

    One mention per fact: If install is documented in Install, do not repeat it elsewhere.

    line 16
  3. Very specific:

    Read what exists before asking anything: README.md, manifest (package.json, pyproject.toml, go.mod, Cargo.toml), LICENSE, top-level source …

    line 25
  4. Distinctive:

    Write the README using the rules above.

    line 38

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

Readme

A README documents a tool. It states what the tool does, shows it running, and explains how to install, use, and remove it. It never persuades. If the facts are good, they carry the README; if they need dressing up, that is a signal about the tool, not a writing problem.

Rules

  1. First line says what the thing is. Plain declarative sentence: "Backup for sqlite databases, scheduled by cron." No problem/solution framing, no pain narrative, no "Tired of X?". A reader should know what they are looking at in five seconds.
  2. Show a real invocation early. A command and its actual output beat any description. Copy from a real session, not an idealized one.
  3. Facts over adjectives. Delete "powerful", "simple", "elegant", "blazing fast", "seamless". State the mechanism instead: not "lightning-fast search" but "searches 100k files in ~50ms (ripgrep)".
  4. Say what it touches. Anything that runs code, registers hooks, writes files, or makes network calls gets stated next to the install command, along with how to disable or uninstall it. This is documentation of behavior, not a trust-building exercise.
  5. One mention per fact. If install is documented in Install, do not repeat it elsewhere. Repetition reads as selling.
  6. Collapse depth with <details>, don't cut it. Architecture notes, design rationale, and reference tables go inside <details> blocks with markdown inside (blank line after <summary>, blank line before </details>).
  7. No narrative voice. No "I built this because...", no "What I learned", no origin story, no philosophy section up top. If design rationale matters, put a short note in a collapsed section.
  8. Order follows use. What it is → Install → Usage/example → How it works → Reference/FAQ → License. A reader who wants to try the tool should never scroll past theory to find a command.

Workflow

1. Gather context silently

Read what exists before asking anything: README.md, manifest (package.json, pyproject.toml, go.mod, Cargo.toml), LICENSE, top-level source dirs. Infer name, language, install command, license.

2. Ask only what you can't infer

Batch remaining gaps into one round of questions, at most:

  • One sentence on what the tool does (if the code doesn't make it obvious)
  • A real command + output demonstrating it (or offer to run the tool to capture one)
  • Whether it runs shell commands/hooks, writes outside the project, or makes network calls

Skip any question the repo already answers.

3. Generate

Write the README using the rules above. Structure serves the content, not a fixed template — a tiny CLI needs a fraction of what a framework needs. No emoji unless existing content uses them. Badges only if the repo already has them or the user asks.

For rewrites: keep accurate content, fix violations below, preserve anything the current README already does well.

4. Self-review before finishing

ViolationFix
Opens with a question, pain point, or "Tired of X?"Replace with a plain statement of what the tool is
Problem/solution pitch structureState what the tool does; skip the pitch
Adjectives without numbers ("fast", "simple", "powerful")Replace with mechanism or measurement, or delete
Value repeated across sectionsKeep the first factual mention, delete rest
Touches/hooks/network behavior undocumentedDocument next to install, including uninstall
Same command documented in 3+ placesOne usage section
Origin story or philosophy above examplesMove to collapsed details or delete
Idealized example outputUse real captured output

Report which violations you found and fixed, so the user can veto intentional choices.

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.

Check your setup, free