Coding style
Canonical Agent Skills with idempotent cross-agent installers for Claude Code, Codex, OpenCode, and GitHub Copilot
npx -y skills add 26zl/universal-agent-skills --skill coding-styleAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 14 days oldThe repository was created 14 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Keep code comments and docstrings concise, neutral, and human-authored in tone. Use when writing, refactoring, or reviewing code where comments may be added or changed; do not use to shorten required public API documentation, safety notes, or legal notices.
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
2.5 KB, as published. Nobody here has run it
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.
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.