coding-style
Skill2 starsChanged 36 days agoMITView on GitHub
Keep code comments and docstrings concise, neutral, human-authored in tone, and written in English unless another language is required. Use when writing, refactoring, or reviewing code where comments, identifiers, or docstrings may be added or changed; do not use to shorten required public API documentation, safety notes, or legal notices.
11 other projects use a version of this.
Adopted by
Most recently taken up by
- static-web-server/static-web-servertheir own version, first seen Nov 9, 2026
- thunderstormwang/AgentSkillstheir own version, first seen Nov 6, 2026
- els0r/skillstheir own version, first seen Oct 13, 2026
- AltraMayor/f3their own version, first seen Oct 8, 2026
- quarkusio/quarkustheir own version, first seen Oct 8, 2026
- RichieHakim/agent_skillstheir own version, first seen Oct 5, 2026
Other versions11 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 11
- quarkusio/quarkus★ 16ksame name
- AltraMayor/f3★ 3.4ksame name
- static-web-server/static-web-server★ 2.4ksame name
- codetesla51/skills★ 32same name
- Fuwn/suckless-agent-skills★ 18same name
- RichieHakim/agent_skills★ 5same name
- els0r/skills★ 1same name
- loboking/gemini-skills★ 1same name
- matejformanek/postgres-claude★ 1same name
- gray-matter/skills★ 0same name
1 more not listed
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 repository43 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- accessibility-auditSkill
- ai-feature-reviewSkill
- api-design-reviewSkill
- architecture-reviewSkill
- cli-and-scripts-auditSkill
- data-auditSkill
- data-minimizationSkill
- debugSkill
- describe-changesSkill
- destructive-ops-approvalSkill
- docs-consolidationSkill
- explain-codebaseSkill
- full-project-auditSkill
- implement-featureSkill
- improve-promptSkill
- incident-responseSkill
- infrastructure-auditSkill
- legal-compliance-reviewSkill
- license-complianceSkill
- no-ai-tracesSkill
- operations-auditSkill
- performance-auditSkill
- prepare-releaseSkill
- production-readiness-reviewSkill
- refactorSkill
- repository-auditSkill
- review-codeSkill
- secret-hygieneSkill
- security-auditSkill
- simplify-codeSkill
- start-projectSkill
- supply-chain-pinningSkill
- surgical-implementationSkill
- threat-modelSkill
- upgrade-dependenciesSkill
- ux-reviewSkill
- verify-changesSkill
- write-agent-instructionsSkill
- write-docsSkill
- write-testsSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. 0 are common, 13 are distinctive, and 0 are very specific to this project.
0
Common
Most of the 11 edited versions we read keep these.
13
Distinctive
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 9
Write code that explains itself through names, structure, and small functions.
- Distinctive: line 13
Add a comment only for non-obvious intent, invariants, constraints, workarounds, security boundaries, or surprising tradeoffs.
- Distinctive: line 14
Keep comments short, factual, and neutral.
- Distinctive: line 16
Avoid first-person or conversational phrasing such as “I added,” “we need,” “here we,” or “this is where.”
- Distinctive: line 17
Avoid commentary about the editing process, the prompt, the agent, or who generated the code.
- Distinctive: line 18
Do not narrate the change itself: no before/after wording, "previously," "now," "used to," or "fixed" — state the current invariant, not …
- Distinctive: line 19
Do not add tutorial paragraphs throughout implementation code.
- Distinctive: line 20
Delete stale, redundant, speculative, or copied comments when touching nearby code.
- Distinctive: line 26
Write code in English: identifiers, comments, docstrings, commit messages, and test names.
- Distinctive: line 27
Keep English even when the conversation, issue, or specification is in another language.
- Distinctive: line 29
Never mix languages inside one identifier or one comment.
- Distinctive: line 30
Keep user-facing strings, translations, and localized content in whatever language the product requires.
- Distinctive: line 63
Avoid narrating the fix history:
“Common” is measured: kept by at least 6 in 10 of the 11 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.
Files
Coding Style
Write code that explains itself through names, structure, and small functions. Treat comments as a last-mile explanation for information the code cannot express clearly.
Comment rules
- Add a comment only for non-obvious intent, invariants, constraints, workarounds, security boundaries, or surprising tradeoffs.
- Keep comments short, factual, and neutral. Prefer one sentence or a compact phrase.
- Explain why a surprising choice is necessary. Do not narrate what an obvious line already does.
- Avoid first-person or conversational phrasing such as “I added,” “we need,” “here we,” or “this is where.”
- Avoid commentary about the editing process, the prompt, the agent, or who generated the code.
- Do not narrate the change itself: no before/after wording, "previously," "now," "used to," or "fixed" — state the current invariant, not the diff that produced it.
- Do not add tutorial paragraphs throughout implementation code.
- Delete stale, redundant, speculative, or copied comments when touching nearby code.
- Preserve required API documentation, public contracts, safety warnings, citations, and legal notices.
- Match the repository's established documentation convention when it is stricter than this skill.
Language
- Write code in English: identifiers, comments, docstrings, commit messages, and test names.
- Keep English even when the conversation, issue, or specification is in another language.
- Switch only when the user asks for another language, or when the repository already uses one consistently.
- Never mix languages inside one identifier or one comment.
- Keep user-facing strings, translations, and localized content in whatever language the product requires.
Examples
Prefer:
// Keep the old key for clients that cache signed URLs.
const cacheKey = previousKey ?? currentKey;Avoid:
// Here we use the previous key because I want to make sure that clients that
// may have cached a signed URL do not suddenly stop working after this change.
const cacheKey = previousKey ?? currentKey;Omit comments that only restate the code:
retryCount += 1;State the current invariant, not the change that produced it:
# Built-in marketplaces (openai-*) are listed without a source.
if name not in managed:
continueAvoid narrating the fix history:
# Before the fix this raised "inventory malformed"; now the built-in is skipped.
if name not in managed:
continueReview
Before finishing, inspect new and edited comments. Shorten or remove any comment that sounds conversational, narrates the implementation, repeats the code, describes the change history, or reveals use of an AI assistant. Rewrite any identifier or comment left in the conversation's language instead of the repository's.
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
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.

