agentleFS
26zl26zl/universal-agent-skills/skills/coding-style/SKILL.md

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

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

    Write code that explains itself through names, structure, and small functions.

    line 9
  2. Distinctive:

    Add a comment only for non-obvious intent, invariants, constraints, workarounds, security boundaries, or surprising tradeoffs.

    line 13
  3. Distinctive:

    Keep comments short, factual, and neutral.

    line 14
  4. Distinctive:

    Avoid first-person or conversational phrasing such as “I added,” “we need,” “here we,” or “this is where.”

    line 16
  5. Distinctive:

    Avoid commentary about the editing process, the prompt, the agent, or who generated the code.

    line 17
  6. Distinctive:

    Do not narrate the change itself: no before/after wording, "previously," "now," "used to," or "fixed" — state the current invariant, not …

    line 18
  7. Distinctive:

    Do not add tutorial paragraphs throughout implementation code.

    line 19
  8. Distinctive:

    Delete stale, redundant, speculative, or copied comments when touching nearby code.

    line 20
  9. Distinctive:

    Write code in English: identifiers, comments, docstrings, commit messages, and test names.

    line 26
  10. Distinctive:

    Keep English even when the conversation, issue, or specification is in another language.

    line 27
  11. Distinctive:

    Never mix languages inside one identifier or one comment.

    line 29
  12. Distinctive:

    Keep user-facing strings, translations, and localized content in whatever language the product requires.

    line 30
  13. Distinctive:

    Avoid narrating the fix history:

    line 63

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

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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:
    continue

Avoid narrating the fix history:

# Before the fix this raised "inventory malformed"; now the built-in is skipped.
if name not in managed:
    continue

Review

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.

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.