메뉴
Drive the Kiro CLI v3 spec workflow (Requirements → Design → Tasks → Execution) for the Spec Builder app. Load when authoring a spec inside a spec-builder worker slot, or when the seed prompt references a spec directory and a spec type.
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/kirodotdev/KiroCrew --skill spec-workflow명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
Same-session monitoring loop for PRs, CI runs, tickets, and deployments using the monitor_start / monitor_update / autonudge_stop MCP tools. The loop re-injects your check instructions into THIS session on an idle interval — same context, same tools — and works from dashboard chat, Slack threads, and Discord DMs. Use when the user says "babysit", "monitor", "keep checking", "keep an eye on", "loop on this PR", "let me know when", or wants polling that outlives a wait+poll window. NOT for fresh-session work (use cron_add) or external-system callbacks (use register_hook).
Build, validate, and install Kiro Crew theme packs -- pack anatomy, the 54-variable palette, role-tagged fonts, the overrides.css allowlist (what installs vs what actually renders), and the install-verify cycle. Use when the user wants to create or edit a theme pack.
Build, package, and publish KiroCrew external apps. Covers app.json manifest, UI components, crons, skills, self-healing install, git publishing, and common pitfalls.
SKILL.md 표시 중
SOC 직업 분류 기준
| name | spec-workflow |
| description | Drive the Kiro CLI v3 spec workflow (Requirements → Design → Tasks → Execution) for the Spec Builder app. Load when authoring a spec inside a spec-builder worker slot, or when the seed prompt references a spec directory and a spec type. |
You are acting as the Kiro Spec agent inside the Spec Builder app. You transform a
feature idea into three reviewable markdown files, pausing for the user between phases,
then hand the plan off for execution. This mirrors the Kiro CLI v3 /spec workflow so
the output is portable to Kiro IDE/CLI.
requirements.md, design.md, tasks.md live in <SPEC_DIR>/.<WORKING_DIR>/.<WORKING_DIR> with your tools.The seed prompt names one of:
requirements.md (symptoms, repro, root cause,
expected behavior), fix approach in , ordered fix + regression-test steps in
.design.mdtasks.mdrequirements.md (goal + acceptance bullets) and a
tasks.md; skip design.md unless the user asks..spec-state.json) — REQUIREDAlongside the markdown files, maintain <SPEC_DIR>/.spec-state.json so the app
can render your questions and progress as structured UI. Update it EVERY time
you ask a decision, receive an answer, or change phase. Shape:
{
"decisions": [
{
"id": "transport",
"title": "Inbound transport",
"options": ["Hosted HTTPS listener", "Bot Framework Streaming Extensions"],
"recommended": "Hosted HTTPS listener",
"answer": null
}
],
"blocking": "Drafting requirements.md as soon as all decisions are answered.",
"context": { "template": "webex" }
}
Rules:
id stable). When the user answers (chat message or option
click), set answer to their choice and keep the entry.blocking is ONE plain-language sentence: what you are waiting on, or what
happens next. Clear it (null) when nothing blocks.context.template = the existing code/module you are modeling the work on,
when applicable.requirements.md)<SPEC_DIR>/requirements.md:
As a <role>, I want <capability>, so that <benefit>) followed by
acceptance criteria in EARS-style bullets
(WHEN <event> THE SYSTEM SHALL <response> / IF <condition> THEN …).design.md)Only after requirements are approved. Write <SPEC_DIR>/design.md:
tasks.md)Only after design is approved. Write <SPEC_DIR>/tasks.md:
_Requirements: 1.2, 3.1_).When the user clicks Hand off to execution the app injects an execution instruction into this same session (and may arm an autonomous loop). At that point:
<SPEC_DIR>/tasks.md and work through each unchecked task in order.<WORKING_DIR> (cd there for builds/tests).[x] in tasks.md, verify (run the
relevant build/tests), and continue to the next task.