What SPDD is

Structured Prompt Driven Development (SPDD) is a specific, opinionated way of doing spec-driven development. Where the broad category leaves the shape of the spec and the placement of review up to you, SPDD commits to answers: a fixed set of structured artifacts, a fixed set of human gates, and standards that are applied automatically rather than remembered.

The name is literal. Instead of prompting an AI tool once and hoping, you move an idea through structured stages, each one drafted by AI and reviewed by a human before it advances. A misunderstanding costs less the earlier you catch it, so SPDD front-loads that catching into small, focused reviews rather than one overwhelming one at the end.

SPDD is published openly as openspdd, the open specification of the methodology. You can run SPDD with any stack, any AI provider, and any editor. REEZN is a platform built specifically to run it as a team, but the methodology does not belong to any one tool.

Principles

Quality is a process, not a prompt

A one-line prompt gives you slop. A structured, reviewed blueprint gives you quality. SPDD makes the structure mandatory so no plan skips what matters.

Gate at the cheap-to-change points

Reviews sit before expensive, hard-to-reverse work: before design, before code. The later a mistake is caught, the more it costs, so the gates go early.

Standards are objects, not memory

Norms and safeguards are first-class things injected into every generation, not conventions a reviewer has to remember to apply.

Memory compounds

Every approved plan teaches an organizational knowledge base, so later plans are drafted knowing what earlier ones established.

Humans sign off, agents draft

AI does the drafting at every stage. Nothing advances on the AI’s say-so alone; a human approves each gate.

The stages

SPDD runs an idea through the following stages. REEZN’s pipeline embodies them directly, and they are the concrete worked example of the general specify-review- implement-verify loop:

01Definition

The author captures the idea in plain language: goal, business value, scope in and out, constraints, and acceptance criteria as Given / When / Then. The richer this input, the sharper everything downstream.

02Structured analysis

AI drafts a structured analysis document from the definition: the domain concepts (existing and new), the strategic approach and the alternatives it rejected, and a risk and gap analysis with a coverage table for every acceptance criterion. It stays strategic, not yet an implementation.

03Review gate 1

A human confirms the analysis captured the right ask. This is the "did we understand it?" gate, best answered by whoever owns the requirements. Comments block approval until resolved.

04REASONS blueprint

Once analysis is approved, AI generates a REASONS canvas per service the feature touches: an implementation-ready blueprint grounded in that service’s real stack and the approved analysis.

05Review gate 2

A technical reviewer confirms each blueprint is the right way to build. This is the "how should we build it?" gate. Blueprints are approved per service, so a feature can be partially approved.

06Agent implementation

An agent implements the approved blueprint in the team’s repos, runs the service’s tests, and opens a pull request per service. The PR is reviewed like any other.

07Verification

Each PR carries an AI verification report checking the result against the acceptance criteria and safeguards, with structured verdicts. A safeguard violation blocks delivery unless an admin overrides it with a written justification.

08Sign-off

A human approves the verification report. Only then does the work count as delivered. Every step leaves a versioned, attributable record of who agreed to what.

The implementation, verification, and sign-off tail is where SPDD closes the loop from an approved spec all the way to a reviewed pull request. In REEZN it is a premium capability; the specify-and-review core runs on any plan.

The REASONS canvas

The blueprint stage uses a structured canvas whose sections spell the acronym REASONS. Each section answers a specific question, grounded in the approved analysis, so no two blueprints skip the same thing:

RRequirements

The core problem and value, distilled from the analysis to a few sentences, keeping the plan anchored to the ask.

EEntities

The domain model: the concepts, attributes, and relationships, rendered as a class diagram using the actual names from the analysis.

AApproach

The chosen solution direction and key design decisions, adapted to the service’s real technology stack rather than a generic framework.

SStructure

The architecture: which components exist and how they depend on one another, shaped to the service’s actual stack.

OOperations

The concrete, executable tasks. Each spells out what to build, why (which acceptance criterion it satisfies), how, and under what constraints.

NNorms

The organization’s standards applied to this feature, each relevant norm named and explained in terms of how it constrains this service.

SSafeguards

The hard limits stated concretely for this implementation, each safeguard named and its practical meaning spelled out.

A separate REASONS canvas is generated for every service a feature touches, so each plan speaks in terms of that service’s real stack and the right reviewer signs off on the part they own.

Norms, safeguards, and organizational memory

What makes SPDD governed rather than merely structured is that your standards are first-class objects, not reminders. Norms are the conventions and proven patterns your team follows; they guide. Safeguards are the hard limits that must never be crossed (privacy boundaries, usage caps, compliance rules); they constrain. Both are injected into every AI generation, scoped org-wide or per project, so each analysis and blueprint is built to your real rules rather than generic best practice. A safeguard violation caught at verification blocks delivery outright unless a human explicitly overrides it, on the record.

Alongside them, every approved plan, norm, and document teaches an organizational knowledge base that the AI consults while drafting. Context compounds instead of being re-explained: the fiftieth plan is written knowing what the first forty-nine established. Standards that once required slack headcount to maintain, written conventions, structured review, decision records, become nearly free when AI drafts and a human approves.

Why the gates go where they do

SPDD places its two core review gates deliberately, at the two cheapest points to change direction. The first gate, on the analysis, catches a misunderstood requirement while it is still a comment on a document. The second, on the blueprint, catches a wrong design before any code exists. Both sit before implementation, because a mistake caught on the page costs a sentence to fix and the same mistake caught in a shipped feature costs an incident.

Splitting "did we understand it?" from "how should we build it?" into two small reviews, rather than one large one, is what keeps each gate focused enough that reviewers actually do it. The verification sign-off then closes the loop at the far end: the spec that opened the work is the yardstick the finished work is checked against.

The line

The methodology is open and tool-agnostic: run SPDD with any stack, any provider, any editor. REEZN is the platform built to run it as a team, with the roles, gates, safeguards, and memory enforced by the server rather than by discipline.

SPDD: Structured Prompt Driven Development