targeted-debuglisted

## Live context !`git rev-parse --show-toplevel 2>/dev/null && echo "repo: $(basename $(git rev-parse --show-toplevel))" || echo "not a git repo"` !`git branch --show-current 2>/dev/null | sed 's/^/branch: /' || true` # targeted-debug A scope-bounded debug skill. Reads ONLY files explicitly named in the stack trace, error message, or user input. Forms a hypothesis from observable evidence. Does NOT explore the codebase broadly. Does NOT launch `/investigate`. Does NOT call MCP tools (Grafana, Slack, Jira) unless the user explicitly asks for them in this turn. ## Why this skill exists The `/insights` report flagged "Claude went into wide codebase exploration when the user wanted targeted debug" as a top-3 friction category. The full `/investigate` pipeline is the right tool for "I don't know what's happening, investigate the whole thing." This skill is the right tool for "here's the stack trace, tell me what's wrong" — and the explicit constraint that makes it work is a hard scope rule. ## Hard rules 1. **Read only what's named.** Files in scope are: (a) files mentioned by the user in their prompt, (b) files appearing in the stack trace they pasted, (c) files that the error message references by path. Anything else requires asking the user first. 2. **No `Glob` for unrelated paths.** `Glob` is allowed only to resolve the exact paths from rule 1 when they're relative or partial. 3. **No `Grep` outside in-scope files.** Use `Grep` only on the files from rule