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.
Analyze code files for formatting issues and inconsistencies. Provide a comprehensive report with specific file locations and recommendations.
Identify target 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
Use grep_search and read_file to check for these common issues:
[ \t]+$)\r\n (Windows) and \n (Unix)\n for Unix)black --check or flake8 --select=E,W if availableruff check if available (fast Python linter)prettier --check if availableeslint --fix --dry-run if availablecargo fmt -- --check if availablegofmt -l to list files needing formattinggofmt -d to show diffs.prettierrc, .editorconfig, pyproject.toml (with black/flake8 config)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