The latest articles on DEV Community by sourabh Shukla (@sourabh_shukla_06bcf7007c). https://dev.to/sourabh_shukla_06bcf7007c https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F3961627%2F25b5a2a8-919e-42dd-8d8c-2f89a6247cd1.jpg https://dev.to/sourabh_shukla_06bcf7007c en sourabh Shukla Mon, 01 Jun 2026 07:31:41 +0000 https://dev.to/sourabh_shukla_06bcf7007c/kiro-uses-spec-driven-development-but-where-does-the-spec-come-from-5b4j https://dev.to/sourabh_shukla_06bcf7007c/kiro-uses-spec-driven-development-but-where-does-the-spec-come-from-5b4j <p>Kiro just shipped and the core idea is compelling: your AI coding tool works from a <em>spec</em>, not just a prompt. Define requirements, design decisions, and tasks upfront — Kiro implements against them.</p> <p>But there's a gap nobody's talking about yet.</p> <p><strong>Writing a good spec is hard.</strong> Most developers don't have a structured way to go from "I want to build X" to a complete <code>.kiro/specs/</code> 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.</p> <p>This is the problem I've been working on with <a href="https://flowigantt.com" rel="noopener noreferrer">FLOWiGANTT</a>.</p> <h2> The workflow </h2> <ol> <li>Describe your project in plain language</li> <li>FLOWiGANTT evaluates the idea, asks clarifying questions, generates architecture and PRD with full reasoning captured</li> <li>Export directly as a Kiro SDD bundle — <code>.kiro/specs/</code> with <code>requirements.md</code>, <code>design.md</code>, and <code>tasks.md</code> per feature, plus steering files (<code>product.md</code>, <code>tech.md</code>, <code>structure.md</code>)</li> </ol> <h2> What the output actually looks like </h2> <p>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.</p> <p><strong>Input:</strong> one paragraph.</p> <p><strong>Output:</strong> 12 feature specs with EARS-format requirements, component design, and implementation tasks — ready to drop into a repo and open in Kiro.</p> <p>The architecture correctly chose Rust + Tauri, identified the right crates (<code>notify</code>, <code>rusqlite</code>, <code>clap</code>), and generated GDScript-specific analysis tasks rather than generic web app boilerplate.</p> <p>You can browse the full plan here — architecture, PRD, tasks, and the Kiro SDD bundle are all available and downloadable:</p> <p>👉 <a href="https://flowigantt.com/shared/D_dbkTteg34EzJkcbU3QKgjQUvHln_qg" rel="noopener noreferrer">https://flowigantt.com/shared/D_dbkTteg34EzJkcbU3QKgjQUvHln_qg</a></p> <h2> Why the steering files matter </h2> <p>Kiro's <code>product.md</code>, <code>tech.md</code>, and <code>structure.md</code> 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.</p> <p>The steering files aren't just documentation — they're the memory layer that keeps Kiro oriented to your actual architecture decisions across every session.</p> <h2> The open question </h2> <p>Curious whether others are thinking about the spec generation problem — or just writing <code>.kiro/specs/</code> by hand. What's your current workflow for going from idea to spec?</p> kiro ai programming devtool