clean-code

Scan the changed lines against the symptom map, then load only the one to three reference files covering the flagged rules. Cite each finding as path:line with a rule ID like FUN-12, a one-sentence defect, and a concrete fix, checking the Don't over-apply section for [M] and [H] findings first.

Ask for a dry run, optionally pinning a language or domain such as "dry run go payroll". The Skill generates a messy but working program in a temp workspace, reviews and refactors it using its own protocol, and shows diffs plus a planted-vs-caught scorecard without touching your project.

Yes, the Skill adapts each rule's intent to the host language's idioms. Go and Rust use error values or Result instead of exceptions, Python uses snake_case and properties, and non-null type systems in Kotlin, TypeScript strict, C#, Swift, and Rust enforce the null-handling rules directly.

Each reference file has a Don't over-apply section: skip what formatters and linters already enforce, don't wrap stable standard-library types, don't build adapters for one-off dependencies, and don't split small stable data holders. Project conventions and language idioms override the book's Java-era style.

Severity tags are defaults that context can raise or lower, and [L] findings alone never block a change. The Skill defers deep SOLID analysis, design-pattern selection, and test strategy to sibling skills rather than re-deriving them.