code-smellslisted

# Code Smells Whole-repo design review. Third member of the analysis family: | Question | Skill | |---|---| | Which files are big / coupled / churning / cyclic? | `architectural-hotspots` | | What is broken inside file X (perf, correctness, durability)? | `code-audit-deep` | | Where is the *design* wrong, and which refactoring fixes it? | **this skill** | The premise: hotspots sees graph shape, audit-deep sees runtime behavior — neither sees *misplaced responsibility*. A function that lives in the wrong module, a concept smeared across four files, an abstraction with one user: these compile, pass tests, and show up in no profiler. They show up as change cost. This skill finds them and names both the smell and the cure. Every finding is a **named smell mapped to a named refactoring**: "Feature Envy in `report.py:88 parse_totals()` → Move Function to `invoice.py`" is a diagnosis plus a prescription. "This could be cleaner" is neither — never emit that sentence. A definitional anchor (it shapes the whole method): a smell is *"a surface indication that usually corresponds to a deeper problem"* (Fowler), and per Kent Beck *"a suggestion that something may be wrong, not evidence that there is already a problem."* Smells are heuristics, not rules — the field's own literature warns that mechanical detectors drown in false positives because *"code metric values, when inspected out of context, mean nothing."* That is why every mechanical lead below must be confirmed by reading, an