sunrain520/spec-first/spec-debug

Debug and Fix

Find root causes, then fix them. This skill investigates bugs systematically — tracing the full causal chain before proposing a fix — and optionally implements the fix with test-first discipline.

Workflow Contract Summary

• 输入： 可复现的失败、错误、回归、stack trace、issue 或明确异常行为。
• 输出： 证据闭合的 causal chain、最小修复、回归验证与结构化 handoff；若未授权修复则只返回诊断。
• 硬出口： 无法复现且缺 replacement evidence、因果链仍有未验证跳步、target repo/source owner/dirty overlap 未解决，或 required verification 失败时不得声明 root cause/fix complete。
• 权威： 运行时复现、source、test 与 log 提供事实；LLM 判断因果充分性；诊断、local mutation、commit 与 landing 分别授权。
• 消费者： 用户、spec-work、spec-code-review、issue/PR owner 与后续知识沉淀流程。

<bug_description> #<invocation arguments supplied by the current host> </bug_description>

Mode

The default mode is interactive. Investigate, present the causal chain, and use the Phase 2 fix-choice gate and Phase 4 handoff as written below.

When the invocation includes mode:pipeline-return, strip that token from <bug_description> and load references/pipeline-return.md. This mode is for an outer workflow such as spec-lfg: it replaces blocking questions with conservative defaults, applies only an inherited and explicitly authorized local convergent fix, and returns a structured envelope to the caller. The mode token does not authorize mutation, commit, push, external communication, credentials, or tracker writes.

Scenario Capability

Follows docs/contracts/workflows/scenario-capability-matrix.md. Overrides: high-risk

• foreign-residual-workspace -> blocked-action-required: stop before fix mutation, root-cause-confirmed claims that depend on suspect local artifacts, commits, or PR-ready handoff until the named cleanup/init action runs or the user explicitly accepts degraded evidence.
• optional external-tool evidence unavailable -> fallback-only: continue with bounded direct source, test, log, runtime-probe, and user-provided evidence; disclose the missing capability and do not extend root-cause or blast-radius claims beyond that evidence.
• non-git-build-workspace coverage gaps -> partial: keep investigation/fixes inside the explicit target_repo or inspected build surface and directly inspect uncovered modules before claiming they are unaffected.

Core Principles

1. Investigate before fixing. Do not propose a fix until you can explain the full causal chain from trigger to symptom with no gaps. "Somehow X leads to Y" is a gap.
2. Predictions for uncertain links. When the causal chain has uncertain or non-obvious links, form a prediction — something in a different code path or scenario that must also be true. If the prediction is wrong but a fix "works," you found a symptom, not the cause. When the chain is obvious (missing import, clear null reference), the chain explanation itself is sufficient.
3. One change at a time. Test one hypothesis, change one thing. If you're changing multiple things to "see if it helps," stop — that is shotgun debugging.
4. When stuck, diagnose why — don't just try harder.

Anti-Rationalization Red Flags

这是注意力提醒,不是 gate,也不替代 LLM 判断;最终是否停下、如何处理仍由你按当前证据决定。

Execution Flow

Beyond the trivial-bug fast-path in Phase 0, no further phase skipping — complex bugs simply spend more time in each phase naturally. No further complexity tiers.

Phase 0: Triage

Parse the input and reach a clear problem statement.

Repository and source boundary: Resolve the current Git root before repo-dependent investigation. In a parent workspace, bounded read-only orientation may compare likely child repos, but require a single target_repo or explicit per-fix repo scope before any behavior-bearing test, instrumentation write, or fix. Do not let cwd or broad discovery choose a sibling repo. Canonical checked-in source is the fix owner; generated runtime mirrors under .claude/, .codex/, .agents/skills/, .cursor/, .kiro/, or .qoder/ are not source. If runtime drift is causal, repair source/generation first and regenerate only with explicit authorization.

If the input references an issue tracker, fetch it:

