3.0 KiB
3.0 KiB
name, description
| name | description |
|---|---|
| code-style-review | 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
TODOorFIXMEcomments 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:
cd backend
mvn checkstyle:check
If violations are found, fix them or run the auto-formatter if configured:
cd backend
mvn spotless:apply
Then rerun:
cd backend
mvn checkstyle:check
2. Frontend verification (TypeScript / JavaScript)
Run the frontend linter and formatter:
cd frontend
npx eslint src/ --ext .ts,.tsx,.js,.jsx
npx prettier --check src/
If formatting issues are found, apply Prettier:
cd frontend
npx prettier --write src/
3. Final check
- Backend
mvn checkstyle:checkpasses. - 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:
Tool / Severity / File / Line / Message / Recommendation
Severity levels: ERROR, WARNING, INFO.
If all checks pass, say explicitly:
All automated style checks passed.
Example summary block:
## 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.