fullstack.rocks/skills

code-standards

A code review that learns what your team rejects.

How many times have you left the same comment on a PR? code-standards is a code review that learns, so you only have to say it once.

Each review runs three layers on the changed files: your project’s linters as configured, the ast-grep rules (cs-*) your team taught it, and the agent’s judgment against a learned standards.md (std-*). lizard (complexity) and jscpd (duplication) run alongside, and the deterministic layers finish in under a second on about 50 files.

Install

Terminal
npx skills add Fullstack-Rocks/skills --skill code-standards -a claude-code

code-standards stands alone and needs none of the other skills.

Try saying

claude · demo shop
A real Claude Code session on the demo shop, recorded as it happened. Long thinking stretches are sped up, everything else plays at its real pace.
Transcript

> Is my change clean? Skill(code-standards): the linters, the cs-* rules, lizard and jscpd, then standards.md. Every finding cites a rule. > We never read environment variables outside app/config.py. Flag this. Bypasses proposed before writing anything: from os import environ, import os as _os, other os.environ access, dotenv, BaseSettings subclasses, wrapper helpers, process.env / import.meta.env. Saved: cs-env-outside-config (21 cases it must flag, 12 lookalikes it must not), cs-env-outside-config-ts (9 and 6), and std-config-single-source. Repo hits: the Python rule flags 5 places, all real violations. These are team files, meant to be committed and reviewed in a PR.

How does it work?

The config lists file extensions, not languages, so it works in any language the tools can parse. Depending on what you say, it runs in one of three modes:

  1. init (“Set up coding standards for this repo.”) scaffolds .code-standards/, detects your linters and extensions, asks up to five questions, and drafts standards.md from 2 or 3 files you consider exemplary. Nothing is written until you approve.
  2. review (“Is my change clean?”) runs every tool in parallel, applies only the standards.md entries whose scope matches, and reports by severity. Every finding cites a rule.
  3. negate (“We never read env vars outside app/config.py. Flag this.”) first proposes the bypasses a narrow rule would miss, before touching any tools. Then it writes a rule with fixtures, saves it only once ast-grep test passes and a repo-wide false-positive check comes back clean, and logs it.

Everything lives in .code-standards/ in your repo: the rules, test fixtures, standards and a log of each rejection. Your team commits it and reviews it in PRs, just like code.

One sentence from you becomes a tested rule in .code-standards/, reviewed in PRs like code.

But does it work?

Benchmark

What does a review cost, and what does it find?

A review costs about the same with or without the skill. On the whole repo (55 files) it took 57 s and $0.43 and found 17 of 17 issues, against 57 s, $0.36 and 15 of 17 alone. On a 3-file change with 8 planted smells it took 30 s and $0.28 for 8 of 8, against 52 s and $0.21 for 7 of 8. What the skill changes is completeness. Claude alone had a shell and the project’s linters (ruff, oxlint, tsc), but no ast-grep, jscpd or lizard. Answers were graded by hand.

Whole repo, 55 files: 57 s, $0.43 and 17 of 17 issues with code-standards, against 57 s, $0.36 and 15 of 17 alone. A 3-file change with 8 planted smells: 30 s, $0.28 and 8 of 8 with it, against 52 s, $0.21 and 7 of 8 alone.
Open full size (opens in a new tab)

The other skills