• GitHub (#123, org/repo#123, github.com URL): Parse the issue reference from <bug_description> and fetch with gh issue view <number> --json title,body,comments,labels. For URLs, pass the URL directly to gh.
• Other trackers (Linear URL/ID, Jira URL/key, any tracker URL): Attempt to fetch using available MCP tools or by fetching the URL content. If the fetch fails — auth, missing tool, non-public page — ask the user to paste the relevant issue content. Ensure the fetch includes the full comment thread, not just the opening description.

Read the full conversation — the original description AND every comment, with particular attention to the latest ones. Comments frequently contain updated reproduction steps, narrowed scope, prior failed attempts, additional stack traces, or a pivot to a different suspected root cause; treating the opening post as the whole picture often sends the investigation in the wrong direction. Extract reported symptoms, expected behavior, reproduction steps, and environment details from the combined thread. Then proceed to Phase 1.

Everything else (stack traces, test paths, error messages, descriptions of broken behavior): the problem statement is the input itself.

Trivial-bug fast-path: Once the problem is clear, decide whether the framework is needed at all. If the cause is immediately readable from the input (single-file typo, missing import, obvious null deref or off-by-one with a one-line fix) and verification doesn't require deep tracing, present the cause and the proposed one-line fix and run Phase 2's Fix it now / Diagnosis only user-choice gate before editing — the fast-path saves investigation ceremony, not the user's choice over whether to apply a fix. If the user picks fix, run Phase 3's Workspace and branch check (uncommitted-work confirmation and default-branch branch-creation prompt), apply the fix, leave a one-line note explaining the cause, and skip to Phase 4's structured summary. If diagnosis only, write the summary and stop. When in doubt, run the full framework; getting the wrong root cause costs more than the few minutes of ceremony.

Otherwise, proceed to Phase 1.

Questions:

• Do not ask questions by default — investigate first (read code, run tests, trace errors)
• Only ask when a genuine ambiguity blocks investigation and cannot be resolved by reading code or running tests
• When asking, ask one specific question

Prior-attempt awareness: If the user signals they lack or have exhausted attempts — "I've been trying", "keeps failing", "stuck", "试了好几次" — ask what they have already tried before any investigation step. The attempts list prevents repeating known-failed paths; a later diagnostic question about environment or startup is not a substitute for it. This is one of the few cases where asking first is the right call.

Phase 1: Investigate

1.1 Reproduce the bug

Confirm the bug exists and understand its behavior. Run the test, trigger the error, follow reported reproduction steps — whatever matches the input.

• Browser bugs: Delegate browser execution to the internal spec-test-browser owner with current target-origin:<exact-loopback-origin>. spec-debug owns reproduction intent, route selection, diagnosis, and result interpretation; it never constructs agent-browser argv or bypasses the owner's exact-origin/effect/private-evidence gates. Consume only the returned route/step facts and private evidence refs. Missing or invalid origin, unavailable owner capability, or a durable/external effect without authorization is a visible not-run/not-supported reproduction limitation, not permission to fall back to another direct browser runner.
• Manual setup required: If reproduction needs specific conditions the agent cannot create alone (data states, user roles, external services, environment config), document the exact setup steps and guide the user through them. Clear step-by-step instructions save significant time even when the process is fully manual.
• Does not reproduce after 2-3 attempts: Read references/investigation-techniques.md for intermittent-bug techniques.
• Cannot reproduce at all in this environment: Document what was tried and what conditions appear to be missing.
• Writing the reproduction test: Orient on testing conventions from the current target repo/worktree immediately before authoring the failing test. Read the active root and scoped AGENTS.md/CLAUDE.md guidance plus representative existing tests; record the current git identity and dirty state when available. Do not persist or reuse this orientation across runs, branches, or worktrees. If guidance is unreadable or absent, record that concrete degraded fact and use only the observable style in readable existing tests. Use an existing failing test when it already captures the bug, update an existing test when it owns the contract but has the wrong expectation, strengthen an over-mocked test when it should have caught the bug, or add a new minimal isolated test only when no existing test is the right home. The chosen test must fail on the current bug and pass once the corrected behavior lands; name it descriptively so the failure message itself explains the bug.

1.2 Verify environment sanity

Before deep code tracing, confirm the environment is what you think it is:

• Correct branch checked out; no unintended uncommitted changes
• Dependencies installed and up to date (bun install, npm install, bundle install, etc.) — stale node_modules/vendor is a frequent false lead
• Expected interpreter or runtime version (check .tool-versions, .nvmrc, Gemfile, etc. against what's actually active)
• Required env vars present and non-empty
• No stale build artifacts (dist/, .next/, compiled binaries from an earlier branch)
• Dependent local services (database, cache, queue) running at expected versions when the bug plausibly involves them

1.3 Trace the code path

Trace data flow backward from the symptom to where valid state first became invalid. Read code-shape to form a hypothesis, then verify with observed values — do not theorize from code alone.

Concrete recipe:

1. Read the stack trace bottom-to-top, opening each frame's source. The bottom frame is the symptom; the root cause is somewhere upstream.
2. Identify the first frame where the input data is already invalid — that's the upper bound on where to look.
3. Instrument the boundaries around that frame: targeted log/print statements, debugger breakpoints, or test assertions that capture actual values at function entry/exit. Assumed values lie; observed values don't.
4. Walk the boundaries until valid input becomes invalid output. That transition is the root cause site.

Do not stop at the first function that looks wrong — the root cause is where bad state originates, not where it is first observed.