Investigation Mode

Overview

This skill provides a hard stop and a repeatable workflow when progress stalls or errors repeat. It prevents “random walk” fixes and forces evidence-first debugging.

Use when...

• There are 2+ consecutive failures/errors in the same feature or approach

• The same error comes back after “fixes”

• There is temptation to “just workaround” or change approach silently

• The problem statement is unclear and implementation would be guesswork

Symptoms / keywords

• “stuck”, “still failing”, “same error”, “again”, “flaky”, “intermittent”, “can’t reproduce”, “works on my machine”

• “quick workaround”, “let’s just do it manually”, “skip validation”, “good enough”

• CI-only failures, nondeterministic tests, repeating TypeScript/build/lint errors

Rules (verbatim triggers)

Failure response rules

• 2+ consecutive failures: Switch to investigation mode

• Ask before: Using workarounds or alternatives

• Explain: Why original approach failed

• Options: Use task-direction-approval (2–3 options + trade-offs; ask user when changing direction).

Core: Respect user's original intent. When stuck, find proper solutions rather than taking shortcuts.

After 2 consecutive errors in same feature

• 🛑 PAUSE - Stop implementation immediately

• 🔍 INVESTIGATION MODE - Switch focus to root cause analysis

• 📖 Deep Research - Dispatch a research subagent to execute web fetch for official docs, RFCs, known issues and return a cited Context Package

• 🧠 Sequential-thinking - Analyze fundamental misunderstanding

• 🧪 Test First - Write comprehensive tests before continuing

Declare mode switch: "🔍 INVESTIGATION MODE: Pausing to research root cause"

Workflow

• Freeze changes: stop making further edits that are not evidence-driven.

• Capture evidence: record the exact error text, stack traces, logs, and minimal repro steps.

• Constrain scope: isolate the smallest failing unit (single test, single endpoint, single build step).

• Run root cause analysis:

• REQUIRED SUB-SKILL: Use root-cause-tracing for systematic isolation techniques.

• Use uncertainty-verification when the fix depends on exact tool/library behavior.

• Propose options: Use task-direction-approval (2–3 options + trade-offs).

• Ask approval if direction changes:

• REQUIRED SUB-SKILL: Use task-direction-approval when switching library/tool/architecture or replacing automation with manual workaround.

• Resume only after selecting a plan and (when applicable) verifying it with a small test.

Common mistakes

• Continuing to code while the failure mode is not understood

• Changing direction silently instead of asking for approval

• “Fixing” by adding retries/timeouts without evidence