create-prd-engineering

name	create-prd-engineering
description	Write a detailed PRD for engineering teams covering functional requirements, technical constraints, data models, API contracts, edge cases, acceptance criteria per story, release stages, and cross-functional tracking. Use when the engineering team needs a comprehensive build spec.

Create PRD (Engineering)

Generate a detailed Product Requirements Document for engineering teams. This is the engineering team's build spec -- it goes deeper than a standard PRD on functional requirements, technical constraints, data models, API contracts, edge cases, and acceptance criteria. Designed to be the document engineers pull stories from and reference during implementation.

When to Use

• You are writing requirements that engineering will break into stories and build from
• The feature involves data model changes, API contracts, or cross-service integration that need to be specified up front
• You need acceptance criteria per story so QA and engineering agree on "done"
• You want to track release stages (Alpha, Beta, GA) with entrance criteria

When NOT to Use

• You need a cross-functional overview for mixed audiences -- use create-prd (standard)
• You are handing this to an AI coding agent to build -- use create-prd-claude-code
• You need a concise one-pager for leadership -- use create-prd-one-pager
• The feature is still in early discovery and requirements are not stable enough for this level of detail

Inputs

Ask the user for:

1. Feature name -- What are we building?
2. Problem statement -- What problem does this solve? Include user impact and business impact.
3. Goals and success metrics -- What does success look like? Include baselines if available.
4. Functional requirements -- What must the system do? Be specific about behaviors, not just capabilities.
5. Technical context -- What systems, services, or data stores are involved? Any known constraints?
6. Design references -- Wireframes, mockups, or design specs (if available)
7. Dependencies -- Other teams, services, or features this depends on
8. Release plan -- What stages (Alpha, Beta, GA) and what are the criteria to advance?

If the user provides a design doc or markdown spec, read it for context.

Outputs

A comprehensive engineering PRD in markdown, following the template in references/template.md. The document includes:

• Metadata and stakeholders
• Problem statement with user and business impact
• Goals, non-goals, and success metrics with baselines
• Functional requirements organized by area
• Technical constraints and architecture notes
• Data model changes
• API contracts
• Edge cases and error handling
• User stories with acceptance criteria
• Release stage plan with entrance criteria
• Cross-functional tracking (design, docs, support, analytics)
• Risks and open questions

Steps

1. Gather context -- Ask for the inputs above. If a design doc or markdown spec exists, read it.
2. Write the problem statement -- Cover both user pain and business impact. Engineers build better when they understand why something matters.
3. Define functional requirements -- Organize by feature area. Each requirement should describe a behavior: "When X happens, the system does Y." Avoid vague requirements like "the system should be fast."
4. Document technical constraints -- Performance targets, backwards compatibility, security requirements, rate limits, data retention policies. Be specific.
5. Specify data model changes -- New tables, modified schemas, indexes, foreign keys. If migrations are needed, note them.
6. Write API contracts -- Endpoints, methods, request/response schemas, error codes. Include enough detail that a developer can implement without guessing.
7. Map edge cases -- What happens when input is invalid? When a dependency is down? When rate limits are hit? When the user has no data? Cover the unhappy paths.
8. Write user stories with acceptance criteria -- Each story should be independently deliverable. Acceptance criteria use Given/When/Then format and cover both happy and unhappy paths.
9. Plan release stages -- Map the work to Alpha, Beta, and GA with clear entrance criteria for each stage.
10. Track cross-functional needs -- Does design need to deliver mocks? Does documentation need updating? Does support need runbooks? Track each dependency.
11. Review with the user -- Walk through the spec. Key question for engineering review: "Can you break this into sprint stories and start building?"

Example Usage

User: "I need an engineering PRD for adding webhook support to our platform. Teams should be able to register webhook URLs and receive event notifications."

Agent: Asks about the event system architecture, expected event types, delivery guarantees, retry logic, and auth model. Produces a full engineering PRD with data model for webhook registrations, API contracts for CRUD + delivery, edge cases for failed deliveries, and acceptance criteria.

User: "Write an engineering PRD for migrating from REST to GraphQL for our dashboard API. Here's the design doc: docs/graphql-migration.md."

Agent: Reads the design doc, maps the existing REST endpoints, and produces a PRD with the GraphQL schema, migration plan per endpoint, backwards compatibility approach, and release stages.

Guardrails

• Requirements are behaviors, not wishes. "The system should be performant" is not a requirement. "P95 latency for the search endpoint must be under 200ms for queries returning fewer than 100 results" is.
• Every story needs acceptance criteria. If you cannot write Given/When/Then for a story, the story is not defined.
• Edge cases are not optional. The unhappy paths are where most bugs live. Cover invalid input, missing data, service failures, and concurrency.
• Do not design the architecture. Describe constraints and requirements. Let engineering design the solution. If you have opinions, put them in a "Suggested Approach" section clearly marked as non-binding.
• Track cross-functional dependencies explicitly. A PRD that assumes design will deliver mocks "when they are ready" without a tracked commitment is a PRD that will slip.
• Mark unknowns. Use [TBD -- owner: Name, target: Date] so unknowns are visible and trackable.

Related Skills

• create-prd -- Standard PRD for cross-functional audiences
• create-prd-claude-code -- PRD optimized for AI coding agents
• create-prd-one-pager -- Leadership one-pager
• create-architecture-diagram -- Visualize the system architecture
• decision-brief -- When a technical decision needs stakeholder approval