Code standards adopter
Skill timwukp/agent-skills-best-practice/skills/skills/code-standards-adopter
35 portable agent skills (Agent Skills spec) for Kiro & Claude Code: Scrum DevSecOps roles, PCI-DSS/MAS TRM compliance, AWS Well-Architected reviews — each with evals and a 4-layer tested methodology
npx -y skills add timwukp/agent-skills-best-practice --skill code-standards-adopterAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 7 stars7 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
Infers a codebase's implicit coding conventions (naming, structure, imports, comments, error handling) by analyzing the existing code, then makes them explicit: generates linter/formatter configs that match current reality, a conventions document, and agent steering rules so AI-written code blends in. Use when adopting AI coding tools on an existing codebase or onboarding to an unfamiliar team style. Triggers on: "match our coding style", "infer our conventions", "generate lint config from this codebase", "make the AI write code like our team", "extract our code standards", "set up steering rules from existing code".
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
4.8 KB, as published. Nobody here has run it
Code Standards Adopter
Most teams' real conventions live in the code, not in a style guide. This skill reads the codebase, infers the conventions actually in force, and turns them into enforceable artifacts — so newly written code (human or AI) matches what's already there instead of fighting it.
The output is descriptive first, prescriptive second: capture what IS, flag inconsistencies, and let the team decide what SHOULD be.
Process
- Sample the codebase. Don't read everything. Pick 10-20 representative files: the most-recently-changed files (current style), the largest modules (dominant style), and one file per major directory. Note the languages and frameworks in play.
- Infer conventions per dimension (see checklist below). For each, record: the dominant pattern, observed frequency (e.g. "camelCase in 18/20 files"), and exceptions worth flagging.
- Detect existing enforcement. Check for linter/formatter configs (.eslintrc, ruff.toml, .editorconfig, checkstyle, prettier, gofmt assumptions), CI lint steps, and pre-commit hooks. Never generate a config that conflicts with one that exists — propose amendments instead.
- Generate the artifacts the user needs (ask if unclear, default to all three):
- Conventions document — concise markdown, one section per dimension, with real examples lifted from the codebase (anonymized if sensitive).
- Tool configs — linter/formatter configuration matching the inferred style, with each non-default rule commented with its evidence ("18/20 files use single quotes").
- Agent steering rules — a steering/context file for AI coding tools (Kiro
.kiro/steering/code-style.md, CLAUDE.md section, or equivalent) containing only the conventions an agent would otherwise get wrong.
- Report inconsistencies separately. Where the codebase splits (e.g. two naming styles 60/40), present both options with counts and let the team pick — do not silently impose the majority.
Convention Checklist
| Dimension | What to look for |
|---|---|
| Naming | Case styles per identifier kind (files, classes, functions, constants, DB columns); abbreviation habits; test file naming |
| Structure | Directory layout logic; one-class-per-file or not; where interfaces/types live; co-location of tests |
| Imports | Ordering and grouping; absolute vs relative; barrel files; aliasing |
| Functions | Typical length; early-return vs nested; parameter object thresholds |
| Errors | Exceptions vs result types; error wrapping; logging at throw site or boundary; custom error classes |
| Comments | Density; docstring format and coverage; TODO conventions; license headers |
| Tests | Framework idioms; naming (should_x vs test_x vs it('...')); fixture patterns; assertion style |
| Formatting | Quotes, semicolons, line length, trailing commas — only where no formatter already decides |
| Git | Commit message style; branch naming (read recent history) |
Steering Rules Quality Bar
The steering file is the highest-leverage artifact. Keep it under ~50 lines:
- Include only conventions a competent agent would plausibly get wrong (project-specific idioms, unusual choices, the chosen side of any inconsistency).
- Exclude anything a formatter/linter already enforces — tools enforce, steering informs.
- One example per rule, drawn from the actual codebase.
- State the why where it isn't obvious ("we use result types because exceptions cross a WASM boundary here").
Guidelines
- Evidence over taste: every rule you emit must cite observed frequency. If you can't count it, don't claim it.
- Respect the formatter hierarchy: if prettier/gofmt/black is present, formatting dimensions are settled — don't relitigate them in the conventions doc.
- For polyglot repos, produce per-language sections; don't average conventions across languages.
- If the codebase is too small (<10 source files) or too inconsistent to infer anything, say so and recommend starting from a community standard instead, listing what was actually observed.