Inspiration

As a student exploring AI agents, I kept running into the same friction: most AI coding tools push you into pure “vibe coding.” You describe something, the agent writes code, and consistency slowly falls apart as the project grows.

Kiro’s spec-driven development approach immediately stood out. Instead of jumping straight into code, it forces you to first define clear requirements, design decisions, and tasks. I wanted to make this workflow even smoother and more accessible — especially for students and solo developers who want the benefits of structured agentic development without heavy process overhead.

That’s how SpecForge was born: a lightweight tool that turns natural-language ideas into complete, ready-to-use Kiro specs.

What it does

SpecForge helps users go from a rough idea to a structured Kiro-compatible specification:

Generates a clear requirements.md with user stories and acceptance criteria
Creates a design.md with architecture notes and key technical decisions
Produces a tasks.md broken into actionable implementation steps

The goal is to give people a clean, reviewable foundation that Kiro agents can then implement more reliably, while still keeping the process lightweight.

How I built it

I built SpecForge primarily with Kiro IDE, deliberately using the same features I wanted the tool to support:

Used Specs to plan and iterate on SpecForge itself
Wrote steering files to keep the agent aligned with project conventions
Added hooks for automatic documentation updates and light validation
Experimented with MCP to bring in external context when needed
Kept the .kiro/ folder as the single source of truth throughout development

The tech stack is intentionally simple so the focus stays on the workflow rather than complex infrastructure.

Challenges I faced

Balancing structure and flexibility
Making the generated specs structured enough to be useful, but not so rigid that they feel heavy or limit creativity.
Keeping the agent consistent
Without good steering and clear task breakdowns, the agent would sometimes drift. Learning how to write effective steering files and task lists was a big part of the process.
Meta development
Building a tool that helps create specs while using specs to build the tool itself was both useful and occasionally confusing. It forced me to stay disciplined about process.
Scope control
It was tempting to add too many features early. I had to repeatedly cut scope so the core experience (idea → clean Kiro spec) stayed strong.

What I learned

Spec-driven development really does improve consistency when working with agents
Good steering files and clear task breakdowns matter more than I initially expected
Starting with structure doesn’t have to feel slow — it can actually speed up the later stages
Building with the same tool you’re designing for creates useful feedback loops

What’s next

I plan to improve the quality of generated specs, add better support for iterating on existing specs, and explore tighter integration with Kiro’s agent workflows. The long-term goal is to make structured agentic development feel as natural as vibe coding, while keeping the reliability benefits.