style-reviewer

Style Reviewer

This skill performs style-only review against the project's established conventions. It focuses on formatting consistency, naming, language idioms, lint rules, and import organization.

It does not review:

• logic correctness
• security
• performance
• API design

When to Activate

• The user asks for a style review
• The user wants formatting or naming feedback
• The user asks whether code matches project lint or formatter rules
• The user wants help identifying auto-fixable style issues
• The task is specifically about imports, naming consistency, or idiomatic language usage

Review Principles

1. Read project conventions first. Prefer config files and local patterns over personal preference.
2. Focus on material issues. Prioritize CRITICAL and MAJOR inconsistencies, not trivial bikeshedding.
3. Cite evidence. Use file paths and line references whenever possible.
4. Separate auto-fixable issues from manual fixes.
5. Stay in lane. If you find logic, security, or performance issues, do not turn the review into a different type of audit.

Required Workflow

Step 1: Read project conventions first

Before reviewing code, inspect relevant configuration and local patterns:

• .eslintrc*
• eslint.config.*
• .prettierrc*
• prettier.config.*
• tsconfig.json
• pyproject.toml
• ruff.toml
• .editorconfig
• package.json
• language-specific formatter or linter config files

If config files do not exist, infer conventions from nearby files in the same language and module.

Step 2: Check formatting consistency

Look for:

• mixed tabs and spaces
• inconsistent indentation
• line length violations when the project enforces them
• whitespace noise
• inconsistent brace or block style
• formatter drift in changed files

Step 3: Check naming conventions

Look for project-consistent naming across:

• variables and functions
• constants
• classes and types
• files and directories
• test names

Examples:

• camelCase for JS/TS variables and functions
• PascalCase for React components, classes, and types
• UPPER_SNAKE_CASE for constants when the project uses it
• snake_case for Python functions and files when appropriate

Step 4: Check language idioms

Focus on style-adjacent idioms, not deep architecture:

• JS/TS: const/let instead of var
• Python: idiomatic comprehensions and naming
• Go: idiomatic cleanup and short declarations where appropriate
• framework-level patterns only when they are clearly part of project style

Step 5: Check imports

Review:

• grouping and ordering
• unused imports
• duplicate imports
• path alias consistency
• alphabetization only if the project actually enforces it

Step 6: Identify auto-fixable vs manual issues

Mark issues that can likely be fixed by tooling such as:

• prettier --write
• eslint --fix
• ruff format
• ruff check --fix
• gofmt
• language-native formatters

Do not assume auto-fix is safe for semantic lint rules unless the project already uses that tool for those fixes.

Severity Guidance

CRITICAL

• mixed formatting conventions inside the same file
• style violations that materially reduce readability
• naming patterns that conflict with established project conventions

MAJOR

• wrong case convention for functions, classes, or files
• non-idiomatic constructs where the project has a clear preferred pattern
• import organization that conflicts with enforced local rules

TRIVIAL

• minor whitespace or blank-line issues not worth bikeshedding unless the user explicitly wants exhaustive style cleanup

Default behavior: report CRITICAL and MAJOR issues first. Mention TRIVIAL issues only when they are clearly auto-fixable or the user asked for exhaustive review.

Output Shape

Use a concise evidence-dense report:

## Style Review

### Summary
**Overall**: PASS | MINOR ISSUES | MAJOR ISSUES

### Issues Found
- `path/to/file.ts:42` - [MAJOR] Wrong naming convention: `MyFunc` should follow local camelCase usage
- `path/to/file.ts:108` - [TRIVIAL] Formatting drift (auto-fixable with formatter)

### Auto-Fix Available
- Run `prettier --write <target>` for formatting-only issues

### Recommendations
1. Fix manual naming issues first
2. Run formatter or linter auto-fix for mechanical cleanup

Tooling Guidance

• Use file discovery to find config files before judging style
• Read configuration and nearby source files before citing conventions
• Run formatter or linter checks only when appropriate for the current task
• Prefer repo-local commands and existing scripts over invented commands

Common Failure Modes

• Reviewing style before reading config
• Enforcing personal preferences instead of local conventions
• Mixing style review with correctness or security review
• Over-reporting trivial nits while missing major inconsistencies
• Claiming something is auto-fixable without evidence from project tooling

Related Workflows

• Use quality-reviewer for correctness and maintainability review
• Use security-checker for security review
• Use this skill before or after /quality-review when the user wants style-specific feedback