Marcos Paulo
113 lines
3.0 KiB
Markdown
113 lines
3.0 KiB
Markdown
---
|
|
name: code-style-review
|
|
description: Run automated linters, Checkstyle, and formatting scripts to validate and fix code style without consuming unnecessary LLM tokens.
|
|
---
|
|
|
|
# Code Style & Automated Linting
|
|
|
|
Use this skill after modifying code files to trigger local static analysis tools and fix formatting issues automatically.
|
|
|
|
## When to use
|
|
|
|
- After completing any backend (Java) or frontend changes.
|
|
- Before running MR self-reviews or committing code.
|
|
|
|
## Core rules
|
|
|
|
### Indentation & formatting
|
|
|
|
- TypeScript, JavaScript, JSX, JSON, HTML, CSS, Less: 2 spaces per indentation level.
|
|
- Java, XML: 4 spaces per indentation level.
|
|
- Do not use hard tabs unless the existing file already uses them consistently.
|
|
- Remove trailing whitespace from all lines.
|
|
- Ensure every file ends with exactly one empty newline (POSIX standard).
|
|
- Keep line length reasonable; break long lines rather than letting them scroll far beyond 120 characters.
|
|
- Maintain consistent brace style with the surrounding file.
|
|
|
|
### Code hygiene
|
|
|
|
- Remove unused imports, variables, functions and types.
|
|
- Remove dead code, commented-out experiments and placeholder snippets.
|
|
- Delete leftover debugging statements: `console.log`, `console.warn`, `console.error`, `System.out.println`, `printStackTrace`, etc.
|
|
- Do not leave `TODO` or `FIXME` comments unless explicitly approved and tracked.
|
|
- Keep imports organized and free of duplicates.
|
|
- Ensure naming follows the conventions already used in the file/module.
|
|
|
|
## Execution steps
|
|
|
|
### 1. Backend verification (Java / Maven)
|
|
|
|
Run the automated style check in the `backend` directory:
|
|
|
|
```bash
|
|
cd backend
|
|
mvn checkstyle:check
|
|
```
|
|
|
|
If violations are found, fix them or run the auto-formatter if configured:
|
|
|
|
```bash
|
|
cd backend
|
|
mvn spotless:apply
|
|
```
|
|
|
|
Then rerun:
|
|
|
|
```bash
|
|
cd backend
|
|
mvn checkstyle:check
|
|
```
|
|
|
|
### 2. Frontend verification (TypeScript / JavaScript)
|
|
|
|
Run the frontend linter and formatter:
|
|
|
|
```bash
|
|
cd frontend
|
|
npx eslint src/ --ext .ts,.tsx,.js,.jsx
|
|
npx prettier --check src/
|
|
```
|
|
|
|
If formatting issues are found, apply Prettier:
|
|
|
|
```bash
|
|
cd frontend
|
|
npx prettier --write src/
|
|
```
|
|
|
|
### 3. Final check
|
|
|
|
- [ ] Backend `mvn checkstyle:check` passes.
|
|
- [ ] Frontend ESLint reports no errors.
|
|
- [ ] Frontend Prettier reports no formatting differences.
|
|
- [ ] No unintended files were reformatted.
|
|
- [ ] No leftover debugging statements remain.
|
|
|
|
## Output format
|
|
|
|
Return findings as:
|
|
|
|
```text
|
|
Tool / Severity / File / Line / Message / Recommendation
|
|
```
|
|
|
|
Severity levels: `ERROR`, `WARNING`, `INFO`.
|
|
|
|
If all checks pass, say explicitly:
|
|
|
|
```text
|
|
All automated style checks passed.
|
|
```
|
|
|
|
Example summary block:
|
|
|
|
```markdown
|
|
## Code Style & Automated Linting
|
|
|
|
- Backend Checkstyle: PASS / FAIL — reason
|
|
- Frontend ESLint: PASS / FAIL — reason
|
|
- Frontend Prettier: PASS / FAIL — reason
|
|
```
|
|
|
|
If any check fails, apply the recommended fix and rerun the tool before finishing unless the user asks to skip.
|