How to Apply Spec Driven Development With Claude Code

Spec driven development is the practice of turning a high-level product requirements document into per-feature specifications that an AI coding agent can follow reliably. This guide walks through the full workflow demonstrated by Gustavo Dev Doido: building context layers, generating a PRD, writing specs with a reusable skill, and judging whether a spec is actually good.

What Is Spec Driven Development?

Spec driven development is a workflow where you write detailed, verifiable specifications for each feature before an AI coding agent writes any code. The core idea, as presented by Gustavo Dev Doido on the Full Cycle channel, is that an LLM is an inference engine: it does not know what you want to build unless you tell it, layer by layer.

The workflow rests on two principles. First, deterministic gates: fixed processes that the agent must follow the same way every time. Second, context: everything the model needs to make the decisions you would have made. A spec is the artifact that carries both.

This matters whether you are starting a greenfield project or working inside an existing legacy codebase. The first step is always the same: understand which technologies you will use, because that knowledge becomes part of the context you assemble for the model.

In the demonstration, the stack for an authentication feature included Argon2 (sometimes written "Argon 2") for password hashing and Prisma with PostgreSQL as the ORM. Argon2 is a credible pick: it won the Password Hashing Competition in 2015 and has been the recommended default for password hashing since. Note the level of detail: the spec names the library choices but stops short of prescribing implementation, such as class names or method signatures.

Why Context Beats Inference in AI Coding

An LLM produces a generic result when it lacks context, because it can only fill the gaps with its own defaults. The video gives a concrete example: you ask for a login, the agent implements one, and it redirects nowhere useful after success, because you never said that a successful login should redirect to the dashboard. The model did what it thought was good. The failure was missing context, not missing intelligence.

The practical consequence is that context must be built deliberately, in layers. The demonstration assembles several layers before any code exists:

• The PRD, a high-level document with an executive summary, the problem, the audience, success metrics, and user stories for features such as a landing page, authentication, video upload, a video library, tags, and background processing.
• Visual context, such as design tokens and how they should be used, so the interface follows the intended visual system.
• Feature specs, one per feature, generated from the PRD in a specification format.

None of these layers prescribe implementation. They constrain what the agent should want to build. When the context is sufficient, the agent is being steered toward your intent instead of filling the gaps with its own defaults.

This is the mindset behind methodologies the video name-checks, including BDD-style specification practices and SDD (spec driven development). The tool matters less than the method: the presenter notes you could use Codex or any agent. The point is feeding context, and Claude Code, Anthropic agentic coding tool that runs in the terminal, is simply the vehicle used in the demo.

From PRD to Feature Spec: The Workflow

The workflow moves from the general to the specific in three stages: PRD, feature selection, and spec generation. Each stage narrows the context the agent receives, so by the time a spec exists it describes one feature in enough detail to build.

Stage 1: Write the PRD

The PRD (Product Requirements Document) describes what you want to develop at the highest possible level, deliberately avoiding technical detail. It contains an executive summary, the problem statement, the audience, success metrics, and user stories covering every feature the product requires. Once it exists, the model knows what the product is; it still knows nothing about how any piece should work.

Stage 2: Pick one feature

From the PRD you select a single feature, for example authentication, and ask the agent to generate a specification for that feature specifically. This granularization is what keeps each spec focused and reviewable.

Stage 3: Generate the spec with a skill

The generation step uses a reusable skill called spec writer. A skill is a capability packaged as an artifact: a prompt file that the agent loads and follows. The spec writer skill reads the PRD plus any existing project documentation, then produces a structured specification document. In the demo it also splits the output into two files, a spec and an implementation plan, wrapped by a single organizing contract, and proposes the next step.

The resulting authentication spec contains a technical overview, expectations for the feature, affected components at the architecture level, technical decisions (Argon2 for hashing, Prisma with Postgres for the ORM), components to create with descriptions, API contracts per endpoint, migration notes, and a testing strategy. It is technical but still high level: it describes what is wanted, not how to code it.

Where BMED and Harners Engineering Fit

BMED and Harners Engineering are two of the named approaches the presenter groups under the same umbrella: methodologies that feed an LLM structured context instead of hoping inference fills the gaps. The transcript credits Harners Engineering design as the frame for deciding which context layers to assemble, from project documentation to visual design tokens, before any code is written.

This is not a solo idea. GitHub's spec-kit brought spec driven development to a wider audience in September 2025, when Microsoft's developer blog documented its sequential slash commands for creating a spec and then the technical plan. The Claude Code demo follows the same logic with homegrown tooling, which points to the real lesson: the methodology is portable, the artifacts are yours to define.

Inside the Spec Writer Skill: Six Execution Steps

