← ClaudeAtlas

sb-debuglisted

Use directly when the user asks why a Task failed or cannot be implemented. Establish the root cause, categorize it, and return a next action. Read-only; never starts implementation or applies the fix.
Huruikagi/specbind · ★ 3 · Code & Development · score 72
Install: claude install-skill Huruikagi/specbind
# Diagnose one failure The **diagnosis is the deliverable**. Someone else applies the fix, from a context that did not watch this failure happen. ## Final response contract — before any investigation Your final response is incomplete unless it ends with this exact parseable shape. Reserve it now and fill it from the evidence: ```text ## Diagnosis - CATEGORY: IMPLEMENTATION | REVIEW | PLAN | ARTIFACT | ENVIRONMENT | UNDETERMINED - CAUSE: <what diverges, and where> - NEXT_ACTION: <for whoever owns that category> - UNCERTAIN: <what remains open, or none> ``` Naming a category in prose does not satisfy this contract. Do not rename the heading, omit a field, or return only a narrative diagnosis. ## Apply project language style Before authoring any artifact or user-facing prose, read: ```sh specbind rule read language-style --for consume ``` Apply returned policy only to natural-language prose. `NO_CHANGE RULE_ABSENT` means no additional project preference; any `ERROR` line stops the workflow. ```sh specbind protocol read debug ``` ## Resolve the subject Use the explicit failure, Spec, and Task identity supplied by the caller. When a bare diagnosis request omits them, do not infer identity from a repository path or from whichever Task you notice first. ```sh specbind milestone status specbind tasks list <spec> ``` List Tasks for every active Spec in implementation. For a request that says a Task failed or cannot be implemented, candidates are blocked Tasks and pending