Introducing spec-driven development — built for agent-driven projects

[kaanozhan]

We just shipped a workflow we think is the right shape for building software with AI agents: spec-driven development. It's optional, but if you're doing serious work with agents, we strongly recommend trying it.

The problem we kept hitting
For a single bug fix, that's fine. For a real project — multiple features over weeks, evolving constraints, contributors coming and going — it's a slow erosion. Your project's institutional memory leaks out one chat log at a time.

What we built

Frame now supports a structured spec → plan → tasks → implement workflow. Each spec lives in its own folder under .frame/specs//:

spec.md what we're building (Problem, Goal, Constraints, Success Criteria)
plan.md how (Architecture, Files, Dependencies, Sequencing)
tasks.md a flat list of discrete tasks
status.json phase + metadata

You describe what you want; the AI drafts the spec. Click /spec.plan and it produces an implementation plan. Click /spec.tasks and it breaks the plan into discrete tasks that auto-import into tasks.json with proper attribution. From there, ship them like any other task — your existing tools and habits keep working.

Why this matters

When you work this way, every decision becomes a durable artifact. Why this architecture? It's in the spec. What were the constraints? Plan, section two. What's left to ship? Tasks, with status.

That structure pays off twice:

• For the agent — every new session starts with full context. No more re-explaining what we're building, what we already tried, why we ruled X out.
• For you (and your team) — a glance at .frame/specs/ is the project's design history. Onboarding becomes "read these specs."

We think structured context is the right primitive for AI-native development. Not because it's mandatory, but because it's how you build things that survive past any individual conversation.

It's optional

Spec-driven dev is opt-in per project. The first time you open the Specs panel, Frame asks if you want to enable it. Existing tasks.json workflows stay
untouched; spec-derived tasks land in your same task list with a spec · slug chip so you can see where each one came from.

Try it

Open any project → click the Specs tab in the toolbar → hit Enable. Walk through one feature end-to-end and tell us what works, what doesn't.

Feedback welcome here or in issues. The implement loop and autopilot mode are coming next — your input shapes what they look like.