investigatelisted

# Investigate A diagnosis gate for bug work. Andy's usage data shows repeated cycles where a plausible fix is shipped before the real failure mode is understood — tvOS IAP rejection patched as product-loading when the bug was focus management; gaze replay patched as routing when the bug was coordinate-space; OptiGest tests green on synthetic data while the live app stayed broken. This skill enforces diagnosis before edit. ## When to invoke User runs `/investigate <bug summary>` when a bug is reported or discovered. Do NOT propose or write fix code until the user confirms the diagnosis produced by this skill. ## When to skip The ~5–10K token overhead is pure tax on obvious bugs. Skip this skill when: - The cause is stated in the error message (typo, import error, off-by-one in a visible loop). - The fix is a one-line change and the call path is already in context. - The user explicitly names both the cause and the fix. Use it when the symptom could plausibly come from more than one layer (logic / state / boundary / validation gap / build) — that's where misdiagnosis cascades burn 50–200K tokens. ## The contract Complete these five steps **in order**. Stop and wait for user input after step 5. ### 1. Reproduce or confirm the failure mode - If the user gave error output / screenshot / console log, quote the exact line that proves the bug. - If not, ask for it before continuing — do not guess. One ask, then wait. ### 2. Read the failing code path end-to-end - Grep fo