Find code that is hard to follow or change because callers must coordinate details that belong together. Propose modules that hide those details and make the behavior easier to test.

When the user has already selected a candidate or concrete target change, inspect that target and proceed directly to exploring it. Do not produce another candidate menu or ask them to select it again. A named subsystem may instead limit discovery when the user is still asking which change would help.

This command is informed by the project's domain model and built on a shared design vocabulary:

Locate companion skills by name in the available skill catalog, using its supplied locations or loading mechanism. If one is unavailable, continue with the procedure here; do not infer its installation path or fetch external guidance.

Scope before you scan: YAGNI. Deepening a module pays off by making future changes to it easier, so put extra weight on the parts of the codebase that have recently changed. Decide where to look before you look:

Read the project's existing domain glossary and any ADRs in the area you're touching first.

Explore the scoped area directly. Delegate a bounded, read-only slice when delegation is available and an independent investigation can improve evidence or save time alongside useful local work. Give the agent the question, target modules or paths, known requirements and constraints, and the expected result: concrete code locations or caller traces, the maintenance cost they demonstrate, a plausible improvement, and any uncertainty. If delegation is unavailable or adds little value, continue locally.

Look for friction supported by the code:

Before recommending removal of a module, check whether that removes unnecessary forwarding or makes callers handle its work themselves. Verify delegated findings against the code before presenting them. Stop when you can explain a concrete cost and a useful improvement in the requested area, or identify the facts still missing. No worthwhile candidate is a valid result.

Follow the requested format and the environment's actual rendering capabilities. For a compact review, use concise prose with an inline diagram when the host can render it. For a portable report or a comparison that benefits from a separate artifact, use HTML. If visual rendering is unavailable, explain the relationships in text and state the limitation rather than blocking the analysis.

Use visuals where they clarify ownership, dependencies, caller effort, or the proposed change. A before/after diagram is useful when the structural difference matters; do not invent several candidates or diagram types merely to fill a report. Use the host's supported Mermaid rendering, inline SVG, or simple HTML/CSS as appropriate.

When writing an HTML report, use inline CSS and SVG so it opens without network dependencies. Save it to the requested location, otherwise to a fresh file in the OS temp directory. Use an available artifact preview to show it, or provide its absolute path and a link when opening is unavailable. Do not require a particular OS command or external browser.

For each candidate, provide the evidence needed to judge it:

Recommend the strongest candidate when discovery was requested. For a selected target, explain whether the evidence supports that change and proceed with its design question. Use concise explanatory prose wherever a diagram alone cannot communicate the contract or tradeoff.

Use the project's glossary vocabulary for domain concepts and preserve established names such as "Order service." Explain how those names map to the architectural roles under discussion when the distinction matters.

ADR conflicts: if a candidate contradicts an existing ADR, only surface it when the friction is real enough to warrant revisiting the ADR. Explain the conflict and the evidence for reopening the decision in the report. Don't list every theoretical refactor an ADR forbids.

Read HTML-REPORT.md only when producing an HTML artifact. Inspect the rendered report when the environment allows it and disclose any rendering gap; generating a file does not prove its diagrams are readable.

For discovery-only requests, deliver the findings and stop. If further exploration is requested but several materially different candidates remain, ask which to explore after presenting the evidence. When the target is already clear, continue without that selection pause.

Ground the selected candidate in its callers, constraints, dependencies, and existing tests. Reuse settled decisions and proceed directly to a concrete interface or migration recommendation when the evidence supports it. Use the skill when available for material unresolved choices; otherwise ask focused questions about those choices directly. Do not require an interview when no human decision is missing.

Use the skill when available to keep meanings and records aligned. Follow existing documentation conventions and the authorized working mode: write only when documentation updates are authorized, and keep proposed text in the conversation for read-only or discussion work.

Finish with the requested findings or design recommendation, its evidence, preserved contracts, and the verification or decision still needed. Implementation, commits, or external publication require authorization for that work; selecting a candidate alone does not authorize them.