G GDD Playbook
Gate-Driven Development (GDD)

Build with AI.
Stay in control.

Describe what you want to build in plain words. GDD walks the AI through five steps, and you approve each one before it moves to the next. You stay in charge; the AI does the work.

Get the playbook Read the concept article

The simple loop

Same three moves. Repeat until you're happy.

Each step runs the same short loop: you say what you want, the AI does the work and shows what it did, you check it and ask questions or make changes. When you're happy, you approve. Only then does the next step start.

Loop
The back-and-forth between you and the AI within a single step. It repeats until you're happy with what you see.
Gate
A short checklist at the end of each step. Nothing moves forward until every item on it is done and you approve.
You

Start with the problem

Describe what you want to build in a simple prompt.

AI

Clarifies and does the work

Asks questions, drafts, prototypes, builds, and tests.

You

Ask, push back, decide

Ask questions, point out problems, ask for changes. Then approve, or send it back for another try.

Repeat until you approve. Next step starts.
Why I made GDD

A working playbook, built from practice.

AI coding without guardrails hits the same walls: lost context, scope drift, untested fixes, silent bugs. GDD is the process I use to keep those under control, refined project by project.

Vibe Coding

Fast iteration without explicit controls
  • Unclear requirements - vague prompts produce superficially correct solutions that miss the real need.
  • Scope drift - iterative prompting adds features and changes behavior without preserving agreed boundaries.
  • Lost context - the AI forgets earlier decisions, constraints, and architecture as the project grows.
  • Invented logic - code may run while silently producing wrong results.
  • Weak tests - generated tests may omit edge cases or confirm the AI's own wrong assumptions.

Gate-Driven Development

Fast iteration with clear human checkpoints
  • Clear requirements - define the problem, users, constraints, and non-goals before building.
  • Controlled scope - gates lock decisions and require explicit approval before boundaries change.
  • Durable context - specs, decisions, status, and the next step live in project files, not chat memory.
  • Verified behavior - acceptance criteria and evidence prove the result matches the intent.
  • Real testing - edge cases and real flows, and a failing test can never be weakened to pass.
Process

A guided path from idea to production.

Each phase is its own loop - you and the AI iterate until the work is proven. The gate is the human checkpoint: work moves forward only when the named outcome has evidence.

01

Spec · frame the problem

Turn your idea into a short written plan: what the app does, who uses it, what stays out. One or two pages, no design yet.

✓ Gate 1 · Spec locked
02

Prototype · prove the flow

Clickable screens running on fake data. Try every flow before anything real is built; changing your mind here costs minutes, not weeks.

✓ Gate 2 · Prototype locked
03

Design · plan what sits behind the screens

Turn every behavior into a testable checklist. Decide the data, rules, security, and tech stack. Still no real code.

✓ Gate 3 · Design locked
04

Build · write real code with proof

The AI builds one small step at a time, each with its own passing test. You read the report: every checklist item done with proof, or openly deferred.

✓ Gate 4 · Build complete
05

Deploy · verify and launch

Same checks on your machine, then staging, then live. The AI launches, re-verifies the live app, and shows the evidence.

✓ Gate 5 · Ship
∞

Change · after launch

Every new request re-enters at the right step: new feature → spec; screen tweak → prototype; behavior change → design; bug → build with a test. Launch is a checkpoint, not the end.

How to set up

Set up GDD in your project.

Download the playbook once, keep it in one central folder, and connect each project with the instruction file for your coding agent.

  1. Download the playbook. One ZIP with everything: the main phase files, the support files (UX, test data), the plug-in templates, and the two project instruction templates. CLAUDE.md for Claude Code, AGENTS.md for Codex.
    Download ZIP ↓ Browse online
  2. Create one central playbook folder. Unzip the files there. Projects reference this folder, so copies do not drift.
  3. Read README.md. Follow its one-time setup and choose the template for your coding agent.
  4. Connect your project. Add CLAUDE.md or AGENTS.md at the project root and replace the playbook-folder placeholder with your real path.
  5. Describe the problem. Start with the outcome you want. Let the AI clarify the spec one decision at a time.