kiro-debug

Diagnose implementation failures using root-cause-first debugging with structured debug reports.

Updated Jun 23, 2026
One-click install
npx skills add https://github.com/j5ik2o/marp-ai-base --skill kiro-debug-j5ik2o
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: kiro-debug
Source: https://github.com/j5ik2o/marp-ai-base/tree/main/.agents/skills/kiro-debug
Command: npx skills add https://github.com/j5ik2o/marp-ai-base --skill kiro-debug-j5ik2o

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? When an implementation task is blocked, verification fails, or repeated fixes do not converge, guess-first patching wastes effort and hides the real issue. This Skill enforces evidence-driven root cause investigation before any fix is proposed. ## Core Features & Use Cases - Root Cause Classification: Categorizes failures into types such as MISSING_DEPENDENCY, RUNTIME_MISMATCH, CONFIG_GAP, LOGIC_ERROR, or SPEC_CONFLICT. - Evidence Gathering Workflow: Reads exact error output, inspects repository state (package.json, tsconfig, git diff), and optionally searches official documentation and issue trackers. - Structured Debug Report: Produces ROOT_CAUSE, CATEGORY, FIX_PLAN, VERIFICATION, NEXT_ACTION (RETRY_TASK, BLOCK_TASK, or STOP_FOR_HUMAN), and CONFIDENCE fields. - Use Case: An implementer reports BLOCKED after two failed remediation attempts on a build error. This Skill inspects the error, dependency versions, and runtime config, identifies a native ABI mismatch, and returns a minimal fix plan with verification commands. ## Quick Start Investigate why my build keeps failing after two fix attempts and produce a root cause debug report with the smallest safe fix plan.

Frequently Asked Questions about kiro-debug

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I debug a blocked implementation task systematically?

Start with the exact error text, stack trace, and failing command, then inspect repository state such as package.json, tsconfig, and git diff. Classify the root cause before proposing any fix, and produce the smallest safe fix plan with verification commands.

What is root-cause-first debugging?

Root-cause-first debugging gathers evidence from errors, runtime config, and documentation before proposing fixes, rather than trying multiple patches. It prevents multi-fix guessing that hides the true cause and creates rework.

When should a blocked task be escalated to a human?

Escalate with STOP_FOR_HUMAN when the blocker requires product or requirements decisions, external credentials, unavailable hardware or services, or re-scoping due to a spec or platform conflict. Repo-fixable issues inside the current task plan should not be escalated.

Why do repeated fixes fail to resolve the same error?

Repeated failures usually mean the true root cause was never identified, such as a runtime mismatch, missing dependency, or task ordering problem. Patch-first attempts treat symptoms, so the same failure survives each remediation.

Can this debugging approach handle spec conflicts?

Yes, spec conflicts are an explicit root cause category. When the failure stems from contradictory requirements or design, the report surfaces the conflict directly instead of proposing a code workaround.