user-debuglisted

# User Debug Run a bug report end-to-end: investigate, reproduce, design, fix, verify. Avoid the command-paste loop with the user. Run diagnostic commands yourself, read logs yourself, and verify CLI suggestions against argparse before invoking them. ## When to use Use `/user-debug` when: - Something is broken and you want a fix, not just a discussion. - You have a symptom (log line, error, screenshot) but not a confirmed root cause. - You want the LLM to do the triage instead of pasting commands back and forth. Use something else when: - The fix is a one-character typo you can do faster yourself. - You want to discuss the design before committing — use a regular conversation. - The work is forward-feature, not a bug — use `/build-step`. ## Arguments | Arg | Required | Default | Description | |---|---|---|---| | `--symptom` | yes | -- | What's broken. Quote the error, log line, or describe the misbehavior precisely. | | `--repro` | no | -- | Command or steps to reproduce. If omitted, the skill derives one from the symptom. | | `--issue` | no | -- | GitHub issue number to link/close. | | `--triage` | no | `quick` | `quick` (worktree + reviewers) or `investigate-only` (Diagnosis Block then stop). `full` is accepted as a deprecated synonym for `quick` — the prior TDD-driven `full` mode delegated to `/build-step-tdd`, which was archived 2026-05-24 after 0 invocations. | | `--review` | no | `code` | `none`, `code` (review-gauntlet lean profile), `auto` (gates only). App