132 lines
4.7 KiB
Markdown
132 lines
4.7 KiB
Markdown
---
|
|
name: analyze-prd
|
|
description: "Extract architectural requirements from a PRD, identify relevant knowledge domains, and flag ambiguities before architecture design. This is the Architect pipeline's second step, comparable to brainstorming in the PM pipeline."
|
|
---
|
|
|
|
This skill will be invoked after architecture research is complete or when the architect needs to extract architectural requirements from a PRD before starting design.
|
|
|
|
**Announce at start:** "I'm using the analyze-prd skill to extract architectural requirements from the PRD."
|
|
|
|
## Purpose
|
|
|
|
Read the PRD and extract the architectural dimensions that must be addressed during design. Identify which knowledge domains are relevant, flag ambiguities that block architectural decisions, and produce a structured analysis that feeds into `design-architecture`.
|
|
|
|
## Hard Gate
|
|
|
|
Do NOT start designing architecture in this skill. This skill only extracts and organizes requirements. Design happens in `design-architecture`.
|
|
|
|
## Process
|
|
|
|
You MUST complete these steps in order:
|
|
|
|
1. **Read the PRD** at `docs/prd/{feature}.md` end-to-end
|
|
2. **Read optional research brief** at `docs/research/{date}-{topic}-architecture.md` if it exists
|
|
3. **Extract functional requirements** - List each functional requirement and its architectural implications
|
|
4. **Extract non-functional requirements** - List each NFR and its architectural implications
|
|
5. **Identify relevant knowledge domains** - Determine which of the 9 knowledge domains are relevant:
|
|
- System Decomposition
|
|
- API & Contract Design
|
|
- Data Modeling
|
|
- Distributed System Basics
|
|
- Architecture Patterns
|
|
- Storage Knowledge
|
|
- Async & Queue Design
|
|
- Error Model Design
|
|
- Idempotency Design
|
|
6. **Flag ambiguities** - Identify any PRD requirements that are unclear for architectural purposes
|
|
7. **Map requirements to architecture sections** - Show which PRD requirements map to which architecture output sections
|
|
8. **Write analysis document** - Save to `docs/architecture/{date}-{feature}-analysis.md`
|
|
|
|
## Analysis Output Format
|
|
|
|
Save the analysis document to `docs/architecture/{date}-{feature}-analysis.md`.
|
|
|
|
```markdown
|
|
## PRD Source
|
|
|
|
Reference to the PRD file being analyzed.
|
|
|
|
## Functional Requirements Extraction
|
|
|
|
For each functional requirement in the PRD:
|
|
|
|
| # | Requirement | Architectural Implications | Relevant Domains |
|
|
|---|-------------|---------------------------|-----------------|
|
|
| FR-1 | ... | ... | system-decomposition, api-contract-design |
|
|
|
|
## Non-Functional Requirements Extraction
|
|
|
|
For each NFR in the PRD:
|
|
|
|
| # | Requirement | Architectural Implications | Relevant Domains |
|
|
|---|-------------|---------------------------|-----------------|
|
|
| NFR-1 | ... | ... | storage-knowledge, async-queue-design |
|
|
|
|
## Knowledge Domain Relevance
|
|
|
|
For each of the 9 knowledge domains, state whether it is relevant and why:
|
|
|
|
| Domain | Relevant? | Reason |
|
|
|--------|-----------|--------|
|
|
| System Decomposition | Yes/No | ... |
|
|
| API & Contract Design | Yes/No | ... |
|
|
| Data Modeling | Yes/No | ... |
|
|
| Distributed System Basics | Yes/No | ... |
|
|
| Architecture Patterns | Yes/No | ... |
|
|
| Storage Knowledge | Yes/No | ... |
|
|
| Async & Queue Design | Yes/No | ... |
|
|
| Error Model Design | Yes/No | ... |
|
|
| Idempotency Design | Yes/No | ... |
|
|
|
|
## Requirement-to-Section Mapping
|
|
|
|
| Architecture Section | PRD Requirements Served |
|
|
|---------------------|------------------------|
|
|
| System Overview | ... |
|
|
| Frontend Architecture | ... |
|
|
| Backend Architecture | ... |
|
|
| API Definitions | ... |
|
|
| DB Schema | ... |
|
|
| Service Boundaries | ... |
|
|
| Async Model | ... |
|
|
| Error Model | ... |
|
|
| Idempotency Design | ... |
|
|
|
|
## Ambiguities And Gaps
|
|
|
|
List any PRD requirements that are unclear for architectural purposes and need PM clarification before design can proceed. If none, write "None identified."
|
|
|
|
## Research Brief Integration
|
|
|
|
If a research brief exists, summarize key findings that inform this analysis. If no research brief exists, write "No architecture research brief available."
|
|
```
|
|
|
|
## Primary Inputs
|
|
|
|
- `docs/prd/{feature}.md` (required)
|
|
- `docs/research/{date}-{topic}-architecture.md` (optional)
|
|
|
|
## Primary Output
|
|
|
|
- `docs/architecture/{date}-{feature}-analysis.md`
|
|
|
|
## Transition
|
|
|
|
After completing this analysis, invoke `design-architecture` with the PRD and analysis document as inputs.
|
|
|
|
## Guardrails
|
|
|
|
This is a pure analysis skill.
|
|
|
|
Do:
|
|
- Extract architectural implications from PRD requirements
|
|
- Identify relevant knowledge domains
|
|
- Flag ambiguities that block design decisions
|
|
- Map requirements to architecture output sections
|
|
|
|
Do not:
|
|
- Design architecture
|
|
- Make technology selections
|
|
- Define API contracts, schemas, or service boundaries
|
|
- Write architecture decisions
|
|
- Produce any architecture output sections |