Опишете задачата
Към всички skills

kiro-debug

gotalab · Разработка

Investigate implementation failures using root-cause-first debugging. Use when an implementer is blocked, verification fails, or repeated remediation does not converge.

Оригинален текст · няма потвърден превод на български
Платформи: Не са посочениНиво: Не е посоченоВ индекса: 21.09.2026 г.Обновен в GitHub: 20.05.2026 г.

Теми: agent-skills · claude-code · codex · cursor · gemini-cli · github-copilot · kiro · opencode · sdd · spec-driven-development · steering · subagents

Първо прочетете инструкцията.

Файлът се зарежда от посочения източник само по ваше действие. Можете да го прочетете тук, да го копирате или да го запазите като .md.

Оригинален SKILL.md
GitHub хранилище
Звезди на репото
3677
Лиценз
MIT
Последна проверка на записа
22.09.2026 г.

Добавете в своя инструмент.

Командата отваря избора на skills от репозитория. Прочетете файла и условията на автора преди изпълнение.

npx skills add gotalab/cc-sdd

Страницата копира текст. Не инсталира и не изпълнява нищо на устройството ви.

Откъс от SKILL.md

Началото на файла на автора, без превод.

kiro-debug

Overview

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.

When to Use

  • Implementer reports BLOCKED
  • Reviewer rejection repeats after remediation
  • Validation fails unexpectedly
  • A task appears to conflict with runtime or platform reality
  • The same failure survives more than one attempted fix

Do not use this skill to speculate about fixes before gathering evidence.

Inputs

Provide:

  • Exact failure symptom or blocker statement
  • Error messages, stack trace, and failing command output
  • Current git diff or summary of uncommitted failed changes
  • Task brief: what was being built
  • Reviewer feedback, if the failure came from review rejection
  • Relevant spec file paths (requirements.md, design.md)
  • Relevant requirement/design section numbers
  • Relevant ## Implementation Notes
  • Runtime or environment constraints already known

Outputs

Return:

  • ROOT_CAUSE
  • CATEGORY
  • FIX_PLAN
  • VERIFICATION
  • NEXT_ACTION: RETRY_TASK | BLOCK_TASK | STOP_FOR_HUMAN
  • CONFIDENCE: HIGH | MEDIUM | LOW
  • NOTES

Use the language specified in spec.json.

Method

1. Read the Error Carefully

Extract:

  • Exact error text
  • Stack trace or failure location
  • The command that produced the failure
  • Whether the failure is deterministic or intermittent

2. Inspect Local Runtime and Repository State

Inspect the repository for local evidence:

  • package.json, pyproject.toml, go.mod, Makefile, README*
  • Build config
  • tsconfig or equivalent language/runtime config
  • Runtime-specific config
  • Dependency versions and scripts
  • Relevant changed files from git diff

3. Search the Web if Available

If web access is available, search:

  • The exact error message
  • The technology + symptom combination
  • Official documentation
  • Version-specific issue trackers or migration notes

Prefer:

  • Official docs
  • Official repos/issues
  • Version-specific references
  • Runtime-specific documentation

4. Classify the Root Cause

Use one category:

  • MISSING_DEPENDENCY
  • RUNTIME_MISMATCH
  • MODULE_FORMAT
  • NATIVE_ABI
  • CONFIG_GAP
  • LOGIC_ERROR
  • TASK_ORDERING_PROBLEM
  • TASK_DECOMPOSITION_PROBLEM
  • SPEC_CONFLICT
  • EXTERNAL_DEPENDENCY

Целият SKILL.md в GitHub