Transform PRD (Product Requirements Document) into actionable engineering specifications. Creates detailed technical specs that developers can implement step-by-step without ambiguity. Covers data modeling, API design, business logic, security architecture, deployment, and agent system design. Use when: converting product requirements to technical specs, validating PRD completeness, planning technical implementation, creating task breakdowns, or defining test specifications. Triggers: 'PRD to spec', 'convert requirements', 'technical spec from PRD', 'engineering doc from requirements', 'validate PRD'.
Transform PRD (Product Requirements Document) into actionable engineering specifications. Creates detailed technical specs that developers can implement step-by-step without ambiguity. Covers data modeling, API design, business logic, security architecture, deployment, and agent system design. Use when: converting product requirements to technical specs, validating PRD completeness, planning technical implementation, creating task breakdowns, or defining test specifications. Triggers: 'PRD to spec', 'convert requirements', 'technical spec from PRD', 'engineering doc from requirements', 'validate PRD'.
license
MIT
version
0.1.2
compatibility
Requires bash for validation scripts. No external dependencies.
Transform product requirements into engineering specifications so complete that developers can implement the entire system step-by-step without ambiguity, and the resulting system can be replicated or migrated without information loss.
Goal: Break PRD into structured, implementable requirements.
User Story Format
## US-001: [Title]**Priority:** P0/P1/P2
As a [role], I want [action], so that [benefit].
**Acceptance Criteria:** (Given/When/Then)
**Business Rules:** BR-001, BR-002
**Dependencies:** US-002
Requirements Matrix
ID
Requirement
Source
Type
Priority
FR-001
[description]
US-001
CRUD/Logic
P0
NFR-001
API response <200ms P95
PRD §7
Performance
P0
Phase 2: Technical Design (Interactive)
Goal: Make architectural decisions with explicit user confirmation.
Decision Process
For each significant decision:
Present 2-3 options with pros, cons, effort, risk, and operational cost
Recommend with rationale
Wait for user confirmation
Record in Decision Log
Decision Log
ID
Decision
Options
Chosen
Rationale
Trade-offs
Date
D-001
Database
PG, Mongo
PostgreSQL
ACID, JSON support
Higher ops complexity
[date]
Tech Stack
Component
Choice
Version
Rationale
Alternatives
Language
Framework
Database
Cache
Queue
Infra
Phase 3: Detailed Specification
Goal: Specs detailed enough for implementation without questions. Apply Engineering Lenses to every component.
Per entity: purpose, all fields (type, nullable, default, constraints, description), indexes with rationale, relationships with cascade rules, validation rules, lifecycle (create/update/delete behavior).
3.2 API Specification
Per endpoint: method + path, auth/authz, request (params, body, validation rules), response (structure, all status codes with conditions), business logic steps, side effects, rate limits, idempotency.
3.3 Business Logic
Per complex rule: interface (inputs/outputs/errors), algorithm in pseudocode, decision table for branching, concrete edge case examples, transaction boundaries, rollback behavior.
