kiro-debug
starsforks
How to install kiro-debug?
gotalab/cc-sdd/kiro-debug
$npx -y skills add gotalab/cc-sdd --skill kiro-debugInvestigate implementation failures using root-cause-first debugging. Use when an implementer is blocked, verification fails, or repeated remediation does not converge.
SKILL.md
| 1 | # kiro-debug |
| 2 | |
| 3 | <background_information> |
| 4 | This skill is for fresh-context root cause investigation. It combines local evidence, runtime/config inspection, and external documentation or issue research when available. It is not a patch generator for guess-first debugging. |
| 5 | </background_information> |
| 6 | |
| 7 | <instructions> |
| 8 | ## When to Use |
| 9 | |
| 10 | - Implementer reports `BLOCKED` |
| 11 | - Reviewer rejection repeats after remediation |
| 12 | - Validation fails unexpectedly |
| 13 | - A task appears to conflict with runtime or platform reality |
| 14 | - The same failure survives more than one attempted fix |
| 15 | |
| 16 | Do not use this skill to speculate about fixes before gathering evidence. |
| 17 | |
| 18 | ## Inputs |
| 19 | |
| 20 | Provide: |
| 21 | - Exact failure symptom or blocker statement |
| 22 | - Error messages, stack trace, and failing command output |
| 23 | - Current `git diff` or summary of uncommitted failed changes |
| 24 | - Task brief: what was being built |
| 25 | - Reviewer feedback, if the failure came from review rejection |
| 26 | - Relevant spec file paths (`requirements.md`, `design.md`) |
| 27 | - Relevant requirement/design section numbers |
| 28 | - Relevant `## Implementation Notes` |
| 29 | - Runtime or environment constraints already known |
| 30 | |
| 31 | ## Outputs |
| 32 | |
| 33 | Return: |
| 34 | - `ROOT_CAUSE` |
| 35 | - `CATEGORY` |
| 36 | - `FIX_PLAN` |
| 37 | - `VERIFICATION` |
| 38 | - `NEXT_ACTION: RETRY_TASK | BLOCK_TASK | STOP_FOR_HUMAN` |
| 39 | - `CONFIDENCE: HIGH | MEDIUM | LOW` |
| 40 | - `NOTES` |
| 41 | |
| 42 | Use the language specified in `spec.json`. |
| 43 | |
| 44 | ## Method |
| 45 | |
| 46 | ### 1. Read the Error Carefully |
| 47 | Extract: |
| 48 | - Exact error text |
| 49 | - Stack trace or failure location |
| 50 | - The command that produced the failure |
| 51 | - Whether the failure is deterministic or intermittent |
| 52 | |
| 53 | ### 2. Inspect Local Runtime and Repository State |
| 54 | Inspect the repository for local evidence: |
| 55 | - `package.json`, `pyproject.toml`, `go.mod`, `Makefile`, `README*` |
| 56 | - Build config |
| 57 | - `tsconfig` or equivalent language/runtime config |
| 58 | - Runtime-specific config |
| 59 | - Dependency versions and scripts |
| 60 | - Relevant changed files from `git diff` |
| 61 | |
| 62 | ### 3. Search the Web if Available |
| 63 | If web access is available, search: |
| 64 | - The exact error message |
| 65 | - The technology + symptom combination |
| 66 | - Official documentation |
| 67 | - Version-specific issue trackers or migration notes |
| 68 | |
| 69 | Prefer: |
| 70 | - Official docs |
| 71 | - Official repos/issues |
| 72 | - Version-specific references |
| 73 | - Runtime-specific documentation |
| 74 | |
| 75 | ### 4. Classify the Root Cause |
| 76 | Use one category: |
| 77 | - `MISSING_DEPENDENCY` |
| 78 | - `RUNTIME_MISMATCH` |
| 79 | - `MODULE_FORMAT` |
| 80 | - `NATIVE_ABI` |
| 81 | - `CONFIG_GAP` |
| 82 | - `LOGIC_ERROR` |
| 83 | - `TASK_ORDERING_PROBLEM` |
| 84 | - `TASK_DECOMPOSITION_PROBLEM` |
| 85 | - `SPEC_CONFLICT` |
| 86 | - `EXTERNAL_DEPENDENCY` |
| 87 | |
| 88 | ### 5. Determine the Smallest Safe Next Action |
| 89 | Decide whether the issue can be fixed inside this repo by: |
| 90 | - Editing files |
| 91 | - Adjusting configuration |
| 92 | - Adding or correcting dependencies |
| 93 | - Restructuring code |
| 94 | |
| 95 | Use `NEXT_ACTION: RETRY_TASK` when the issue is repo-fixable inside the current approved task plan. |
| 96 | |
| 97 | ### 6. Determine Whether the Task Plan Is Still Valid |
| 98 | Decide whether the current approved task plan is still safe to execute as written. |
| 99 | |
| 100 | Prefer `NEXT_ACTION: STOP_FOR_HUMAN` when: |
| 101 | - A missing prerequisite task should exist before this one |
| 102 | - The current task is ordered incorrectly relative to unfinished work |
| 103 | - The current task boundary is wrong and should be split or merged |
| 104 | - The task is too large or ambiguous to fix safely inside the current implementation loop |
| 105 | |
| 106 | Use `NEXT_ACTION: BLOCK_TASK` only when the current task should stop but the rest of the queue can still proceed safely. |
| 107 | |
| 108 | Do not propose a brute-force code fix as a substitute for revising `tasks.md` or the approved plan. |
| 109 | |
| 110 | ## Critical Rule |
| 111 | |
| 112 | Do not propose a multi-fix shotgun plan. Identify the root cause first, then produce the smallest plausible fix plan. If the true problem is a spec conflict or architecture problem, say so directly. |
| 113 | |
| 114 | ## Stop / Escalate |
| 115 | |
| 116 | Use `NEXT_ACTION: STOP_FOR_HUMAN` when the blocker genuinely requires: |
| 117 | - Human product/requirements decision |
| 118 | - External credentials or inaccessible services |
| 119 | - Hardware or unavailable external systems |
| 120 | - Re-scoping due to spec/platform conflict |
| 121 | |
| 122 | If the issue is fixable by repo changes inside the current task plan, do not escalate prematurely. |
| 123 | |
| 124 | ## Common Rationalizations |
| 125 | |
| 126 | | Rationalization | Reality | |
| 127 | |---|---| |
| 128 | | “This probably just needs a quick patch” | Patch-first debugging creates rework. | |
| 129 | | “Let’s try a few fixes” | Multi-fix guessing hides root cause. | |
| 130 | | “The spec is probably wrong, I’ll adapt it” | Spec conflicts must be surfaced explicitly. | |
| 131 | | “The docs search is optional” | For runtime/dependency issues, docs and version issues often contain the shortest path to root cause. | |
| 132 | |
| 133 | ## Output Format |
| 134 | |
| 135 | ```md |
| 136 | ## Debug Report |
| 137 | - ROOT_CAUSE: <1-2 sentence root cause> |
| 138 | - CATEGORY: MISSING_DEPENDENCY | RUNTIME_MISMATCH | MODULE_FORMAT | NATIVE_ABI | CONFIG_GAP | LOGIC_ERROR | TASK_ORDERING_PROBLEM | TASK_DECOMPOSITION_PROBLEM | SPEC_CONFLICT | EXTERNAL_DEPENDENCY |
| 139 | - FIX_PLAN: |
| 140 | 1. <specific repo- |
People who liked this also viewed
6 picksType
- azure-diagnosticsDebug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deploySkillsJul 2026
- systematic-debuggingUse when encountering any bug, test failure, or unexpected behavior, before proposing fixesSkillsJul 2026
- safe-debugRigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training SkillsMay 2026
- explore-runRigor Improve / Rigor Explore run leaf skill for bounded exploratory evidence in deep learning research repositories. Use when the researcher explicitly authorizes exploratory runs such as small-subseSkillsMay 2026
- minimal-run-and-auditRigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation SkillsMay 2026
- insforge-debugUse when diagnosing problems in an InsForge project — reactive failures (SDK error object, HTTP 4xx/5xx, gateway timeout 502/503/504, edge function failure or timeout, login/OAuth/auth errors, RLS denSkillsJul 2026
