302 lines
8.6 KiB
Markdown
302 lines
8.6 KiB
Markdown
# Clarify Design
|
|
Clarifies technical design and architecture based on requirements.
|
|
|
|
## Initial Setup
|
|
Respond with:
|
|
```
|
|
I'm ready to help clarify the technical design.
|
|
|
|
I'll read your requirements from spec/requirements.md to understand what needs to be built.
|
|
|
|
Please describe your tech stack and design preferences.
|
|
```
|
|
|
|
Wait for user input.
|
|
|
|
## Workflow
|
|
1. **Read** `spec/requirements.md` FULLY
|
|
2. **Receive user's tech preferences**
|
|
3. **Ask clarifying questions** (3-5 at a time) about:
|
|
- Specific technologies and versions
|
|
- Architecture patterns and structure
|
|
- Data storage and management
|
|
- UI/interface approach
|
|
- Integration points and dependencies
|
|
- Testing approach and preferences
|
|
4. **Continue asking** until no more questions remain
|
|
5. **Generate design document** at `spec/design.md`
|
|
|
|
## Guidelines
|
|
- Each bullet with a clarifying question should be numbered
|
|
- Be specific: name actual technologies with versions, not placeholders
|
|
- Align with requirements: every design decision should trace back to requirements
|
|
- If user doesn't mention UI approach and requirements need one, ask or suggest
|
|
- If user has no testing preferences, create appropriate strategy based on tech stack
|
|
- Include concrete file/folder structures
|
|
- Match complexity to project scope - don't over-engineer
|
|
- Design for both happy path and error cases
|
|
|
|
## Chat Output Format
|
|
After completing design:
|
|
```
|
|
I've created a design document at spec/design.md.
|
|
|
|
The design includes:
|
|
- Complete tech stack with rationale
|
|
- Component breakdown with responsibilities
|
|
- Data model and UI structure
|
|
- Key user flows and interactions
|
|
- File structure and development approach
|
|
|
|
Please review and let me know if you'd like any adjustments.
|
|
```
|
|
|
|
## File Output Format
|
|
Create `spec/design.md`:
|
|
|
|
```markdown
|
|
# Design: [Project Name]
|
|
|
|
## Design Overview
|
|
[2-3 sentences describing the technical approach and key architectural decisions]
|
|
|
|
## Tech Stack
|
|
|
|
### Languages & Frameworks
|
|
- **Language**: [e.g., JavaScript/TypeScript]
|
|
- **Framework**: [e.g., React 18]
|
|
- **Build Tool**: [e.g., Vite]
|
|
- **Styling**: [e.g., Tailwind CSS]
|
|
|
|
### Data & State
|
|
- **Data Storage**: [e.g., localStorage, PostgreSQL, MongoDB]
|
|
- **State Management**: [e.g., React Context, Redux, Zustand]
|
|
- **Data Format**: [e.g., JSON, structured data model]
|
|
|
|
### Dependencies
|
|
- [Library 1]: [Purpose]
|
|
- [Library 2]: [Purpose]
|
|
|
|
**Rationale**: [Why this tech stack? How does it fit the requirements?]
|
|
|
|
## System Architecture
|
|
|
|
### High-Level Architecture
|
|
```
|
|
[Diagram or description of system layers]
|
|
|
|
Example:
|
|
┌─────────────────────────────┐
|
|
│ Presentation Layer │ ← UI Components
|
|
├─────────────────────────────┤
|
|
│ Business Logic Layer │ ← State Management
|
|
├─────────────────────────────┤
|
|
│ Data Layer │ ← Storage/API
|
|
└─────────────────────────────┘
|
|
```
|
|
|
|
### Component Breakdown
|
|
|
|
#### Component: [Name]
|
|
**Purpose**: [What this component does]
|
|
**Location**: `src/components/ComponentName.tsx`
|
|
**Responsibilities**:
|
|
- [Responsibility 1]
|
|
- [Responsibility 2]
|
|
|
|
**Props/Interface**:
|
|
```typescript
|
|
interface ComponentProps {
|
|
prop1: string;
|
|
prop2: number;
|
|
onAction: () => void;
|
|
}
|
|
```
|
|
|
|
**State**:
|
|
- [State item 1]: [Purpose]
|
|
- [State item 2]: [Purpose]
|
|
|
|
## Data Model
|
|
|
|
### Entity: [EntityName]
|
|
```typescript
|
|
interface EntityName {
|
|
id: string;
|
|
field1: string;
|
|
field2: number;
|
|
field3: Date;
|
|
}
|
|
```
|
|
|
|
**Purpose**: [What this represents]
|
|
**Relationships**: [How it relates to other entities]
|
|
|
|
## User Interface Design
|
|
|
|
### Screen: [ScreenName]
|
|
**Purpose**: [What user accomplishes here]
|
|
**Layout**:
|
|
```
|
|
┌─────────────────────────┐
|
|
│ Header │
|
|
├─────────────────────────┤
|
|
│ Main Content │
|
|
│ - Element 1 │
|
|
│ - Element 2 │
|
|
├─────────────────────────┤
|
|
│ Footer/Actions │
|
|
└─────────────────────────┘
|
|
```
|
|
|
|
**Key Elements**:
|
|
- [Element 1]: [Purpose and behavior]
|
|
- [Element 2]: [Purpose and behavior]
|
|
|
|
**User Interactions**:
|
|
- [Action 1] → [Result]
|
|
- [Action 2] → [Result]
|
|
|
|
## Key Interactions & Flows
|
|
|
|
### Flow: [FlowName]
|
|
**Scenario**: [User story this implements]
|
|
|
|
1. User [action]
|
|
2. System [response]
|
|
3. System [next step]
|
|
4. User sees [result]
|
|
|
|
**Error Handling**:
|
|
- If [error condition] → [behavior]
|
|
- If [error condition] → [behavior]
|
|
|
|
## File Structure
|
|
```
|
|
project-root/
|
|
├── src/
|
|
│ ├── components/
|
|
│ │ ├── ComponentA.tsx
|
|
│ │ └── ComponentB.tsx
|
|
│ ├── hooks/
|
|
│ │ └── useCustomHook.ts
|
|
│ ├── utils/
|
|
│ │ └── helpers.ts
|
|
│ ├── types/
|
|
│ │ └── index.ts
|
|
│ ├── App.tsx
|
|
│ └── main.tsx
|
|
├── spec/
|
|
│ ├── requirements.md
|
|
│ └── design.md
|
|
├── package.json
|
|
└── README.md
|
|
```
|
|
|
|
## Design Decisions & Tradeoffs
|
|
|
|
### Decision: [DecisionName]
|
|
**Choice**: [What we decided]
|
|
**Alternatives Considered**: [What else we could do]
|
|
**Rationale**: [Why we chose this]
|
|
**Tradeoffs**: [What we gain/lose]
|
|
|
|
## Non-Functional Considerations
|
|
|
|
### Performance
|
|
- [Performance approach, e.g., "Lazy load components"]
|
|
- [Optimization strategy, e.g., "Memoize expensive calculations"]
|
|
|
|
### Scalability
|
|
- [How design handles growth]
|
|
- [What needs to change if requirements scale]
|
|
|
|
### Accessibility
|
|
- [Accessibility approach, e.g., "ARIA labels on all interactive elements"]
|
|
- [Keyboard navigation strategy]
|
|
|
|
### Error Handling
|
|
- [Error handling strategy]
|
|
- [User feedback approach]
|
|
|
|
## Testing Strategy
|
|
|
|
**Philosophy**: Every task must be verified before moving to the next. Testing is incremental and continuous.
|
|
|
|
### Testing Tools & Framework
|
|
- **Testing Framework**: [e.g., Jest, pytest, Vitest, etc.]
|
|
- **Testing Library**: [e.g., React Testing Library, unittest, etc.]
|
|
- **Test Runner Command**: `[e.g., npm test, pytest, etc.]`
|
|
- **Coverage Tool** (if applicable): [e.g., Jest coverage, coverage.py]
|
|
|
|
### Verification Approach for Each Task Type
|
|
|
|
#### Code/Logic Tasks
|
|
- **Verification Method**: Automated tests
|
|
- **When to Test**: [After each task / TDD / as you go]
|
|
- **What to Test**:
|
|
- Function behavior with valid inputs
|
|
- Edge cases and error handling
|
|
- Integration with other components
|
|
|
|
#### UI/Component Tasks
|
|
- **Verification Method**: [Automated tests + manual verification / manual only]
|
|
- **Automated Tests**: Component rendering, props, interactions
|
|
- **Manual Verification**: Visual appearance, responsiveness, UX flow
|
|
|
|
#### Configuration/Setup Tasks
|
|
- **Verification Method**: [e.g., "Run build command", "Run dev server"]
|
|
- **Success Criteria**: No errors, expected output
|
|
|
|
### Test Writing Approach
|
|
[Describe when tests should be written:]
|
|
- **Test-Driven Development (TDD)**: Write tests before implementation
|
|
- **Test-After**: Implement feature, then write tests
|
|
- **Incremental**: Write tests as you implement
|
|
|
|
### Critical Testing Rules
|
|
1. Every task must have clear verification steps
|
|
2. Tests must pass before moving to next task
|
|
3. If tests fail repeatedly (3+ times), stop and reassess
|
|
4. Document any tasks that cannot be automated (manual verification)
|
|
|
|
### Unit Tests
|
|
- **What**: Test individual components/functions in isolation
|
|
- **Where**: `src/__tests__/` or alongside source files
|
|
- **Key areas**: [List critical functions to test]
|
|
- **Run Command**: `[command to run unit tests]`
|
|
|
|
### Integration Tests
|
|
- **What**: Test component interactions and data flow
|
|
- **Key flows**: [List important user flows to test]
|
|
- **Run Command**: `[command to run integration tests]`
|
|
|
|
### Manual Testing Scenarios
|
|
- **What**: UI/UX verification that requires human judgment
|
|
- **Key scenarios**: [List scenarios to manually verify]
|
|
- **When**: After completing each phase with UI changes
|
|
|
|
## Development Approach
|
|
|
|
### Phase Breakdown
|
|
[High-level phases - detailed breakdown happens in plan.md]
|
|
1. **Phase 1**: [e.g., "Setup & Core Structure"]
|
|
2. **Phase 2**: [e.g., "Data Layer"]
|
|
3. **Phase 3**: [e.g., "UI Components"]
|
|
4. **Phase 4**: [e.g., "Integration & Polish"]
|
|
|
|
### Development Standards
|
|
- [Coding conventions]
|
|
- [Naming conventions]
|
|
- [Documentation requirements]
|
|
|
|
## Open Questions
|
|
[Any remaining technical uncertainties - resolve before planning]
|
|
- [Question 1]
|
|
- [Question 2]
|
|
|
|
## References
|
|
- Requirements: `spec/requirements.md`
|
|
- [Any relevant documentation or resources]
|
|
```
|