Spec-Driven Development Starter Pack

Turn a meeting transcript or vague request into a spec that a person can review and an AI agent can execute. Then validate the requirement against a clickable prototype before engineering starts.

Use the prompts

AudienceBA, PM, PdM, marketers, and delivery teams

FormatSelf-guided workflow with three prompts

PrerequisitesNo coding or AI background required

The core idea

The spec is the control surface

Do not ask an AI agent to build from a messy request. First turn the request into a reviewable specification. Code and prototypes are downstream.

01Raw inputTranscript, ticket, notes, and source evidence.

02SpecificationRequirements, rules, constraints, acceptance criteria, and gaps.

03PrototypeA clickable result that exposes misunderstandings while change is still cheap.

04HandoffApproved spec, decision log, open questions, and QA checks.

What changes for the team

Your requirements can now become executable input. Ambiguity that used to surface in development or UAT can show up on screen in minutes.

Acceptance criteria can be tested against a prototype before engineering starts.
Out-of-scope decisions matter because the agent will otherwise fill gaps with plausible guesses.
The same spec aligns the BA, developers, QA, stakeholders, and the AI agent.

What does not change

AI output is still your output if you decide to use it. The model can draft, but the team must verify.

Check the spec against the original transcript or ticket.
Check the prototype against the spec.
Check tests against acceptance criteria.
Update the spec whenever the decision changes.

Ready to paste

Three prompts for your next backlog item

Start with one safe item. Remove client secrets and production credentials. Review the spec before any build step.

Prompt 01

Turn messy notes into a spec

Use this when the source is a transcript, a ticket, or a page of meeting notes.

Here are my raw notes from a discovery call. Do not write code.

Turn them into a specification: business need, functional requirements, business rules, quality attributes, constraints, acceptance criteria, out of scope.

Then list every decision this conversation did not actually make. Quote the line that hides each one and give me the options. Ask me what you cannot answer.

Human check

Every claim traces back to the source.
Unknown owners and dates stay unknown.
Options discussed are not recorded as decisions.
Out of scope is explicit.

Prompt 02

Count the ambiguity

Use this before review or handoff to find requirements that can be implemented in more than one reasonable way.

For the spec above, list every requirement that could reasonably be implemented in more than one way.

For each one: give me the two readings, explain what could go wrong, and propose wording that removes the ambiguity.

Human check

The proposed wording reflects a real decision.
Acceptance criteria are observable.
Business rules and quality attributes are separated.
The spec does not silently widen scope.

Prompt 03

Red-team before you send

Use this as an adversarial review before a stakeholder or engineering handoff.

Review this spec as three separate skeptics:

1. A delivery manager who has been burned by vague acceptance criteria.
2. A senior engineer who has to build it.
3. The customer paying for it.

Quote the exact line, say what breaks, propose replacement wording, and rank each finding by the cost of finding it late.

Human check

Findings quote the exact risky text.
Severity is tied to a concrete consequence.
Replacement wording preserves the intended scope.
A person accepts or rejects every proposed change.

Monday move

Do not ask AI to build yet

Take one messy request from your backlog. Ask the model to list the decisions the request did not actually make. That number is the ambiguity you were about to hand to someone else.

Every time the model, stakeholder, or developer finds a missing decision, update the spec first. Do not let the chat become the source of truth.

Want this workshop for your team?

Contact Andrew