grill-to-kiro

Refines ambiguous feature requests into structured handoffs for Kiro spec workflows.

Updated Jun 23, 2026
One-click install
npx skills add https://github.com/j5ik2o/marp-ai-base --skill grill-to-kiro-j5ik2o
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: grill-to-kiro
Source: https://github.com/j5ik2o/marp-ai-base/tree/main/.agents/skills/grill-to-kiro
Command: npx skills add https://github.com/j5ik2o/marp-ai-base --skill grill-to-kiro-j5ik2o

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Passing vague feature ideas directly into Kiro's spec-driven development workflow locks ambiguity into requirements, design, and tasks. This Skill clarifies domain terminology, design decisions, and spec boundaries before anything reaches kiro-discovery or kiro-spec-init. ## Core Features & Use Cases - Pre-spec clarification: Runs grill-with-docs questioning to pin down the problem, current state, desired outcome, and scope boundaries before spec creation. - Context persistence: Records confirmed domain terms in CONTEXT.md and irreversible or trade-off decisions as ADRs under docs/adr/. - Structured Kiro handoff: Produces a standardized handoff document (Problem, Current State, Scope, Boundaries, Domain Context Updates, Kiro Route) instead of forwarding raw user requests. - Use Case: A user says "I want to add a notification feature." The Skill grills the request, updates CONTEXT.md with new terms, drafts an ADR for the delivery-channel decision, then routes a clean handoff to kiro-spec-init. ## Quick Start Ask the assistant to grill this feature idea and prepare it for a Kiro spec before creating any requirements.

Frequently Asked Questions about grill-to-kiro

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I prepare a vague feature idea for Kiro spec-driven development?

Run a grilling pass that clarifies the problem, current state, desired outcome, and scope boundaries before invoking kiro-discovery or kiro-spec-init. Record confirmed terms in CONTEXT.md and significant decisions as ADRs, then hand off a structured summary.

When should I use kiro-discovery versus kiro-spec-init?

Use kiro-discovery when boundaries are still exploratory or the work may decompose into multiple scopes. Use kiro-spec-init when a single spec's boundary and feature name are already clear, optionally with an existing brief.md.

When should I skip the grilling step before creating a Kiro spec?

Skip it when checking an existing spec's status, continuing approved requirements, design, tasks, or implementation, making trivial fixes, or when the user explicitly instructs to proceed directly to Kiro.

What belongs in CONTEXT.md versus an ADR?

CONTEXT.md acts as a glossary holding canonical domain terms, avoided terms, and invariants—never tasks or spec content. ADRs under docs/adr/ capture only irreversible, non-obvious, or trade-off-laden design decisions.

Why not pass the user's original request directly to kiro-spec-init?

Raw requests carry ambiguity that Kiro freezes into requirements, design, and tasks. A structured handoff with explicit scope, boundaries, and domain context prevents that ambiguity from being baked into the spec.