agentleFS
Sign inStart free
electronxelectronx/wiredkits-free/skills/write-claude-md/SKILL.md

write-claude-md

Skill5 starsChanged 21 days agoMITView on GitHub

Write or tighten a CLAUDE.md for the current repo from what the code actually does. Use when asked to "write a CLAUDE.md", "set up Claude for this repo", "improve our CLAUDE.md", or when Claude keeps getting the same project conventions wrong.

  • Reads credentials

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    1. redamancy231-create/claude-skills★ 3same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository5 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    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:

    Read CLAUDE.md, .claude/CLAUDE.md and any nested CLAUDE.md files if present.

    line 12
  2. Very specific:

    Read README.md, CONTRIBUTING.md, and any AGENTS.md, .cursorrules or .github/copilot-instructions.md.

    line 13
  3. Distinctive:

    Conventions that are only habits: Read 3 to 5 recent, typical files in the main source folder and the tests next to them.

    line 22
  4. Distinctive:

    Run the test and lint commands once if they are cheap and safe, so you know they work as written.

    line 25
  5. Distinctive:

    Use this shape and drop any section that would be empty:

    line 29
  6. Very specific:

    Write instructions ("Use pnpm, not npm"), not descriptions ("The project uses pnpm").

    line 57
  7. Distinctive:

    Don't repeat what a linter already enforces, and don't paste config files.

    line 59
  8. Distinctive:

    Don't invent rules. If you think something should be a rule but the code doesn't follow it yet, put it under Suggestions in your reply, not …

    line 60
  9. Distinctive:

    Keep it under about 80 lines.

    line 61
  10. Distinctive:

    Write the file only after showing it, unless the user already asked you to just write it.

    line 71

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

Write a CLAUDE.md

A good CLAUDE.md is short and holds only what Claude can't work out quickly by reading the code: how to build and test, the rules the team actually enforces, and the traps. Every line costs context on every request, so a 60-line file that is all true beats a 300-line file that restates the README.

1. Check what exists

  • Read CLAUDE.md, .claude/CLAUDE.md and any nested CLAUDE.md files if present. You are improving them, not starting over.
  • Read README.md, CONTRIBUTING.md, and any AGENTS.md, .cursorrules or .github/copilot-instructions.md. Reuse what is still true.

2. Learn the project from the code, not from guesses

Find each of these and note the exact command or path. Skip any you can't confirm.

  1. Stack and layout. Languages, frameworks, package manager (look at lockfiles), monorepo tool, the top-level folders that matter.
  2. Commands. Install, dev server, build, test (all and a single file), lint, format, typecheck, migrations. Take them from package.json scripts, Makefile, justfile, pyproject.toml, Cargo.toml, CI workflow files. Prefer what CI runs.
  3. Conventions that are enforced. Linter and formatter configs, commit message rules (commitlint, PR templates), branch naming, required checks in CI.
  4. Conventions that are only habits. Read 3 to 5 recent, typical files in the main source folder and the tests next to them. Note naming, error handling, how modules are structured, test style and fixtures. Only keep a habit if you saw it at least three times.
  5. Traps. Generated files that must not be edited by hand, env vars needed to run anything, slow or flaky test suites, services that must be running, folders that look dead but aren't. Search for DO NOT EDIT, generated, .env.example, and TODO/FIXME comments that warn about something.

Run the test and lint commands once if they are cheap and safe, so you know they work as written. Never run deploy, release or migration commands against shared environments.

3. Write it

Use this shape and drop any section that would be empty:

# <Project name>

<One or two sentences: what this is and who uses it.>

## Commands
- Install: `...`
- Dev: `...`
- Test all: `...`  Single file: `...`
- Lint / format / typecheck: `...`

## Layout
- `src/api/` HTTP handlers; business logic lives in `src/core/`.
- ...

## Rules
- <Rule stated as an instruction, with the reason when it isn't obvious.>
- ...

## Watch out
- `src/gen/` is generated by `make gen`; edit the `.proto` files instead.
- ...

Writing rules:

  • Write instructions ("Use pnpm, not npm"), not descriptions ("The project uses pnpm").
  • One fact per line. No marketing, no history, no praise of the codebase.
  • Don't repeat what a linter already enforces, and don't paste config files.
  • Don't invent rules. If you think something should be a rule but the code doesn't follow it yet, put it under Suggestions in your reply, not in the file.
  • Keep it under about 80 lines. If a part of the repo has many rules of its own, put them in a nested CLAUDE.md in that folder instead.

4. Hand it over

Show the full file (or the diff, if one existed) and then, in at most five lines:

  • Commands you ran and whether they passed.
  • Anything you could not confirm and left out.
  • Suggestions for rules the team might want to adopt.

Write the file only after showing it, unless the user already asked you to just write it.

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