Claude-skill-registry checking-code-formatting
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.
install
source · Clone the upstream repo
git clone https://github.com/majiayu000/claude-skill-registry
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/checking-code-formatting" ~/.claude/skills/majiayu000-claude-skill-registry-checking-code-formatting && rm -rf "$T"
manifest:
skills/data/checking-code-formatting/SKILL.mdsource content
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
, etc..h
-
Use
to explore the codebase structurelist_directory -
Use
to find source files by extensiongrep_search
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
(Windows) and\r\n
(Unix)\n - Impact: Medium - can cause issues in version control
- Fix: Normalize to one style (prefer
for Unix)\n
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
orblack --check
if availableflake8 --select=E,W - Use bash_command: Run
if available (fast Python linter)ruff check
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
if availableprettier --check - Use bash_command: Run
if availableeslint --fix --dry-run
3.3 Rust
- Use bash_command: Run
if availablecargo fmt -- --check - Indentation: Standard Rust uses 4 spaces
- Line length: Standard is 100 characters
3.4 Go
- Use bash_command: Run
to list files needing formattinggofmt -l - Use bash_command: Run
to show diffsgofmt -d
3.5 General
- Look for project-specific formatters:
,.prettierrc
,.editorconfig
(with black/flake8 config)pyproject.toml - 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