abbreviation-policyThis 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.
boolean-namingThis 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 bo
casing-lawThis 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 prohib
dead-code-intoleranceThis 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 contro
declaration-orderThis 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
go-pedantryThis 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-s
guidelines-complianceThis 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
import-disciplineThis 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
magic-value-eliminationThis 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.
naming-precisionThis 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.
one-pattern-one-wayThis 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
python-pedantryThis 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 docstrin
symmetryThis 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 cons
typescript-pedantryThis 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-spe
using-pedantic-principlesThis 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 sk
visual-rhythmThis 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 for