Draft a spec from rough input
Start with the PRD-to-spec workflow, then use the spec template examples to turn product language into engineering sections your team can review.
Open the drafting pathSpec Guides
Question-focused pages built for real delivery work. Start with a short playbook, then jump into templates and implementation details without switching mental context.
8 guidesFocused reads instead of long theory pages
Workflow-firstBuilt around drafting, review, testing, and rollout
Template-readyEach guide leads naturally into a reusable artifact
Choose the guide path for your task
Make acceptance criteria testable
Use concrete examples and the Given/When/Then template when QA needs criteria that name state, action, expected result, and edge cases.
Open the criteria pathReview before implementation
Run the spec review checklist with the edge-case checklist before code starts, especially when the change affects permissions, data, or rollout safety.
Open the review pathConstrain AI-generated code
Use the AI coding prompt template to bind generated changes to the spec, non-goals, acceptance criteria, and required test evidence.
Open the AI pathWhat you get from each guide
Every guide follows the same structure: a one-paragraph summary of why the topic matters, a short reusable example you can copy directly into your spec or ticket, and deeper sections covering edge cases, role-specific questions, and decision rules. The goal is a page you can open at the start of a sprint, scan in five minutes, and leave with a concrete artifact.
Guides are intentionally shorter than blog articles. Where a blog post explains the reasoning behind a practice in depth, a guide gives you the checklist or template first — with enough context to apply it without back-reading theory.
How to use these guides with your team
The most effective way to use these guides is to assign one per role before a spec review meeting. The PM reads the PRD-to-spec guide and scope non-goals checklist. The tech lead reads the edge case and API contract checklists. QA reads the acceptance criteria examples and spec review checklist. Each person arrives with specific questions rather than reviewing the same surface.
If you have less than 30 minutes before a review, start with the spec review checklist — it is the single fastest way to surface the gaps that cause the most rework: missing rollback steps, untestable acceptance criteria, and unconfirmed dependencies.
When specs need a guide vs when they need a template
Use a guide when you are trying to answer a question: "what should a good acceptance criterion look like?" or "which edge cases am I most likely to miss?" Use a template when you are ready to write: you know what you want to capture and need a structured format to fill in.
Most spec work starts with a guide — to calibrate what good looks like — then moves to a template to produce the actual artifact. The guides on this page link to their corresponding templates so you can move between the two without losing context.
Which guide to start with
If your team skips spec reviews or has frequent rework from misunderstood requirements: start with the Spec Review Checklist. It surfaces the most common gaps in the shortest time.
If your team writes specs but QA frequently finds issues at test time: start with Acceptance Criteria Examples — the pattern most teams get wrong is writing criteria that are technically true but not testable without interpretation.
If you use AI coding tools and find the output frequently drifts from requirements: start with the AI Coding Prompt Template.
How to combine guides in one review
Start with the highest-risk question
If the work changes external behavior, start with acceptance criteria. If it changes a service boundary, start with the API contract checklist. If the risk is rollout or data, start with edge cases and review gates.
Assign each guide to one role
PMs should challenge scope and non-goals, engineers should challenge contracts and rollout paths, and QA should challenge observability of outcomes. The guide is more useful when each role reads with a different responsibility.
End with one artifact
The review should produce an updated spec, checklist, or prompt. If the team reads three guides but no artifact changes, the review probably generated awareness rather than a decision.
Spec template examples for modern dev teams
Spec template examples you can copy for feature, API, and DB work. Learn a lightweight format that keeps requirements testable and AI-ready.
Read guideAPI contract checklist before you ship
Use this API contract checklist to catch breaking changes before release. Covers schema, errors, versioning, idempotency, and compatibility.
Read guideHow to convert a PRD into a testable spec
A practical PRD to spec workflow. Turn product requirements docs into testable engineering specs with acceptance criteria and edge cases.
Read guideAcceptance criteria examples you can reuse
Acceptance criteria examples for feature delivery. Learn clear Given/When/Then patterns that improve QA handoff and reduce rework.
Read guideGiven/When/Then template for specs
A Given When Then template for specs and test design. Copy a practical format for happy path, error path, and permissions.
Read guideEdge case checklist before coding
Use this edge case checklist to harden your specs before coding. Covers nulls, duplicates, limits, race conditions, and permissions.
Read guideSpec review checklist (before implementation)
A spec review checklist for engineers, PMs, and QA. Validate scope, acceptance criteria, dependencies, rollout, and rollback before coding.
Read guideAI coding prompt template that follows specs
A prompt template to make AI coding follow your spec. Constrain scope, protect contracts, and require test evidence before merge.
Read guide