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.

This skill should be used when the user is writing Go code and needs guidance on Go-specific pedantry: error wrapping with fmt.Errorf and %w, interface design (accept interfaces return structs), package naming conventions, struct field ordering, receiver naming, golangci-lint configuration, and Go-specific patterns that go beyond universal principles.

This skill should be used when the user asks to check code against CLAUDE.md guidelines, review compliance with project conventions, audit a repository's own rules, verify CLAUDE.md inheritance, or when performing a comprehensive pedantic audit that should include project-specific rules. Covers the CLAUDE.md inheritance model, directory walk-up algorithm, parsing guidelines vs informational content, and systematic compliance checking.

This skill should be used when the user is organizing imports, writing require/use/include statements, fixing import ordering, dealing with circular dependencies, or when a file has disordered, ungrouped, or inconsistent imports. Covers import grouping, sorting, separation, and the rule that imports are the table of contents for a file.

This skill should be used when the user's code contains inline string literals, unexplained numbers, hardcoded timeout values, status strings, or any value that should be a named constant or enum. Covers the elimination of magic values and the rule that every literal should have a name.

This skill should be used when the user is naming variables, functions, classes, files, or any identifier. Covers semantic accuracy, vague names like data/temp/result/info/handle, domain-specific naming, and the principle that a name should make the reader never need to look at the implementation.

This skill should be used when the user's codebase has multiple approaches to the same problem, mixes paradigms (callbacks and promises, classes and functions for the same purpose), or when someone introduces a 'local shortcut' that differs from the established convention. Covers pattern consistency and the rule that a codebase should solve each category of problem exactly one way.

This skill should be used when the user is writing Python code and needs guidance on Python-specific pedantry: modern type syntax (str | None vs Optional), Pydantic BaseSettings for configuration centralization, StrEnum for string constants, exception chaining (raise X from e), Google-style docstrings, ruff rules, and Python-specific patterns that go beyond universal principles.

This skill should be used when the user is writing parallel code paths (CRUD operations, event handlers, API endpoints), implementing matching pairs (create/destroy, open/close, serialize/deserialize), or when similar operations have dissimilar structures. Covers structural mirroring, signature consistency, and the rule that parallel things must look parallel.

This skill should be used when the user is writing TypeScript code and needs guidance on TypeScript-specific pedantry: strict tsconfig settings, discriminated unions over type assertions, Zod schemas for runtime validation, barrel exports, as const assertions, ESLint strict rules, and TypeScript-specific patterns that go beyond universal principles.

This skill should be used when the user asks "which pedantic skill should I use", "show me all code quality principles", "help me pick a code style rule", or at the start of any code review, refactoring, or greenfield project. Provides the index of all principle skills and the three language pack skills.

This skill should be used when the user's code has inconsistent whitespace, missing blank lines between logical sections, cramped or overly spaced code, or when the visual structure does not match the logical structure. Covers whitespace as punctuation and the rule that code is prose and must be formatted like prose.

1 hook across 1 event