Kiro Spec BatchSAFE

Turn approved specs into long-running autonomous implementation. A minimal, adaptable SDD harness with Agent Skills for Claude Code, Codex, Cursor, Copilot, Windsurf, OpenCode, Gemini CLI, and Antigravity.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: kiro-spec-batch
description: Create complete specs (requirements, design, tasks) for all features in roadmap.md using parallel sub-agent dispatch by dependency wave.
---


# Spec Batch

<background_information>
- **Success Criteria**:
  - All features have complete spec files (spec.json, requirements.md, design.md, tasks.md)
  - Dependency ordering respected (upstream specs complete before downstream)
  - Independent features processed in parallel via sub-agent dispatch
  - Cross-spec consistency verified (data models, interfaces, naming)
  - Mixed roadmap context understood without breaking `## Specs (dependency order)` parsing
  - Controller context stays lightweight (sub-agents do the heavy work)
</background_information>

<instructions>

## Step 1: Read Roadmap and Validate

1. Read `{{KIRO_DIR}}/steering/roadmap.md`
2. Parse the `## Specs (dependency order)` section to extract:
   - Feature names
   - One-line descriptions
   - Dependencies for each feature
   - Completion status (`[x]` = done, `[ ]` = pending)
3. If present, also read for context:
   - `## Existing Spec Updates`
   - `## Direct Implementation Candidates`
   Do not include these in dependency-wave execution; they are awareness-only inputs for sequencing and consistency review.
4. For each pending feature in `## Specs (dependency order)`, verify `{{KIRO_DIR}}/specs/<feature>/brief.md` exists
5. If any brief.md is missing, stop and report: "Missing brief.md for: [list]. Run `/kiro-discovery` to generate briefs first."

## Step 2: Build Dependency Waves

Group pending features into waves based on dependencies:

- **Wave 1**: Features with no dependencies (or all dependencies already completed `[x]`)
- **Wave 2**: Features whose dependencies are all in Wave 1 or already completed
- **Wave N**: Features whose dependencies are all in earlier waves or already completed

Display the execution plan:
```
Spec Batch Plan:
  Wave 1 (parallel): app-foundation
  Wave 2 (parallel): block-editor, page-management
  Wave 3 (parallel): sidebar-navigation, database-views
  Wave 4 (parallel): cli-integration
  Total: 6 specs across 4 waves
```

If roadmap contains `## Existing Spec Updates` or `## Direct Implementation Candidates`, mention them separately as non-batch items so the user can see the whole decomposition.

## Step 3: Execute Waves

For each wave, dispatch all features in the wave as **parallel sub-agents**.

**For each feature in the wave**, spawn a sub-agent with this task:

```
Create a complete specification for feature "{feature-name}".
Bind the feature argument in each phase to "{feature-name}" (including `$1` or `{feature}` references). This batch uses the existing fast-track mode: supply `-y` to design and tasks before entering their approval checks. Required phase review gates still apply.

1. Read the brief at {{KIRO_DIR}}/specs/{feature-name}/brief.md for feature context
2. Read the roadmap at {{KIRO_DIR}}/steering/roadmap.md for project context
3. Execute the full spec pipeline. For each phase, read the corresponding skill's SKILL.md for complete instructions (templates, rules, review gates):
   a. Initialize: If spec.json already exists, reuse that spec without reinitializing or renaming it. Otherwise read .gemini/skills/kiro-spec-init/SKILL.md; use the brief as the project description and initialize spec.json and requirements.md in the existing brief directory. Later phases may update their own artifacts.
   b. Generate requirements: Read .gemini/skills/kiro-spec-requirements/SKILL.md and execute for feature "{feature-name}"
   c. Generate design: Read .gemini/skills/kiro-spec-design/SKILL.md and execute with arguments "{feature-name} -y", including required design review
   d. Generate tasks: Read .gemini/skills/kiro-spec-tasks/SKILL.md and execute with arguments "{feature-name} -y", including required task review
4. Let each successful phase record its approvals through its documented fast-track flow. If a phase review fails or needs human input, stop this feature and report the blocker; do not force its approvals to true
5. Report completion with file list and task count
```

If multi-agent is not available, execute features in the wave sequentially.

**After all sub-agents in the wave complete**:
1. Verify each feature has: spec.json, requirements.md, design.md, tasks.md
2. If any feature failed, report the error and continue with features that succeeded
3. Display wave completion: "Wave N complete: [features]. Files verified."
4. Proceed to next wave

## Step 4: Cross-Spec Review

After all waves complete, spawn a **single sub-agent** for cross-spec consistency review. Use the `spec-reviewer` agent if available (defined in `.gemini/agents/spec-reviewer.md`). This is the highest-value quality gate -- it catches issues that per-spec review gates cannot.

**Sub-agent task**:

Read ALL generated specs and check for consistency across the entire project:
- `{{KIRO_DIR}}/specs/*/design.md` (primary: contains interfaces, data models, architecture)
- `{{KIRO_DIR}}/specs/*/requirements.md` (for scope and acceptance criteria)
- `{{KIRO_DIR}}/specs/*/tasks.md` (for boundary annotations only -- read _Boundary:_ lines, skip task descriptions)
- `{{KIRO_DIR}}/steering/roadmap.md`

Reading priority: Focus on design.md files (they contain interfaces, data models, architecture). For requirements.md, focus on section headings and acceptance criteria. For tasks.md, focus on _Boundary:_ annotations.

Check:
1. **Data model consistency**: Same entities defined consistently across specs (field names, types, relationships)
2. **Interface alignment**: Where spec A outputs what spec B consumes, do contracts match exactly?
3. **No duplicate functionality**: Any capability specified in more than one spec?
4. **Dependency completeness**: Every design.md references correct upstream specs? Implicit dependencies not in roadmap?
5. **Naming conventions**: Component names, file paths, API routes, table names consistent across sp

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.