• A

  /prd

  has been generated and you need to bridge the gap to implementation
• You want architecture decisions documented before coding starts
• Multiple developers/agents will implement the feature and need a shared contract
• You need to validate technical feasibility before committing to a PRD
• You want to catch design issues early — before code is written

1. Locate PRD — find or receive the PRD document
2. Analyze context (optional) — if a codebase exists, scan it to understand current architecture, patterns, and constraints
3. Ask clarifying questions — resolve technical ambiguities (max 3-5 questions)
4. Generate SPEC — produce a structured technical specification
5. Review — present to user for feedback and iteration
6. Save — write final SPEC to agreed location

• Existing architecture — how the current system is structured
• Tech stack — languages, frameworks, libraries already in use
• Patterns — naming conventions, file organization, error handling approach
• Database — current schema, migration tool, ORM
• API style — REST/GraphQL/gRPC, authentication method, response format
• Testing — test framework, coverage patterns, test utilities

• Architecture choices — where does this feature live? New service or extend existing?
• Data storage — new table? Extend existing? Cache strategy?
• API design — new endpoints? Extend existing? Breaking changes?
• Dependencies — any new libraries needed? Version constraints?
• Performance — expected load? Latency requirements? Batch size limits?

Technical questions before I generate the SPEC:

1. Where should the priority logic live?
   A. Extend existing TaskService
   B. New PriorityService
   C. Inline in controller
   D. Let me decide based on the codebase

2. Database migration approach?
   A. Add column to existing tasks table
   B. New priority table with FK
   C. JSON field on tasks
   D. Let me decide based on current schema

3. API versioning concern?
   A. Add to existing v1 endpoints
   B. New v2 endpoints
   C. No versioning needed

Technical specification derived from: [PRD filename/link] Generated: [date] | Target branch: [branch] | Commit: [short-hash]

• Source: [path or URL to PRD]
• User Stories covered: [US-001, US-002, ...]
• Functional Requirements covered: [FR-1, FR-2, ...]

• [Questions that need product/engineering input before implementation]

• [Technical assumptions made during SPEC creation — validate before implementing]

---

• Every PRD User Story has corresponding SPEC sections
• Every Functional Requirement maps to an API endpoint or business logic rule
• Every Acceptance Criterion maps to at least one test case
• Architecture choices are justified with rationale
• API schemas are specific enough to generate client code
• Error handling covers all identified failure modes
• Implementation order respects dependencies
• No "TBD" or "TODO" items — resolve or move to Open Questions

• Don't restate the PRD. The SPEC adds technical depth, not a copy of requirements in different words.
• Don't over-specify trivial operations. CRUD with no special logic doesn't need a full algorithm section.
• Don't pick technologies without context. Always check what the project already uses before suggesting new tools.
• Don't design in isolation. The SPEC must fit the existing system — same patterns, same conventions, same style.
• Don't leave decisions implicit. If you made a choice (e.g., "add column to existing table"), state it and say why.
• Don't write implementation code. The SPEC describes contracts and behavior, not code. Pseudocode is acceptable for complex algorithms.

/prd  →  /prd-to-spec  →  /goal  →  /review-it  →  /ship-it
 │              │              │
 │  Requirements │  Technical   │  Implementation
 │  (what)       │  (how)       │  (code)

• /prd produces the PRD (input to this skill)
• /prd-to-spec produces the SPEC (this skill)
• /goal implements Issues with SPEC as the technical reference
• /code-to-spec reverse-engineers SPEC from existing code (complementary — forward vs. reverse)