letspecifide
The desktop IDE for spec-driven development with coding agents
Your spec outlives your prompt
Run several agents in parallel, each with its own identity, worktree and live session — all anchored to one specification that stays in place after the branch is merged.
macOS · Windows · Linux — one small native binary
Parallel agent threads
Several threads at once, each with a persistent identity and its own history.
One change, one worktree
Dedicated git worktrees. Your main clone never switches branch.
Your spec, or Spec Kit's
A declarative project-model.yaml, or the specs/ tree you already have.
Bring your own agent
Agent-agnostic and read-only on git. Nothing rewrites your history.
Placeholder — replace with a screenshot of the IDE running several threads.
Why letspecifide
The reasoning survives
The specification ships with the feature and stays to govern how it changes. The next session starts from what you decided, not from an empty prompt.
Work runs in parallel
Threads carry their own identity, worktree, file tree and tabs. You switch between problems, not between chat windows.
Your repository stays yours
letspecifide reads git and never rewrites it. Branch conventions are fixed, work stays isolated, nothing is checked out over the top of something else.
Governed by a project model
Goals, capabilities, domains, workflows, policies, quality gates, risks and decisions live in one declarative file that both you and the agent read.
Two modes, on purpose
Analysis mode produces specification and merges it behind the approvals you set. Development mode writes none — it implements and closes tasks.
Native, not a browser tab
A small desktop binary for macOS, Windows and Linux. Built on Tauri.
Spec-driven, whichever way you practise it
Teams sit at different points depending on the codebase. letspecifide runs all three — it just doesn't leave you at the first one.
The spec starts the work: write it, plan it, break it into tasks, hand it to the agent. This is where most Spec Kit projects live, and letspecifide reads them as they are.
The spec is the program; code is regenerated output. A strong bet on greenfield, supported for the domains where you want to make it.
The spec doesn't stop at hand-off. It stays to govern how the feature changes. You keep writing code. What you stop doing is losing the reasoning.
Early builds are going out to a small group
If you run agents against a real codebase and the losing-the-reasoning part sounds familiar, write and say what you're working on.