standards-review — check code standards

Caution

Manual code review misses pattern creep. As projects grow, the same utility gets re-implemented three times, avoid#5 quietly gets skipped, and stack-specific rules (entity suffixes, constructor injection, no hardcoded colors) erode one PR at a time. A single reviewer can’t track all of this across a large diff.

Tip

/brewcode:standards-review delegates the tedious parts. Parallel haiku agents cover each file group simultaneously — entities, services, tests, build files — then a sonnet validator confirms every finding against the actual source. The report lands in .claude/reports/ with violations, reuse opportunities, and good patterns all separated. Optionally chains into /simplify for a second pass on efficiency and hot-paths.

Quick reference

Field	Value
Command	`/brewcode:standards-review`
Arguments	`[commit\|branch\|folder] [-p <prompt>]`
Model	opus
Context	session
Tools	Read, Glob, Grep, Task, Bash, Write, mcp__grepai__search, AskUserQuestion, Skill

When to use

Before merging a feature branch — run without args to diff the branch against main/master
Spot-check a single commit — pass the short SHA: /brewcode:standards-review abc123
Review a folder in isolation — pass the path: /brewcode:standards-review src/main/java/com/example/orders
Pre-release compliance sweep — catch any avoid#N violations before tagging
After onboarding a new stack — confirm new files follow project conventions from day one

Examples

# Review current branch vs main
/brewcode:standards-review

# Review a specific commit
/brewcode:standards-review a3f9c12

# Review a folder
/brewcode:standards-review src/main/java/com/example/payments

# Natural language triggers also work
"check standards on my branch"
"find duplicates in the current diff"

Flow

Confirm scope
Before any analysis, asks one question: run /simplify afterward for an efficiency pass? Answer is remembered — no second prompt.
Detect tech stack
Scans project root for pom.xml, package.json, pyproject.toml, and similar markers. Loads the matching references/{stack}.md as expert guidelines. Multiple stacks → all references loaded and processed separately.
Collect files
Runs git diff —name-only (branch or commit) or find (folder). Filters to stack-specific extensions. Hard cap at 50 files — warns if the scope is too broad.
Load context
Reads .claude/rules/avoid.md, best-practice.md, all *.md rule files, and CLAUDE.md if present. Skips gracefully when files don’t exist.
Spawn expert agents
Files are grouped by type (entities, services, tests, build config). One haiku agent fires per non-empty group in parallel. Each agent runs search-first via grepai_search before flagging potential duplicates, then outputs structured JSON with violations and reuse signals.
Validate findings
A sonnet reviewer agent reads every file:line location from the expert JSON, confirms the rule actually applies in context, and returns CONFIRM or REJECT per finding. False positives are dropped.
Write report
Confirmed findings land in .claude/reports/{timestamp}_standards-review/REPORT.md — split into violations (errors / warnings), reuse opportunities (with similarity %, recommended action), and good patterns. If the user said Yes in step 1, invokes /simplify on the same scope.

How it works

The skill runs as an opus orchestrator. It reads your project’s rules and stack guidelines once, then fans out to specialist haiku agents — one per file group — that can run in parallel. Each agent is instructed to use grepai_search before flagging a potential duplicate, applying the similarity decision matrix (90-100% → REUSE, 70-89% → EXTEND, 50-69% → CONSIDER, below 50% → KEEP_NEW). A sonnet validation pass eliminates false positives by reading actual source at reported line ranges. The final report separates errors (must fix), warnings (should fix), and informational notes.

Internals — priority stack, similarity matrix, report structure

Review priority order

Priority	Source	Focus
1	Existing codebase	Search FIRST — import instead of creating
2	`CLAUDE.md`	Project standards, conventions, patterns
3	`rules/*.md`	Strict rules with numbers — check ALL `[avoid#N]`, `[bp#N]`
4	`references/{stack}.md`	Stack-specific guidelines bundled with this skill

Similarity decision matrix

Similarity	Decision	Action
90–100%	REUSE	Import existing
70–89%	EXTEND	Add params/config to existing
50–69%	CONSIDER	Evaluate effort vs benefit
<50%	KEEP_NEW	Justified new code

Stack groupings (Phase 4)

Java/Kotlin groups: entities, services, tests, build. TypeScript/React groups: styles, components, tests, build. Python groups: modules, tests, configs, build.

Each group maps to a pattern (e.g., **/entity/*.java) and a focus area (e.g., entity suffix, DI, Lombok).

Report structure

REPORT.md sections: Summary table → Violations (errors / warnings) → Reuse Opportunities → Good Patterns Found → Reuse Statistics → Legend.

Phase 7: optional simplify

If the user answered “Yes” at Phase 0, the skill invokes:

Skill(skill="simplify", args="{INPUT_VALUE}")

where {INPUT_VALUE} is the same scope (commit hash, branch, or folder path) used in the review.

Error handling

Condition	Action
No files found	Exit: “No files to review for {SCOPE}“
>50 files	Warn user, suggest narrowing scope
Unknown stack	Continue with project rules only
No rules found	Continue with stack reference only
All compliant	Report: “All code compliant with standards”

⭐

Updating plugins

Use /brewtools:plugin-update to check and update the brewcode plugin suite in one command. See the FAQ for details.