Back/Product/Cursor/Claude
IntermediateProduct

How to Use Spec Kit and AI to Write Robust Feature Specifications

Use Spec Kit as a questioning partner for a substantial feature: write the first specification, answer the ambiguities it finds, and turn those decisions into requirements and acceptance criteria an implementation team can use.

How to Use Spec Kit and AI to Write Robust Feature Specifications

Marco shows a feature specification in Spec Kit and explains how its questions surface missing decisions, such as limits on the amount of feedback a user may submit.

Before you start

What you need

  • A specific user problem and evidence that it matters
  • The feature scope and explicit non-goals
  • Known users, roles, permissions, and data involved
  • Product, technical, legal, and operational constraints
  • A repository where the specification can be versioned

What you’ll make

A versioned feature specification whose open decisions, edge cases, requirements, and acceptance criteria are explicit enough to guide implementation.

Tools used

Step by step

The workflow

Follow the sequence once, then adapt the prompts, checks, and handoffs to your own setup.

4 steps

Step01

Begin Writing Your Specification in Spec Kit

Start the Spec Kit feature flow with the user problem, supporting evidence, target users, scope, non-goals, constraints, and known decisions. Keep guesses out of the facts section.

Example prompt
Create a feature specification for [feature]. Problem: [evidence-backed problem]. Users and roles: [users]. In scope: [scope]. Non-goals: [non-goals]. Constraints: [constraints]. Known decisions: [decisions]. Label assumptions and open questions instead of inventing answers.
Step02

Let the AI Analyze Your Requirements

Have Spec Kit analyze the draft for ambiguity. Ask it to cover limits, permissions, error and recovery behavior, accessibility, data handling, latency, and conflicts with existing product behavior.

Example prompt
Analyze this specification for missing decisions and edge cases. Group questions by user behavior, limits, permissions, data, failure recovery, accessibility, performance, and compatibility. Cite the requirement that triggered each question. Do not answer product or policy questions for us.
Step03

Address AI-Generated Clarifying Questions

Answer the questions one by one. Record the chosen behavior, rationale, owner, and unresolved follow-up. If the answer needs research or another team, leave it open with a next action.

Example prompt
Apply these decisions to the specification: [decisions]. Add a short decision log with rationale and owner. Keep these items open: [open questions]. Do not convert an assumption into a requirement.
Step04

Refine and Complete Your Specification

Ask Spec Kit to reconcile the document. Remove contradictions and duplicates, convert decisions into testable requirements, and check that every acceptance criterion has a clear trigger and observable result.

Example prompt
Reconcile the full specification. Flag contradictions and duplicate requirements. For each accepted behavior, write observable acceptance criteria with preconditions, action, result, and relevant error state. Preserve the decision log and unresolved questions.

This process uses AI to augment and improve human-led engineering processes, rather than just generating code from scratch. It's ideal for complex, serious features where clarity is critical.

What good looks like

  • Each requirement traces to the stated problem, a constraint, or a documented decision.
  • Open questions remain labeled instead of being silently filled with model assumptions.
  • Limits, permissions, failure behavior, accessibility, and data handling are covered where relevant.
  • Acceptance criteria describe observable behavior rather than implementation slogans.

Build your next product with ChatPRD

Turn an idea into a PRD, user stories, and a plan.

Try ChatPRD free

After the steps

Runbook notes

How to recover when the loop fails and where human judgment helps.

Recover

If it goes sideways

The specification grows into adjacent features and infrastructure
Restate the user problem, list non-goals, and move future ideas into a separate section instead of adding them to the current build.
The model answers a product or policy question on the team's behalf
Mark the item as an open question, name the decision owner, and record the answer only after that owner makes the decision.
Requirements use words such as fast, intuitive, or robust without a testable meaning
Replace each adjective with a measurable limit, an observable behavior, or an explicit example.
The implementation changes but the specification remains a historical snapshot
Link the spec to the feature branch or epic and update the decision log when the team learns something that changes expected behavior.

Start shipping
better products.

Join 100,000+ product managers who use ChatPRD to write better docs, align teams faster, and build products users love.

Free to start
No credit card
SOC 2 certified
Enterprise ready