agentleFS
mmurakarummurakaru/skills/CLAUDE.md

skills

CLAUDE.md0 starsChanged 6 days agoMITView on GitHub

- Use single hyphens (-), not em dashes (—). - In long Markdown, put each sentence on its own line; keep normal Markdown structure. - Commits use the user's identity only - no Co-Authored-By, Signed-off-by, or Claude/Anthropic trailers. - Never hand-edit CHANGELOG.md or files marked auto-generated. - Favor quality, simplicity, robustness, scalability, and long-term maintainability over development cost. - Follow the repo's conventions: check how the codebase already solves the same problem, and match it before adding a new pattern…

The file

We split this CLAUDE.md into the rules it gives an agent

11 rules. About 0 are common, 10 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈10

    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
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Use single hyphens (-), not em dashes (—).

    line 3
  2. Distinctive:

    Never hand-edit CHANGELOG.md or files marked auto-generated.

    line 6
  3. Distinctive:

    Follow the repo's conventions: check how the codebase already solves the same problem, and match it before adding a new pattern or …

    line 8
  4. Distinctive:

    Verify technical guidance against current official documentation, internal documentation, or installed source and types.

    line 9
  5. Distinctive:

    If the user rejects a hypothesis, STOP guessing - search the web or read more code.

    line 11
  6. Distinctive:

    Prefer concrete code reads + web searches over speculative pattern-matching.

    line 12
  7. Distinctive:

    Verify technical claims against source or official docs before asserting.

    line 13
  8. Distinctive:

    Prefer concise prose over tables in audits and reports unless a table is clearly justified.

    line 16
  9. Distinctive:

    Never put secrets/tokens inline in commands - use env vars or references.

    line 18
  10. Distinctive:

    Treat memory as point-in-time context, not current truth.

    line 19
  11. Very specific:

    When posting as me, read ~/VOICE.md for my writing style.

    line 24

≈ “Common” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.md 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
CLAUDE.md

General Guidelines

  • Use single hyphens (-), not em dashes (—).
  • In long Markdown, put each sentence on its own line; keep normal Markdown structure.
  • Commits use the user's identity only - no Co-Authored-By, Signed-off-by, or Claude/Anthropic trailers.
  • Never hand-edit CHANGELOG.md or files marked auto-generated.
  • Favor quality, simplicity, robustness, scalability, and long-term maintainability over development cost.
  • Follow the repo's conventions: check how the codebase already solves the same problem, and match it before adding a new pattern or abstraction.
  • Verify technical guidance against current official documentation, internal documentation, or installed source and types. Match the version in use.
  • If the user rejects a hypothesis, STOP guessing - search the web or read more code. Don't go in circles on AX-tree, DOM, or framework internals.
  • Prefer concrete code reads + web searches over speculative pattern-matching.
  • Verify technical claims against source or official docs before asserting; cite a source for stats and root causes, and state confidence.
  • In PR reviews, verify each finding via source/permalinks, keep only essential nits, and never post comments or approvals until explicitly authorized.
  • Flag only code-review issues with concrete repro or real impact - no hedged "latent bug" findings.
  • Prefer concise prose over tables in audits and reports unless a table is clearly justified.
  • Comments: one line max, WHY only when non-obvious; if it needs more than a line, rename instead.
  • Never put secrets/tokens inline in commands - use env vars or references.
  • Treat memory as point-in-time context, not current truth. Verify against current files before relying on it; if it conflicts with what you observe, trust observation and update or remove the stale memory.

Opinions & Voice

  • For tasks that benefit from my viewpoints, read ~/OPINIONS.md.
  • When posting as me, read ~/VOICE.md for my writing style.

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.