deepening-reviewlisted

# Deepening Review ## Core Rule Surface shallow modules as candidates, then grill one deeply — depth over breadth. Never deepen a module the user didn't choose. ## Kit Context Before starting this skill, ensure session boot is complete: 1. Read `CODEBASE_MAP.md` for project understanding 2. Read `CLAUDE.project.md` if it exists for project-specific rules 3. Read `agent_docs/architecture-language.md` — **required**. This skill uses its vocabulary exactly. 4. Read `tasks/decisions.md` if it exists — don't re-litigate ADR-resolved decisions. If `agent_docs/architecture-language.md` hasn't been read in this session, read it now before proceeding. ## When to Use Invoke with `/deepening-review` when: - The user wants to improve architecture for testability or AI-navigability - A module cluster feels tightly coupled and hard to reason about - Tests exist but bugs keep escaping — suggesting tests sit past the wrong seam - Onboarding to a codebase and noticing pass-through modules that hide nothing - After `/architecture-review` flagged structural issues without suggesting concrete refactors ## When NOT to Use - For SOLID violations / module health metrics → use `/architecture-review` - For specific code smells (long function, feature envy, etc.) → use `/code-quality-audit` then `/refactoring-guide` - For unused code → use `/dead-code-audit` - For projects under ~5 source files — depth analysis needs surface area ## Paradigm vs `/architecture-review` | Lens | This skill (