pedantic-coder

Scan all CLAUDE.md files in the repository and check code for compliance with project-specific guidelines

Audit an entire repository for pedantic violations — systematically scans the codebase for naming, casing, symmetry, ordering, consistency, and structural issues

Review the current code for pedantic violations — naming, casing, symmetry, ordering, consistency, dead code, and every small detail that matters

Use this agent for comprehensive code pedantry audits — naming, casing, symmetry, ordering, consistency, and every detail that separates clean code from correct code. Handles both targeted file reviews and full repository audits. Examples: <example>Context: User has written new code and wants it reviewed for quality. user: "Review my code for consistency and style issues" assistant: "I'll use the pedantic-reviewer agent to audit the code." <commentary>Code review for consistency touches naming, casing, imports, ordering, symmetry — comprehensive pedantic audit needed.</commentary></example> <example>Context: User wants a thorough quality check before merging. user: "Do a pedantic review of my changes before I merge" assistant: "I'll use the pedantic-reviewer agent to perform a thorough review." <commentary>Pre-merge review should cover all pedantic dimensions — naming, structure, dead code, magic values.</commentary></example> <example>Context: User wants their entire repository audited for consistency. user: "Audit my whole repo for code quality and consistency" assistant: "I'll use the pedantic-reviewer agent to perform a repo-wide audit." <commentary>Repo-wide audit requires discovering structure, sampling files, identifying codebase-wide patterns and convention conflicts.</commentary></example>

This skill should be used when the user is abbreviating identifiers, using acronyms, or when a codebase has inconsistent short forms like btn/button, msg/message, req/request. Covers the abbreviation decision framework, approved short forms, and the rule that consistency beats brevity.

This skill should be used when the user is naming boolean variables, writing predicate functions, using flags or toggles, or when code contains ambiguous boolean names like flag, status, check, active without proper prefixes. Covers is/has/can/should prefixes, positive naming, and the rule that a boolean's name must read as a true/false question.

This skill should be used when the user is writing code with mixed casing conventions, choosing casing for identifiers, enforcing casing consistency across a codebase, or when camelCase and snake_case appear in the same file. Covers per-context casing rules, acronym handling, and the absolute prohibition of mixed conventions.

This skill should be used when the user's code contains commented-out code blocks, unused imports, unreachable branches, TODO/FIXME comments that have been sitting for more than a day, or comments referencing removed functionality. Covers the elimination of dead code and the rule that version control remembers so you don't have to.

This skill should be used when the user is organizing code within a file, ordering class members, structuring module exports, or when a file has constants mixed with functions mixed with classes in no predictable order. Covers file-level ordering, class member ordering, and the rule that every file should have the same shape.

1 hook across 1 event