Claude Prompt for Spec-Driven & TDD with AI
Produce a Gherkin BDD scenarios for a two-factor authentication via TOTP before any code is written, with acceptance criteria Claude/Cursor can turn into tests.
More prompts for Spec-Driven & TDD with AI.
Produce a Gherkin BDD scenarios for a file uploads with virus scanning before any code is written, with acceptance criteria Claude/Cursor can turn into tests.
Produce a product requirements doc (PRD) for a background job retry with dead-letter queue before any code is written, with acceptance criteria Claude/Cursor can turn into tests.
Generate executable Gherkin scenarios for role-based access control on admin panel, mapped to step definitions in Jest.
Produce a API contract spec with example payloads for a server-side pagination with cursor before any code is written, with acceptance criteria Claude/Cursor can turn into tests.
Drive a permission checker in Java through a strict TDD loop with Zed Assistant: write failing test, make it pass, refactor.
Drive a time-window aggregator in PHP through a strict TDD loop with JetBrains AI Assistant: write failing test, make it pass, refactor.
You are a product engineering strategist with a track record of helping product engineers achieve ship a new feature correctly the first time.
Write a complete **Gherkin BDD scenarios** for a new feature: **two-factor authentication via TOTP** in a VS Code extension. No code yet -- only the spec. The spec must be detailed enough that an AI coding assistant could implement it without asking follow-up questions.
**Feature:** two-factor authentication via TOTP
**Format:** Gherkin BDD scenarios
**Project:** VS Code extension
**Team:** 10-person product team
**Test framework that will verify this:** Cypress
## Why spec-first
Vibe coding without a spec produces code the AI cannot verify. A tight spec turns into a tight test suite, and the test suite becomes the contract the AI must satisfy. "Red until green" is only meaningful if "green" is defined.
## Required spec sections
### 1. Problem statement (3-5 sentences)
- Who is affected
- What they cannot do today
- The cost of not fixing it
- Scope boundary (what this feature is NOT)
### 2. User story / JTBD
Format per Gherkin BDD scenarios:
- User story: "As a <role>, I want <action>, so that <outcome>."
- JTBD: "When <situation>, I want to <motivation>, so I can <outcome>."
- RFC: problem, proposal, alternatives, risks
### 3. Acceptance criteria
Write 6-10 criteria in Given/When/Then form. Each criterion must:
- Be testable (deterministic, binary outcome)
- Name concrete inputs and expected outputs
- Cover at least one edge case (empty input, boundary, auth failure)
- Avoid implementation details ("click the blue button" -> no; "submit the form" -> yes)
### 4. Out of scope
- 3-5 things explicitly not included in this feature
- What a future iteration might tackle
### 5. Data model deltas
- New entities / columns / indexes
- Migration safety (reversible? online?)
- Seed / fixture data needed for tests
### 6. API contract (if applicable)
- New endpoints with method, path, request shape, response shape, error codes
- Auth requirements
- Rate limits
### 7. Observability
- Events to log with structured fields
- Metrics to emit (counter / gauge / histogram)
- Alerts on which thresholds
### 8. Test plan
- Unit tests (count + areas)
- Integration tests (which flows)
- E2E tests (which user journeys)
- Fixtures / mocks needed
- How to run a single AC: "Cypress --filter=<name>"
### 9. Rollout
- Feature flag name
- Kill switch
- Progressive rollout plan (% of users)
- Success metrics and deadline for deciding rollback
### 10. Definition of done
A checklist the PR author can tick off. 8-12 items, each a verifiable condition.
## Output
Produce the full spec. Length: whatever is required to pass the above checklist -- typically 300-600 lines. No marketing language. Imperative, precise, checkable.
Organize your output using a clear framework with labeled sections. Each section should build on the previous one.