Coding standards
A collection of rigorous, phase-isolated SDLC skills to tether autonomous agents to real-world engineering standards.
npx -y skills add NjoyimPeguy/augments --skill coding-standardsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 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
Use once per project, or when conventions drift, to set the standards agents and humans follow — domain vocabulary, patterns to use, things to never do. Skip if the project already has clear, followed standards.
SKILL.md
2.2 KB, as published. Nobody here has run it
Coding Standards
Set the conventions once so every contributor — human or agent — writes code that reads like one author. The highest-leverage standard is shared vocabulary: name things from the domain, consistently, so the same concept is never two words.
When to use
- Starting a project, or when conventions have drifted and the code reads like several authors.
- Skip if the project already has clear standards that are actually followed.
Procedure
- Fix the domain vocabulary. One canonical term per concept ("order", not order/purchase/transaction). Ban generic labels ("service", "manager", "handler", "util") where a domain term exists — the model treats synonyms as distinct things, so this is a design decision, not pedantry. Keep it as a standing glossary the project updates, not a one-time list — agents read it for naming, which cuts drift and token waste.
- Name the patterns to use — error handling, validation, async, dependency injection, testing seams — the one way this project does each, with a short example.
- State the hard "never"s — the small list of things that must not happen here (no business logic in the UI layer, no raw queries outside the data layer). Keep it short; a long list is ignored.
- Point to the exemplar — one existing file that already does it right, so the standard is shown, not just told.
- Write the coding-standards section of the shared design document
.augments/designs/{{YYYY-MM-DD}}-{{topic}}.md(the standard designs location; a standing conventions file or other path only if the user has set one).
Common mistakes
- A long list of rules no one reads — keep it to what actually matters here.
- Standards told but never shown — point to a real exemplar file.
- Generic vocabulary that lets one concept drift into many names.
For a fill-in template for the standards section, a worked example, and the failure patterns, see references/standards-template.md.