dx-refactor-discover

Start with no concrete target — "find me refactor opportunities." Scan the codebase for design problems worth fixing — shallow modules to turn deep, whatever the wider design lenses surface, and code that breaks the project's own structural standards — present them inline as markdown, and promote whichever the user picks into a normal container. This skill discovers and hands off — it can sketch alternative interfaces for whichever candidates the user picks, but it writes no plan.md and edits no code. When several candidates share a cause no rule covers, it proposes the missing standard, but never writes one.

Guard. If context/ isn't scaffolded (no changes/ or efforts/), stop and tell the user to run /dx-init. The candidates this run produces are ephemeral — there is no debt register; anything not promoted or recorded as a lesson leaves no trace.

1 — Load the vocabulary and the rulebook

Invoke dx-references with topic module-design — its terms (deep vs shallow, seam, leverage and locality, adapter, dependency category, the deletion test) are how every candidate is phrased, and its ## Rejected framings says which words stay out. Read foundation/glossary.md for naming (a one-line habit — no section) and foundation/lessons.md so you skip anything a prior run already rejected — "don't re-deepen X because Y", "don't migrate X to rule Y because Z" and "don't propose rule X because Z" alike.

Invoke dx-references with knowledge-layer and match context/standards/ to the scope by its domain × topic rule: a scoped run takes global/ plus the areas the scoped code belongs to; an unscoped run takes every standard that applies somewhere in the tree. From those, keep only the structural rules existing code can be checked against — where a unit lives, what it may depend on, one unit per role. A rule about how to write plans or new work, or a style nit, has nothing to find in old code.

2 — Scan

Optionally scoped by [area or path]; unscoped means the whole tree. Invoke dx-references with design-lenses — module depth is the primary lens, not the only one, and problems outside it go unfound if nothing else is looking. Fan out to built-in Explore subagents to walk it — explore for friction, don't run rigid heuristics.

Recency is the default prior. Walk back a stretch of git log --oneline and let the paths that keep showing up pull attention first — churn is where a deepening pays back soonest. If the log is scattered with no clear hot spot, widen the net instead.

Look for: understanding one concept that means bouncing between many small modules; shallow modules (interface nearly as wide as the implementation); pure functions extracted only for testability while the real bug hides in how they're called; seams that leak; and what the other lenses catch — knowledge duplicated across modules, one module changing for unrelated reasons, coupling that makes a single edit ripple. Apply the deletion test to each suspect: would deleting it concentrate complexity, or just move it? "Concentrates" is the signal.