Kiro uses spec-driven development. But where does the spec come from?

Kiro just shipped and the core idea is compelling: your AI coding tool works from a spec, not just a prompt. Define requirements, design decisions, and tasks upfront — Kiro implements against them.

But there's a gap nobody's talking about yet.

Writing a good spec is hard. Most developers don't have a structured way to go from "I want to build X" to a complete .kiro/specs/ folder with requirements, design decisions, and tasks per feature. They either skip the spec entirely, or spend hours writing it manually — which defeats part of the point.

This is the problem I've been working on with FLOWiGANTT.

The workflow

1. Describe your project in plain language
2. FLOWiGANTT evaluates the idea, asks clarifying questions, generates architecture and PRD with full reasoning captured
3. Export directly as a Kiro SDD bundle — .kiro/specs/ with requirements.md, design.md, and tasks.md per feature, plus steering files (product.md, tech.md, structure.md)

What the output actually looks like

I ran it on a GDScript static analysis tool — a desktop app for Godot developers that generates type hints and detects unused variables, without modifying files until the user approves each change.

Input: one paragraph.

Output: 12 feature specs with EARS-format requirements, component design, and implementation tasks — ready to drop into a repo and open in Kiro.

The architecture correctly chose Rust + Tauri, identified the right crates (notify, rusqlite, clap), and generated GDScript-specific analysis tasks rather than generic web app boilerplate.

You can browse the full plan here — architecture, PRD, tasks, and the Kiro SDD bundle are all available and downloadable:

👉 https://flowigantt.com/shared/D_dbkTteg34EzJkcbU3QKgjQUvHln_qg

Why the steering files matter

Kiro's product.md, tech.md, and structure.md give the AI persistent project context across sessions. When those come from a reasoned planning process rather than being written from scratch, the quality difference in what Kiro produces is significant.

The steering files aren't just documentation — they're the memory layer that keeps Kiro oriented to your actual architecture decisions across every session.

The open question

Curious whether others are thinking about the spec generation problem — or just writing .kiro/specs/ by hand. What's your current workflow for going from idea to spec?