The spec writer skill executes in six ordered steps, which is what makes it deterministic rather than a single hopeful prompt. The numbered sequence from the video:

1. Validate the inputs from the user, confirming the feature description is usable.
2. Run an interview, asking the user questions until the feature's intent is genuinely understood, for example how the authentication flow should start.
3. Summarize everything gathered during the interview so the user can confirm it.
4. Generate the specification document from the confirmed summary.
5. Validate the spec against the required criteria before finishing.
6. Write the output file.

In practice, when invoked in Claude Code, the skill loads, reads the PRD and the existing project documentation, and then writes the spec file while the developer watches. Because the steps are fixed, the same skill reproduces the same quality of specification every time, which is exactly what a deterministic gate is for.

The presenter notes that skills like this exist scattered across the internet, but teams will eventually need to write their own to encode their own standards. Students of the Crazystack Typescript program at Crazystack, including the Bootcamp do Dev Doido, receive a ready-made spec writer skill as part of the material.

Seven Qualities That Separate a Good Spec From a Bad One

To write your own spec generation skill, you first need a standard for what a good spec contains. The video organizes this into a checklist of seven qualities, each with a test you can apply to any line of your specification:

1. Falsifiability. Every statement must be verifiable against the real output. "The system must be performatic" is vague. "P99 latency under 200 ms at 1,000 requests per second" is testable.
2. Behavior, not process. The spec says what is true, not how to implement it. Say "apply a discount proportionally to a value", never "create class X with method apply".
3. Invariants. Name the rules that always hold: the final price is never negative; distributed credits never exceed the original credit in a transaction.
4. Edge cases, named. Empty values, negatives, limits, concurrent access. If a case is deliberately not handled, a mature spec explicitly says so.
5. Boundaries. State what is out of scope. A coupon spec might handle only BRL and exclude foreign currencies (the transcript writes this as "BLR", meaning the Brazilian real), and refunds may be an entirely separate flow.
6. Inputs and restrictions. Define how data is expected to arrive and under which constraints.
7. Business decisions. Record the decisions the business has already made, so the agent does not re-decide them.

The spec template shown in the video mirrors this checklist: technical overview, inputs, architecture, cases, infrastructure, integration points, scope exclusions, and acceptance or verification criteria. A spec that fails falsifiability is the single most common failure; the fix is almost always replacing an adjective with a number and a condition.

FAQ

What is spec driven development in one sentence?

It is the practice of writing verifiable, per-feature specifications before an AI coding agent writes code, so the agent builds what you specified instead of what it inferred.

Do you need Claude Code to use this workflow?

No. The video states the tool is not the point; any capable coding agent works, and the presenter mentions Codex as an alternative. Claude Code is simply the terminal agent used in the demonstration.

What goes into the PRD versus the spec?

The PRD stays high level: problem, audience, success metrics, and user stories. The spec is per feature and adds technical overview, affected components, technical decisions, API contracts, migrations, scope exclusions, and testing strategy.

Why is falsifiability the most important spec quality?

Because a statement that cannot be checked against the output cannot be validated. Replacing "performatic" with "P99 latency under 200 ms at 1,000 requests per second" makes the requirement testable.

What is the spec writer skill?

It is a prompt artifact that encodes a six-step process: validate inputs, interview the user, summarize, generate the spec, validate the spec, and write the output file. Encapsulating the process is what makes spec generation repeatable.

Where does the spec writer skill come from?

The presenter built his own skill to encode the six-step process and shares it with students of the Crazystack Typescript program. The video's advice is that most teams will eventually need to write their own skill reflecting their own standards.

What are BMED and SDD?

They are methodologies for feeding structured context to an AI coding agent, mentioned in the video alongside BDD-style practices. They share the same principle: the model needs explicit, layered context rather than open-ended inference.

What technologies appeared in the demo's authentication spec?

Argon2 for password hashing, and Prisma with PostgreSQL as the ORM. The spec names these decisions but leaves implementation details like class and method names to the developer.

Does this work on legacy codebases?

Yes. The presenter applies the same first step regardless of project age: understand the technologies in play, then assemble the PRD and context layers around them. Existing project documentation becomes part of the context the skill reads.

Turn Your Own Video Walkthroughs Into Articles

A sixteen-minute video like this one holds a complete, structured workflow: context layers, a six-step skill, and a seven-point spec checklist. That knowledge is hard to search, quote, or revisit inside a video timeline, which is the same problem specs solve for code: unstructured input produces unstructured output.

If you have your own explanations, interviews, or lessons sitting on YouTube, the same fix applies to them. Skala Blog turns your videos into written articles: paste the YouTube URL, get the transcription, and generate a structured, publishable article.

Skala Blog

Source video