From idea to built product.
Describe what you want once. gspec's autonomous build drives the whole chain — specs, plan, and code — as a deterministic run with quality gates that catch their own mistakes.
Hand it your idea
Pass your idea straight to the command, or let a short intake interview capture it and the essentials. Either way you answer up front — the run doesn’t stop to re-ask.
The pipeline runs
Nine stages execute in order, each an isolated agent gated by a validator. Foundation specs you already have are reused, not regenerated. Before any code is written, the run pauses once for you to review the specs — or skip it with --no-review.
A working product
Code that builds and passes its own tests, specs that match the code, and a record of what the run learned.
Two ways to run it
Kick off a build from inside your coding harness — the AI coding tool gspec is installed into — or run it headless as a script. Pass your idea directly as an argument — leave it off and the build opens with a short intake interview instead.
From your coding harness
Run the slash command in Claude Code, Codex, or Pi. Add your idea in quotes, or run it bare to be interviewed.
As a script
Run the build headless from your terminal or CI. The engine defaults to the platform you installed gspec for — override it with --engine, and use --resume to pick up a paused run or approve the spec review.
Nine stages, one command
The build walks the full gspec workflow deterministically — nine agent stages, plus a human review
gate between plan and implement (the
review card below). Greenfield or existing project — foundation stages
are skipped when the spec already exists, and an existing architecture is amended rather than rewritten,
so it meets your project where it is.
Foundation
profile Product identity & positioning
stack Technology & infrastructure
practices Standards & quality gates
style Design system
Specification
features Prioritized feature PRDs
architecture Data models, APIs, structure
plan Ordered, dependency-aware tasks
Implementation
review Human gate — you review the specs before any code
implement Write code against the plan
reconcile Sync specs back to reality
Prefer to drive it yourself? Every stage is also a standalone /gspec-* command.
The build just runs them in order, for you.
Autonomous, not unattended-and-hoping
Letting an agent run for a long time is easy. Letting it run and trusting the result is the hard part. gspec's build is built around gates and recovery, so a long run stays honest.
Isolated agent runs
Every stage runs as a fresh headless agent — clean context each time. Nothing accumulates and drifts; the filesystem (your gspec/ docs and code) is the only shared state.
Self-healing QA gates
Each producer is followed by a read-only validator (producer ≠ checker). The gate passes on severity: a spec fails only on a blocker or major finding, so a verdict carrying only minor/nit notes passes with those notes recorded rather than burning another revision — the loop has an exit it can reach. A real failure hands the work back for a surgical revision (not a rewrite): the writer is restricted to the edits the findings name, is told not to pad the document, and sees every verdict so far, so a repeat finding gets fixed differently instead of repeated. If the gate still fails, the run pauses rather than shipping something broken, keeping the full verdict in .gspec/build/last-failure.md — and every failing verdict, including recovered ones, is appended to a cumulative .gspec/build/qa-failures.md so you can tune the loop. On resume, a stage you left failed is re-validated (honoring any hand-edit), never skipped; specs that already passed are memoized and not re-checked; and each stage reports its elapsed time.
Deterministic verify.sh
The implementer generates a committed verify.sh that builds and tests every module in the project — each independently built and shipped unit, like an API, a web app, or a CLI. The driver runs it and reads the exit code — a real build+test gate, not a vibe check. Polyglot and multi-module aware.
Seeded from your library
Saved specs in ~/.gspec (stacks, styles, practices, feature PRDs) are templates the run can start from instead of a blank page. With nobody to ask, the build reports what it found and the writer adopts the single best fit — adapting it to this project, never copying it blindly — or writes fresh when none fits. Your product profile and architecture are always written from scratch: both are specific to one project.
Resumable runs
Progress is tracked in an on-disk run manifest. If a stage crashes, you stop it, or it pauses at the spec-review gate, the build resumes from where it left off instead of starting over.
It always says how it ended
A long run must never stop in silence. Each ending gets its own exit code — 0 complete, 1 failed a gate, 2 paused for spec review, 3 crashed — and its own record in .gspec/build/status.json. gspec build --status prints it in one line and exits with that code, so a script or a watching agent branches on a number instead of reading the log. A run killed mid-stage still leaves that record, and one whose process is simply gone is reported as crashed rather than as still working.
Continuation loop
For large scopes, the driver watches the unchecked-task count and spawns fresh implementer agents while progress keeps dropping — resilient even when a single context can’t hold the whole job.
Learnings report
Every run ends by recording what it learned — QA corrections and feedback that feed the learning loop, so the next build starts smarter.
Right-sized models
Every stage runs as its own agent, so you can assign each a model in .gspec/config.json (or ~/.gspec/config.json) — by exact agent name, by role tier (writer, qa, planner, implementer, …), or a default. Put the checkers and foundation specs on a cheaper model and keep the strong one for architecture and implementation, and a build costs a fraction of running everything on the top tier. With no config, every agent uses the engine default.
Where the build runs today
The autonomous build needs a harness whose engine can run headless — scripted from the terminal, no UI. Today that means Claude Code, Codex, and Pi. Every harness gets the full spec-authoring workflow; the build path is where they differ.
Point it at an idea and go.
Install gspec, then run /gspec-build in a supported harness.