keel-debug-failure
Purpose
Use this skill when a command or validation path fails. Keep the investigation tied to the selected OpenSpec task. This skill owns when to stop, the task-contract binding, checkout preservation, and the failure-report shape; generic diagnosis mechanics (how to reproduce, minimise, or instrument) belong to the host runtime and are not restated here.
Context to read
Read the selected OpenSpec task's Commands, Acceptance, Coupling, Candidate Boundary, Autonomy boundary, Stop Rules, Evidence, Stop if, Read, Touch, and Mode fields. When Coupling: required, also read design.md's Coupled Iteration Contract. Read the failed command output and any repository files needed to reproduce or explain the failure.
Domain lenses
When the change's artifacts or the failing surface signal a domain, consult the matching lens's Execution and review checks section from keel/lenses/ — the lens whose Applies when: header matches — before locking a root-cause hypothesis. When no lens matches, load nothing.
Stopping
There is no fixed attempt count: keep going while each attempt adds evidence, and stop when one does not. When you stop, report the original key error plus what changed during each attempt.
For Coupling: required, an allowed provisional failure inside a candidate is
expected rather than a stop; the evidence that matters is the final assertion
at the candidate completion gate. Follow the task's immediate task-stop
rules for scope breach, missing design authority, non-reproducible evidence,
or a baseline or acceptance change during a candidate.
Preserve the current checkout on verification failure or context pressure.
Only roll back to last-green when the selected task or human instruction
explicitly authorizes it, and keep the failure evidence available.
Report boundary
Follow-ups are limited to directly observed blockers, risks, missing scope, or escalation needs. Do not include roadmap suggestions, new feature suggestions, unrelated architecture critique, or opportunistic refactor suggestions.
When the minimal fix needs files outside Touch, report an Out-of-scope Need with file or area, why needed, consequence if unchanged, minimal proposed change, and evidence. Do not modify those files.
Standalone use
When used alone, report Summary, Failed command, Failure evidence, Attempts, Current hypothesis, and Required decision.