style-reviewer

What this skill does

# 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:

```markdown
## 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