Code Formatting Checker
Instructions
Analyze code files for formatting issues and inconsistencies. Provide a comprehensive report with specific file locations and recommendations.
Step 1: Determine Scope
Identify target files:
- If user specifies files/directories, check those
- If no target specified, analyze current directory recursively
- Focus on source code files:
.py, .js, .ts, .jsx, .tsx, .rs, .go, .java, .cpp, .c, .h, etc.
Use list_directory to explore the codebase structure
Use grep_search to find source files by extension
Step 2: Language-Agnostic Formatting Checks
Use grep_search and read_file to check for these common issues:
2.1 Trailing Whitespace
- Pattern: Search for lines ending with spaces or tabs (
[ \t]+$)
- Impact: High - causes unnecessary diffs
- Fix: Remove trailing whitespace
2.2 Mixed Line Endings
- Pattern: Check for mixed
\r\n (Windows) and \n (Unix)
- Impact: Medium - can cause issues in version control
- Fix: Normalize to one style (prefer
\n for Unix)
2.3 Inconsistent Indentation
- Method: Read files and analyze leading whitespace
- Check for:
- Mix of tabs and spaces
- Inconsistent indentation levels (2 vs 4 spaces)
- Files that should be consistent but aren't
- Impact: High - breaks code readability and can cause errors
- Fix: Choose one style per language (Python: 4 spaces, JavaScript: 2 spaces typically)
2.4 File Ending Issues
- Check: Missing newline at end of file (POSIX compliance)
- Check: Extra blank lines at end of file
- Pattern: Read last few lines of files
- Impact: Low-Medium - style consistency
- Fix: Ensure exactly one newline at end of file
2.5 Line Length
- Threshold: Typically 80, 100, or 120 characters (language/project dependent)
- Method: Read files and check line lengths
- Impact: Medium - readability
- Report: List lines exceeding threshold with line numbers
2.6 Blank Line Consistency
- Check: Missing blank lines between functions/classes
- Check: Extra blank lines between sections
- Method: Analyze code structure patterns
- Impact: Low-Medium - style consistency
Step 3: Language-Specific Checks
3.1 Python
- Quotes: Check for inconsistent quote style (single vs double)
- Imports: Check import order and grouping
- Whitespace: PEP 8 spacing around operators, after commas
- Use bash_command: Run
black --check or flake8 --select=E,W if available
- Use bash_command: Run
ruff check if available (fast Python linter)
3.2 JavaScript/TypeScript
- Quotes: Single vs double quotes consistency
- Semicolons: Consistent use (or lack) of semicolons
- Spacing: Consistent spacing in object literals, function calls
- Use bash_command: Run
prettier --check if available
- Use bash_command: Run
eslint --fix --dry-run if available
3.3 Rust
- Use bash_command: Run
cargo fmt -- --check if available
- Indentation: Standard Rust uses 4 spaces
- Line length: Standard is 100 characters
3.4 Go
- Use bash_command: Run
gofmt -l to list files needing formatting
- Use bash_command: Run
gofmt -d to show diffs
3.5 General
- Look for project-specific formatters:
.prettierrc, .editorconfig, pyproject.toml (with black/flake8 config)
- If formatter config exists, use it for standards
Step 4: Generate Report
Create a comprehensive report with this structure:
# Code Formatting Report
## Summary
- Total files checked: X
- Files with issues: Y
- Critical issues: Z
- Warnings: W
## Issues by Category
### [Category Name]
**Impact**: [High/Medium/Low]
**Count**: [number]
#### Files Affected:
- `path/to/file.ext:line:column` - [description]
- `path/to/file.ext:line:column` - [description]
**Recommendations**:
- [Specific fix instructions]
## Language-Specific Issues
### Python
[Issues found and fixes]
### JavaScript/TypeScript
[Issues found and fixes]
## Suggested Actions
1. [Priority fix]
2. [Next fix]
3. [Optional improvement]
## Formatter Availability
- black: [available/unavailable]
- prettier: [available/unavailable]
- cargo fmt: [available/unavailable]
- gofmt: [available/unavailable]
If formatters are available, suggest running:
```bash
[formatter command]
### Report Format Guidelines
1. **Be specific**: Include file paths, line numbers, and column positions
2. **Prioritize**: Group by impact (Critical, High, Medium, Low)
3. **Actionable**: Provide clear fix instructions
4. **Quantify**: Show counts and statistics
5. **Organize**: Group by issue type and then by file
### Step 5: Provide Fix Suggestions
For each issue type, provide:
1. **Manual fixes**: Exact steps to fix manually
2. **Automated fixes**: Commands to run (if formatters available)
3. **Prevention**: How to avoid in future (editor config, pre-commit hooks)
## Examples
### Example 1: Python Project
User: "Check formatting in this Python project"
- Scan for trailing whitespace
- Check indentation (should be 4 spaces)
- Check line length (PEP 8: 79 chars, but often 100-120 is acceptable)
- Run `black --check` if available
- Report inconsistencies
### Example 2: JavaScript Project
User: "Find formatting issues"
- Check quote consistency
- Check semicolon usage
- Run `prettier --check` if available
- Report all issues with file:line references
### Example 3: Mixed Language Project
User: "Check code style"
- Identify files by extension
- Run language-specific checks
- Use appropriate formatters per language
- Generate unified report
## Best Practices
1. **Check formatter availability first**: Use `bash_command` to test if formatters are installed before suggesting their use
2. **Respect project conventions**: Look for `.editorconfig`, formatter config files
3. **Be thorough but efficient**: Check multiple files in parallel where possible
4. **Prioritize critical issues**: Focus on issues that break functionality (wrong indentation) vs style (quote preference)
5. **Provide context**: Explain why each issue matters
## Tools to Use
- `grep_search`: Find patterns across files (trailing spaces, inconsistent quotes)
- `read_file`: Analyze file contents for indentation, line lengths
- `bash_command`: Run formatters and linters if available
- `list_directory`: Discover project structure and find source files
## Notes
- Some issues are subjective (quote style) - report but note they're style preferences
- Critical issues (wrong indentation) can break code - prioritize these
- Formatters may not be installed - gracefully handle unavailable tools
- Respect existing project style even if it differs from "standard" - consistency within project is key
1---2name: checking-code-formatting3description: Check code formatting, detect style issues, and identify inconsistencies. Use when the user asks to check formatting, code style, linting, format issues, or code formatting problems.4---5
6# Code Formatting Checker
7
8## Instructions
9
10Analyze code files for formatting issues and inconsistencies. Provide a comprehensive report with specific file locations and recommendations.
11
12### Step 1: Determine Scope
13
141. **Identify target files**:
15 - If user specifies files/directories, check those
16 - If no target specified, analyze current directory recursively
17 - Focus on source code files: `.py`, `.js`, `.ts`, `.jsx`, `.tsx`, `.rs`, `.go`, `.java`, `.cpp`, `.c`, `.h`, etc.
18
192. **Use `list_directory`** to explore the codebase structure
203. **Use `grep_search`** to find source files by extension
21
22### Step 2: Language-Agnostic Formatting Checks
23
24Use `grep_search` and `read_file` to check for these common issues:
25
26#### 2.1 Trailing Whitespace
27- **Pattern**: Search for lines ending with spaces or tabs (`[ \t]+$`)
28- **Impact**: High - causes unnecessary diffs
29- **Fix**: Remove trailing whitespace
30
31#### 2.2 Mixed Line Endings
32- **Pattern**: Check for mixed `\r\n` (Windows) and `\n` (Unix)
33- **Impact**: Medium - can cause issues in version control
34- **Fix**: Normalize to one style (prefer `\n` for Unix)
35
36#### 2.3 Inconsistent Indentation
37- **Method**: Read files and analyze leading whitespace
38- **Check for**:
39 - Mix of tabs and spaces
40 - Inconsistent indentation levels (2 vs 4 spaces)
41 - Files that should be consistent but aren't
42- **Impact**: High - breaks code readability and can cause errors
43- **Fix**: Choose one style per language (Python: 4 spaces, JavaScript: 2 spaces typically)
44
45#### 2.4 File Ending Issues
46- **Check**: Missing newline at end of file (POSIX compliance)
47- **Check**: Extra blank lines at end of file
48- **Pattern**: Read last few lines of files
49- **Impact**: Low-Medium - style consistency
50- **Fix**: Ensure exactly one newline at end of file
51
52#### 2.5 Line Length
53- **Threshold**: Typically 80, 100, or 120 characters (language/project dependent)
54- **Method**: Read files and check line lengths
55- **Impact**: Medium - readability
56- **Report**: List lines exceeding threshold with line numbers
57
58#### 2.6 Blank Line Consistency
59- **Check**: Missing blank lines between functions/classes
60- **Check**: Extra blank lines between sections
61- **Method**: Analyze code structure patterns
62- **Impact**: Low-Medium - style consistency
63
64### Step 3: Language-Specific Checks
65
66#### 3.1 Python
67- **Quotes**: Check for inconsistent quote style (single vs double)
68- **Imports**: Check import order and grouping
69- **Whitespace**: PEP 8 spacing around operators, after commas
70- **Use bash_command**: Run `black --check` or `flake8 --select=E,W` if available
71- **Use bash_command**: Run `ruff check` if available (fast Python linter)
72
73#### 3.2 JavaScript/TypeScript
74- **Quotes**: Single vs double quotes consistency
75- **Semicolons**: Consistent use (or lack) of semicolons
76- **Spacing**: Consistent spacing in object literals, function calls
77- **Use bash_command**: Run `prettier --check` if available
78- **Use bash_command**: Run `eslint --fix --dry-run` if available
79
80#### 3.3 Rust
81- **Use bash_command**: Run `cargo fmt -- --check` if available
82- **Indentation**: Standard Rust uses 4 spaces
83- **Line length**: Standard is 100 characters
84
85#### 3.4 Go
86- **Use bash_command**: Run `gofmt -l` to list files needing formatting
87- **Use bash_command**: Run `gofmt -d` to show diffs
88
89#### 3.5 General
90- Look for project-specific formatters: `.prettierrc`, `.editorconfig`, `pyproject.toml` (with black/flake8 config)
91- If formatter config exists, use it for standards
92
93### Step 4: Generate Report
94
95Create a comprehensive report with this structure:
96
97```markdown
98# Code Formatting Report
99
100## Summary
101- Total files checked: X
102- Files with issues: Y
103- Critical issues: Z
104- Warnings: W
105
106## Issues by Category
107
108### [Category Name]
109**Impact**: [High/Medium/Low]
110**Count**: [number]
111
112#### Files Affected:
113- `path/to/file.ext:line:column` - [description]
114- `path/to/file.ext:line:column` - [description]
115
116**Recommendations**:
117- [Specific fix instructions]
118
119## Language-Specific Issues
120
121### Python
122[Issues found and fixes]
123
124### JavaScript/TypeScript
125[Issues found and fixes]
126
127## Suggested Actions
128
1291. [Priority fix]
1302. [Next fix]
1313. [Optional improvement]
132
133## Formatter Availability
134
135- black: [available/unavailable]
136- prettier: [available/unavailable]
137- cargo fmt: [available/unavailable]
138- gofmt: [available/unavailable]
139
140If formatters are available, suggest running:
141```bash
142[formatter command]
143```
144```
145
146### Report Format Guidelines
147
1481. **Be specific**: Include file paths, line numbers, and column positions
1492. **Prioritize**: Group by impact (Critical, High, Medium, Low)
1503. **Actionable**: Provide clear fix instructions
1514. **Quantify**: Show counts and statistics
1525. **Organize**: Group by issue type and then by file
153
154### Step 5: Provide Fix Suggestions
155
156For each issue type, provide:
157
1581. **Manual fixes**: Exact steps to fix manually
1592. **Automated fixes**: Commands to run (if formatters available)
1603. **Prevention**: How to avoid in future (editor config, pre-commit hooks)
161
162## Examples
163
164### Example 1: Python Project
165User: "Check formatting in this Python project"
166- Scan for trailing whitespace
167- Check indentation (should be 4 spaces)
168- Check line length (PEP 8: 79 chars, but often 100-120 is acceptable)
169- Run `black --check` if available
170- Report inconsistencies
171
172### Example 2: JavaScript Project
173User: "Find formatting issues"
174- Check quote consistency
175- Check semicolon usage
176- Run `prettier --check` if available
177- Report all issues with file:line references
178
179### Example 3: Mixed Language Project
180User: "Check code style"
181- Identify files by extension
182- Run language-specific checks
183- Use appropriate formatters per language
184- Generate unified report
185
186## Best Practices
187
1881. **Check formatter availability first**: Use `bash_command` to test if formatters are installed before suggesting their use
1892. **Respect project conventions**: Look for `.editorconfig`, formatter config files
1903. **Be thorough but efficient**: Check multiple files in parallel where possible
1914. **Prioritize critical issues**: Focus on issues that break functionality (wrong indentation) vs style (quote preference)
1925. **Provide context**: Explain why each issue matters
193
194## Tools to Use
195
196- `grep_search`: Find patterns across files (trailing spaces, inconsistent quotes)
197- `read_file`: Analyze file contents for indentation, line lengths
198- `bash_command`: Run formatters and linters if available
199- `list_directory`: Discover project structure and find source files
200
201## Notes
202
203- Some issues are subjective (quote style) - report but note they're style preferences
204- Critical issues (wrong indentation) can break code - prioritize these
205- Formatters may not be installed - gracefully handle unavailable tools
206- Respect existing project style even if it differs from "standard" - consistency within project is key
207