Use when there are 2+ consecutive failures, repeated errors, or the work feels stuck - pauses implementation, switches to root-cause investigation, gathers evidence, and resumes only after a verified plan and options.
Use when editing an existing codebase and the goal is minimal, standard, and non-invasive changes - prioritizes simplest solution, standard libraries first, and surgical modification without unsolicited refactors.
Use when errors occur deep in execution and you need to trace back to find the original trigger - systematically traces bugs backward through call stack, adding instrumentation when needed, to identify source of invalid data or incorrect behavior.
Use when considering switching libraries/tools, changing architecture, or replacing automation with manual workarounds - explains root cause, offers 2-3 options with trade-offs, and requests explicit user choice.
Use when providing exact commands, flags, config keys, file paths, API details, standards, or version-specific behavior - enforces verification via official docs (Context7/web fetch), explicit citations, and bans assumption-based specifics.
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always.