grill-to-kiro

Grill to Kiro

grill-with-docs An entry skill for passing to Kiro's discovery / spec init after solidifying domain terminology and design decisions.

Purpose

Because Kiro strongly drives requirements / design / tasks, if input is passed while still ambiguous, the ambiguity gets fixed on the spec side. This skill clarifies the following before passing to Kiro.

• domain terminology: CONTEXT.md canonical terms to keep in, terms to avoid, and invariants
• accepted decisions: docs/adr/* decisions involving irreversibility, non-obviousness, and trade-offs that should be kept in
• spec boundary: the scope owned by the Kiro spec, the scope not owned, and adjacent specs / subsystems
• handoff input: kiro-discovery or kiro-spec-init a summary that does not depend on the conversation alone

Entry Decision

Use this skill when the request is near the entry point of Kiro / SDD.

• You want to turn a new feature, mechanism, or improvement idea into a spec
• kiro-discovery or kiro-spec-init you want to proceed to
• You want to solidify the request before entering requirements / design / tasks
• CONTEXT.md There appear to be terms or decisions that should be kept in or in an ADR
• The user says things like "boil it down before Kiro" or "grill before spec"

Cases where it is not used:

• You only want to check the status of an existing spec
• You are only continuing already-approved requirements / design / tasks / implementation
• A clearly spec-unnecessary small fix, configuration change, or simple refactoring
• The user explicitly instructs to skip grilling and proceed directly to Kiro

Procedure

1. Lightly check existing context

AGENTS.md / CLAUDE.md の Project Context Sources Follow and check only what exists. Do not stop just because a file does not exist.

• CONTEXT.md, CONTEXT-MAP.md
• docs/adr/
• docs/agents/
• .kiro/steering/
• .kiro/specs/**
• openspec/**

At this stage, do not create new Kiro artifacts. Limit this to grasping existing vocabulary, ADRs, and spec boundaries.

2. Run grill-with-docs first

grill-with-docs Use to boil the user's request down to a granularity that can be passed to Kiro.

Do not line up questions all at once; ask one at a time in an order that is effective for boundary decisions. For things that can be answered by reading code or existing docs, confirm them without asking the user.

At a minimum, clarify the following.

• Whose problem, and what kind of problem, is it
• What is the current state, and what is lacking
• What must be true after completion
• The scope owned by the Kiro spec
• The scope not owned by the Kiro spec
• The relationship with existing specs / subsystems / public contracts
• Newly established domain terms / avoid terms / invariants
• Whether there are decisions involving irreversibility, non-obviousness, and trade-offs that should be made into ADRs

Once terminology is settled, keep it in CONTEXT.md . For ADRs, follow the criteria of domain-modeling and keep them in only when necessary docs/adr/* .CONTEXT.md Treat as a glossary, not a spec or work plan.

3. Create a Kiro handoff

Before handing off to Kiro, create the following handoff rather than using the raw conversation log.

## Kiro Handoff

### Problem
[誰が、何に困っているか]

### Current State
[現状と不足]

### Desired Outcome
[完了後に真であるべきこと]

### Scope
- In: [...]
- Out: [...]

### Boundary Candidates
- [...]

### Upstream / Downstream
- Upstream: [...]
- Downstream: [...]

### Domain Context Updates
- CONTEXT.md: [追加・更新した用語。なければ none]
- ADR: [作成・検討した ADR。なければ none]

### Kiro Route
[kiro-discovery | kiro-spec-init | no-spec]

Use this handoff as Kiro's input. Do not pass the user's original request text to Kiro as-is.

4. Connect to Kiro

Based on the handoff, choose one of the following.

• Boundaries are still under exploration, or multi-scope / mixed decomposition is possible: $kiro-discovery "<handoff summary>"
• Single-spec boundaries and feature name are sufficiently clear: $kiro-spec-init "<handoff summary>"
• No spec needed: do not proceed to Kiro; propose direct implementation or another workflow

kiro-discovery が .kiro/specs/<feature>/brief.md や .kiro/steering/roadmap.md , after creating it, re-read it to confirm that the terms, boundaries, and ADR decisions settled in grill-with-docs have not been dropped.

kiro-spec-init , if an existing brief.md exists, prioritize it; otherwise use the handoff as the project description.

Prohibitions

• Do not pass an ambiguous initial request as-is to kiro-discovery / kiro-spec-init .
• CONTEXT.md : do not mix implementation details, tasks, or spec body text into it.
• Do not create ADRs as a spec ledger.
• kiro-* : do not rewrite the distributed skill itself for this workflow.
• Do not proceed on your own through requirements / design / tasks / implementation. Advance to downstream phases only when the user explicitly requests continuation.

Completion criteria

This skill is complete when one of the following holds.

• grill-with-docs reflecting the results of CONTEXT.md / docs/adr/* and the Kiro handoff are both in place, andkiro-discovery or kiro-spec-init has been connected to
• Determined that no spec is needed, and presented the reason and the next implementation policy
• Explicitly stated that unresolved boundaries, terms, or decisions remain and that user judgment is needed before proceeding to Kiro