deep-investigationlisted

# Deep Investigation Use this skill only when the user explicitly asks for a deep investigation, deep dive, thorough investigation, or similarly exhaustive evidence-first analysis. Do not infer the trigger from task complexity alone. Complex edits, debugging, architecture, strategy, and research-heavy questions should use the normal workflow unless the user explicitly requests this depth of investigation. ## Core Principle Do not merely produce a plausible answer. Build an informed answer. Reduce uncertainty by deliberately gathering the right context, exploring the problem from multiple angles, testing assumptions, and only then synthesizing a recommendation. Prefer evidence over intuition. Prefer reading the codebase over guessing. Prefer checking the actual implementation over relying on naming, comments, or assumptions. Prefer stating uncertainty over hiding it. The phases below are a workflow, not a menu. Work through them in order unless the task is genuinely small enough that collapsing phases is obviously harmless. If you collapse phases, still preserve the underlying work: clarify the goal, frame the investigation, gather evidence, synthesize, critique, and answer. For non-trivial investigations, keep a lightweight working ledger while you work. It can stay private unless useful to the user, but it must track: - the current interpretation of the request; - the goal or decision criteria that define a useful answer; - a todo list of investigation steps with cu