# Spec Workflow

Drive the Kiro CLI v3 spec workflow (Requirements → Design → Tasks → Execution) for the...

- Repository: https://github.com/kirodotdev/KiroCrew (4711 stars)
- Category: Design
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add kirodotdev/KiroCrew --skill spec-workflow -g -a claude-code -y`
Codex: `npx skills add kirodotdev/KiroCrew --skill spec-workflow -g -a codex -y`
Cursor: `npx skills add kirodotdev/KiroCrew --skill spec-workflow -g -a cursor -y`
Gemini CLI: `npx skills add kirodotdev/KiroCrew --skill spec-workflow -g -a gemini-cli -y`

## 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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# Kiro Spec Workflow

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.

## Ground rules

- The seed message gives you exact absolute document paths, the absolute working
  directory, and a spec type. **Always write the spec files to those EXACT document
  paths**, never invent a different location.
  - `requirements.md`, `design.md`, `tasks.md` live in `<SPEC_DIR>/`.
  - The code you are planning for lives in `<WORKING_DIR>/`.
- Work **one phase at a time**. After writing each file, STOP and ask the user to review.
  Do NOT jump ahead to the next phase until the user approves (e.g. "looks good",
  "proceed to design", "continue").
- Ask **clarifying questions in chat** whenever the request is ambiguous in a way that
  would materially change the output. Ask focused questions (1, 3 at a time), state your
  recommended answer, and wait. Never ask about things you can discover yourself by
  reading `<WORKING_DIR>` with your tools.
- Keep every file self-contained, concrete, and free of placeholders.
- **Read the project's own conventions before you write anything.** Check
  `<WORKING_DIR>` for `.kiro/steering/**/*.md` and `AGENTS.md`, and read whatever you
  find. Those files carry the build commands, test layout, naming rules and review
  conventions the rest of the toolchain already honors, so a spec written without them
  can plan work that contradicts the repo it targets. Let them constrain the design and
  the task list (which test framework a task uses, which directory a module belongs in,
  how a change gets verified). When steering contradicts the user's request, say so in
  chat and ask which wins rather than silently picking one.

## Spec types

The rest: https://github.com/kirodotdev/KiroCrew/blob/HEAD/src/kiro_crew/apps/builtins/spec_builder/skills/spec-workflow/SKILL.md