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…
In this repository7 other files it gives its agents.
- capture-componentSkill
- digest-videoSkill
- no-visual-diffSkill
- pr-createSkill
- pr-feedbackSkill
- prior-artSkill
- pr-reviewSkill
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
- Distinctive: line 3
Use single hyphens (-), not em dashes (—).
- Distinctive: line 6
Never hand-edit CHANGELOG.md or files marked auto-generated.
- Distinctive: line 8
Follow the repo's conventions: check how the codebase already solves the same problem, and match it before adding a new pattern or …
- Distinctive: line 9
Verify technical guidance against current official documentation, internal documentation, or installed source and types.
- Distinctive: line 11
If the user rejects a hypothesis, STOP guessing - search the web or read more code.
- Distinctive: line 12
Prefer concrete code reads + web searches over speculative pattern-matching.
- Distinctive: line 13
Verify technical claims against source or official docs before asserting.
- Distinctive: line 16
Prefer concise prose over tables in audits and reports unless a table is clearly justified.
- Distinctive: line 18
Never put secrets/tokens inline in commands - use env vars or references.
- Distinctive: line 19
Treat memory as point-in-time context, not current truth.
- Very specific: line 24
When posting as me, read ~/VOICE.md for my writing style.
≈ “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.
Files
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.
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.

