Generate an Engineering Specification. Use when the user says /eng-spec, asks to create a technical spec, engineering spec, system design document, or translate a PRD into a technical plan. Triggers: eng-spec, engineering spec, technical spec, system design, technical design, architecture spec.
Generate a detailed engineering specification that translates product requirements into a concrete technical plan. The spec gives engineers a clear blueprint for implementation, covering architecture, data models, APIs, and operational concerns.
Produce a markdown document with the following sections:
A brief description of what the system or feature does and how it fits into the broader architecture. Include a high-level diagram description if helpful.
List key technical decisions using the format:
Define the core entities, their fields, types, and relationships. Use table format:
| Field | Type | Required | Description |
|---|
Include notes on indexing, constraints, and migration from existing schemas.
For each endpoint or interface, specify:
Define the error strategy:
Outline the testing approach:
If this changes existing systems:
Address authentication, authorization, data encryption, input validation, and any compliance requirements.
List unresolved technical questions and identified risks with proposed mitigations.
Input: "We need an eng spec for the PDF export feature described in the PRD. Our stack is Node.js, PostgreSQL, and AWS."
Output: A full engineering spec covering the architecture (async job queue with S3 storage for generated PDFs), data models (ExportJob, ExportTemplate tables), API contracts (POST /exports to trigger, GET /exports/:id to poll status, GET /exports/:id/download for retrieval), error handling (retry failed renders up to 3 times, notify user on permanent failure), testing strategy (unit tests for template rendering, integration tests for the job pipeline, load tests for concurrent generation), and migration plan (new tables, no schema changes to existing).