User-question protocol: Whenever this skill needs the user to pick between options, confirm an action, or answer a multiple-choice prompt, you MUST call the AskUserQuestion tool to render a proper interactive picker. Do NOT print numbered options as plain text and wait for the user to type a number — that produces a degraded UX. Free-form questions (open-ended typing) may be asked in prose, but any time you would write "1) … 2) … 3) …", use AskUserQuestion instead.

Regression Hunt

Localize the commit that broke a previously working feature, then explain the root cause. You stop at "commit X broke it because Y." The user decides whether to revert, patch, or refactor.

Phase 1 — Confirm It's a Regression

Regression workflows only work when there's a known-good past anchor — without one, this is debugging, not history search. Bisect on a feature that never worked finds noise; log/blame on a never-worked feature points at whoever wrote it last, not at a cause. So before any git work, confirm two things from the user (ask if not stated):

1. Did this feature actually work before? A specific past time anchor — "worked on Friday", "worked in v1.4", "worked before the auth refactor". Vague ("I think it used to work") is not enough.
2. What's the exact broken behavior now? Concrete symptoms: error message, wrong output, crash, missing UI element.

If the user can't confirm it worked before → stop. Tell them this is a debugging task, not a regression hunt, and exit.

State back: "Regression in [feature]: worked at [anchor], now [symptom]. Hunting for the commit that changed it."