Menú
AID Phase 2 - Technical Specification. Use for system architecture, API contracts, data models, security architecture, transitioning from PRD to implementation.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
AID Phase 4 - Development phase. Use for implementing features, TDD practices, code reviews, transitioning from planning to QA.
AID Phase 0 - Research & discovery. Use for validating problem spaces, identifying stakeholders, defining success metrics, deciding whether to proceed.
AID Phase 3 - Implementation Planning with consolidation-first approach. Resolves contradictions between PRD and Tech Spec, creates consolidated master document, then breaks down into actionable tasks and populates Jira. Includes sprint planning and risk assessment.
AID Phase 1 - PRD creation. Use for user stories, acceptance criteria, scoping features, transitioning from discovery to tech spec.
AID Phase 5 - QA and Release. Use for validating implementations, acceptance tests, preparing releases, deployment, operational readiness.
Expert-level Atomic Design System development from Figma style guides. Build reusable component libraries with atoms, molecules, organisms, templates, and pages.
Basado en la clasificación ocupacional SOC
| name | aid-tech-spec |
| description | AID Phase 2 - Technical Specification. Use for system architecture, API contracts, data models, security architecture, transitioning from PRD to implementation. |
Purpose: Design technical solution. Create blueprint developers can follow without ambiguity.
Entry: PRD approved, requirements clear, dependencies identified Exit: Tech spec complete, architecture documented, API contracts defined, data models specified
| Pitfall | Fix |
|---|---|
| Over-engineering | Design for current needs |
| Missing error handling | Define errors upfront |
| Tight coupling | Design for testability |
| Ignoring non-functionals | Address performance, security |
| Unclear contracts | APIs unambiguous with examples |
# [Feature] Technical Specification
## 1. Overview
### Problem Summary
### Proposed Solution
### Key Decisions
| Decision | Choice | Rationale |
## 2. Architecture
### System Diagram
[Mermaid or image]
### Component Breakdown
| Component | Responsibility | Dependencies |
### Data Flow
## 3. API Design
### POST /api/[resource]
**Request:**
```json
{ "field": "type" }
Response (200):
{ "id": "string" }
Errors: | Code | Error | Description |
| Field | Type | Constraints | Description |
| Scenario | Response | Recovery |
| Requirement | Target | Measurement |
| Risk | Impact | Mitigation |
## Role Guidance
| Role | Focus |
|------|-------|
| PM | Validate approach addresses requirements |
| Dev | Own spec, design for testability |
| QA | Review testability, integration points |
| Tech Lead | Review architecture, approve direction |
## Handoff to Implementation
- Approved tech spec
- API contracts
- Data models
- Architecture decisions with rationale
- Spike/POC results (if any)
Save to: `docs/tech-spec/YYYY-MM-DD-[feature].md`