// Fast failure classifier. Decide whether the problem is a spec gap, an implementation bug, or a rollback candidate before routing to writing-plan, diagnose, or ship.
| name | ks-bug-triage |
| description | Fast failure classifier. Decide whether the problem is a spec gap, an implementation bug, or a rollback candidate before routing to writing-plan, diagnose, or ship. |
| layer | execution |
| owner | bug-triage |
| inputs | ["failure_description","context","recent_evidence"] |
| outputs | ["triage_report","triage_result"] |
| entry_modes | ["plan-ready","build-ready","incident"] |
Preamble: see templates/preamble.md
Quickly classifies a failure before the workflow spends time on the wrong branch. Decides whether the problem is a spec gap, an implementation bug, or a rollback candidate, then routes to the correct skill. Does not do root-cause analysis, formal verification, code repair, or replace diagnose, verify, or writing-plan.
A triage report is not a root-cause report.
Do not classify without minimal evidence. At minimum, know the symptom, the current expectation, and the impact scope.
rollback-candidateoutranks deep investigation. If the impact is high enough, containment comes before explanation.
| triage_result | Meaning | Route |
|---|---|---|
spec-gap | the current expectation, scope, or done criteria are wrong | writing-plan |
implementation-bug | the spec still holds, but the implementation or runtime behavior does not | diagnose |
rollback-candidate | impact is severe enough that rollback or containment must be evaluated first | ship |
Minimum required evidence: symptom, impact, current expectation.
If the only input is "it is broken", ask for minimum context:
Do not classify without minimal evidence. See E1.
If the current spec stays unchanged, should this still be repaired exactly as originally defined?
implementation-bugspec-gapFast decision rules:
Use spec-gap when:
Use implementation-bug when:
If the issue is already a high-impact runtime failure:
rollback-candidateUse rollback-candidate when:
| triage_result | Route | Why |
|---|---|---|
spec-gap | writing-plan | the scope or done criteria need revision |
implementation-bug | diagnose | root cause must be found before repair |
rollback-candidate | ship | containment/rollback evaluation comes first |
Symptom: "tests fail but the feature should work differently now"
→ spec-gap → writing-plan
Symptom: "returns wrong value for edge case, spec unchanged"
→ implementation-bug → diagnose
Symptom: "production endpoint returning 500s, users affected"
→ rollback-candidate → ship
Symptom: "new behavior contradicts approved done criteria"
→ implementation-bug → diagnose
Symptom: "done criteria are now clearly wrong for the real need"
→ spec-gap → writing-plan
Symptom: "data corruption visible in production"
→ rollback-candidate → ship
Symptom: "requirement changed but tests still test the old behavior"
→ spec-gap → writing-plan
Symptom: "API returns 404 for a route that should exist per spec"
→ implementation-bug → diagnose
## Triage Report
**Symptom**: [one sentence]
**Current expectation**: [what should happen]
**Impact scope**: [who is affected and how severe]
**Current evidence**: [logs, tests, or observations]
**triage_result**: [spec-gap / implementation-bug / rollback-candidate]
**Recommended next skill**: [writing-plan / diagnose / ship]
**Why**: [why this route fits the classification]
**Missing information**: [if anything is still missing]
When the symptom is reported but evidence is too thin to classify with confidence:
diagnose with confidence = 0.5diagnose is safe because diagnose will either find the root cause (confirming implementation-bug) or determine the spec is wrong (routing to writing-plan)When evidence supports both spec-gap and implementation-bug:
implementation-bug (the cheaper path to verify first)confidence = 0.7writing-plandecision: triage-complete confidence: 0.85 rationale: The failure was classified from the current evidence and the next workflow branch is explicit. fallback: If later evidence overturns the classification, rerun bug-triage or move directly into the more appropriate skill. escalate: false next_skill: writing-plan / diagnose / ship next_action: Follow the triage result into the next workflow step.
_KS_CLI="${KEYSTONE_CLI:-./keystone}"
$_KS_CLI state set last_decision "triage-complete" >/dev/null 2>&1 || true
$_KS_CLI state set artifacts.last_triage_result "${TRIAGE_RESULT:-implementation-bug}" >/dev/null 2>&1 || true
mkdir -p .keystone/telemetry/events
echo "{\"skill\":\"bug-triage\",\"ts\":\"$(date -u +%Y-%m-%dT%H:%M:%SZ)\",\"decision\":\"triage-complete\",\"triage_result\":\"${TRIAGE_RESULT:-implementation-bug}\"}" >> .keystone/telemetry/events/$(date +%Y-%m).jsonl
Lightweight task compressor. Turn messy input into a one-page brief that can route to roundtable or writing-plan without replacing direction decisions.
Formal quality gate with multi-persona review, confidence thresholds, and QA routing based on fresh verification evidence.
Direction convergence skill. Use brainstorm, align, or challenge mode to turn messy questions or existing proposals into a clear directional decision.
Use this when direction is already clear and the next job is to compress it into an executable block with scope, done criteria, and routing.
Use this when the system is broken, tests are failing, or behavior is abnormal and the root cause is still unknown. No investigation, no fix.
Use this when the current block is already clear and the job is to complete it. Default route comes from test-first; only controlled low-risk exceptions may enter directly.