323 lines
10 KiB
Markdown
323 lines
10 KiB
Markdown
---
|
|
allowed-tools: Read, Glob, Grep, Write, MultiEdit, TodoWrite
|
|
description: Generate comprehensive app design document with project stage assessment
|
|
---
|
|
|
|
# Generate Application Design Document
|
|
|
|
**User Request:** $ARGUMENTS
|
|
|
|
## Context
|
|
|
|
- Project root: !`pwd`
|
|
- Package.json: @package.json
|
|
- Existing design docs: !`ls -la .claude/rules/ 2>/dev/null || echo "No .claude/rules directory yet"`
|
|
|
|
## Goal
|
|
|
|
Create a comprehensive Application Design Document based on deep codebase analysis and user input. The document provides a high-level overview of the application's architecture, core features, user experience, and business logic while remaining technology-agnostic and focused on the "what" rather than the "how".
|
|
|
|
## Process
|
|
|
|
### 1. Initial Analysis
|
|
|
|
- Analyze project structure and existing codebase
|
|
- Review package.json for project name and dependencies
|
|
- Check for existing documentation in .claude/rules/
|
|
- Identify key application features and patterns
|
|
- **Think deeply** about the application's purpose and architecture
|
|
|
|
### 2. Codebase Deep Dive
|
|
|
|
**Think harder about the application's architecture and business logic.**
|
|
|
|
Analyze the codebase to understand:
|
|
|
|
- **Application Structure:** Main modules, features, and components
|
|
- **User Flows:** Authentication, navigation, key user journeys
|
|
- **Data Models:** Conceptual relationships and entities
|
|
- **Business Logic:** Core rules, workflows, and processes
|
|
- **Integrations:** External services and APIs
|
|
- **Security Patterns:** Authentication and authorization approaches
|
|
|
|
_Extended thinking helps identify non-obvious patterns, understand complex business rules from code, and make strategic decisions about what aspects are most important to document._
|
|
|
|
### 3. Interactive Q&A Session
|
|
|
|
**CRITICAL:** Ask project stage question FIRST, then 4-7 additional questions:
|
|
|
|
- Use lettered/numbered options for easy response
|
|
- Focus on business goals and user needs
|
|
- Gather context for proper documentation
|
|
|
|
### 4. Update Project Configuration
|
|
|
|
Based on project stage response:
|
|
|
|
- Update `.claude/rules/3-project-status.mdc` with current stage
|
|
- Set appropriate DO/DON'T priorities for the stage
|
|
- Document stage-specific development guidelines in the Cursor rule
|
|
|
|
### 5. Generate Document
|
|
|
|
Create comprehensive app design document following the standard structure
|
|
|
|
### 6. Save and Organize
|
|
|
|
- Create `.claude/rules/` directory if needed
|
|
- Save as `1-app-design-document.mdc`
|
|
- Suggest next steps (tech stack doc, PRD, etc.)
|
|
|
|
## Required Questions Template
|
|
|
|
### 🎯 CRITICAL: Project Stage Assessment (Ask First!)
|
|
|
|
**1. What stage is your application currently in?**
|
|
|
|
a) **Pre-MVP** - Building initial version, not deployed to production yet
|
|
b) **MVP** - Basic version deployed and live with early users
|
|
c) **Production** - Mature application with established user base
|
|
d) **Enterprise** - Large scale deployment, multiple teams involved
|
|
|
|
**2. Based on your selected stage, here are the development priorities:**
|
|
|
|
- **Pre-MVP Priorities:**
|
|
|
|
- ✅ DO: Core functionality, security basics, input validation, working features
|
|
- ❌ DON'T: Unit tests, performance optimization, accessibility polish, perfect code
|
|
- 🚀 Focus: Ship fast with security, iterate based on feedback
|
|
|
|
- **MVP Priorities:**
|
|
|
|
- ✅ DO: Critical path testing, basic monitoring, user feedback loops
|
|
- ❌ DON'T: Comprehensive test coverage, advanced patterns, premature optimization
|
|
- 🚀 Focus: Stability for early users, rapid iteration
|
|
|
|
- **Production Priorities:**
|
|
|
|
- ✅ DO: Testing, monitoring, performance, accessibility, documentation
|
|
- ❌ DON'T: Skip security reviews, ignore technical debt
|
|
- 🚀 Focus: Reliability, scalability, user experience
|
|
|
|
- **Enterprise Priorities:**
|
|
- ✅ DO: Comprehensive testing, security audits, team coordination, compliance
|
|
- ❌ DON'T: Skip documentation, ignore code standards
|
|
- 🚀 Focus: Team efficiency, maintainability, compliance
|
|
|
|
### 📋 Context-Specific Questions (Ask 4-7 based on analysis)
|
|
|
|
**3. Application Purpose & Users**
|
|
|
|
- What is the primary problem your application solves?
|
|
- Who are your target users and what are their main goals?
|
|
|
|
**4. Unique Value Proposition**
|
|
|
|
- What makes your application unique compared to existing solutions?
|
|
- What's your competitive advantage?
|
|
|
|
**5. User Roles & Permissions**
|
|
|
|
- What different types of users interact with your system?
|
|
- Examples: end users, admins, moderators, content creators, viewers
|
|
|
|
**6. Core User Journeys**
|
|
|
|
- What are the 2-3 most critical user flows?
|
|
- Example: Sign up → Create content → Share → Get feedback
|
|
|
|
**7. Business Model & Growth**
|
|
|
|
- How does this application generate value?
|
|
- Options: SaaS subscription, marketplace, freemium, advertising, one-time purchase
|
|
|
|
**8. Integration Ecosystem**
|
|
|
|
- What external services must you integrate with?
|
|
- Examples: payment processors, email services, analytics, social platforms
|
|
|
|
**9. Scale & Performance Goals**
|
|
|
|
- What scale are you planning for in the next 12 months?
|
|
- Users: dozens, hundreds, thousands, millions?
|
|
- Geographic: local, national, global?
|
|
|
|
**10. Success Metrics**
|
|
|
|
- How will you measure if your application is successful?
|
|
- Examples: user retention, revenue, engagement, conversion rates
|
|
|
|
## Document Structure
|
|
|
|
The generated document must follow this high-level structure:
|
|
|
|
### **Introduction**
|
|
|
|
- Application overview and purpose
|
|
- Target audience and user base
|
|
- Core value proposition
|
|
- Business context and goals
|
|
|
|
### **Core Features**
|
|
|
|
- **Feature Category 1:** (e.g., User Management)
|
|
- Purpose and user benefit
|
|
- Key functionalities
|
|
- User experience considerations
|
|
- **Feature Category 2:** (e.g., Content Creation)
|
|
- Purpose and user benefit
|
|
- Key functionalities
|
|
- User experience considerations
|
|
- **[Additional feature categories as needed]**
|
|
|
|
### **User Experience**
|
|
|
|
- User personas and roles
|
|
- Key user journeys and flows
|
|
- Interface design principles
|
|
- Accessibility and usability considerations
|
|
|
|
### **System Architecture**
|
|
|
|
- High-level system components
|
|
- Data flow and relationships
|
|
- Integration points and external services
|
|
- Security and privacy approach
|
|
|
|
### **Business Logic**
|
|
|
|
- Core business rules and processes
|
|
- Data models and relationships (conceptual)
|
|
- Workflow and state management
|
|
- Validation and business constraints
|
|
|
|
### **Future Considerations**
|
|
|
|
- Planned enhancements and features
|
|
- Scalability considerations
|
|
- Potential integrations
|
|
- Long-term vision and roadmap
|
|
|
|
## Target Audience
|
|
|
|
The document should be accessible to:
|
|
|
|
- **Business stakeholders** who need to understand the application's purpose and capabilities
|
|
- **Product managers** planning features and roadmaps
|
|
- **Designers** creating user interfaces and experiences
|
|
- **New developers** joining the project who need a high-level understanding
|
|
- **Technical leaders** making architectural decisions
|
|
|
|
The language should be clear, business-focused, and avoid technical implementation details.
|
|
|
|
## Writing Principles
|
|
|
|
### DO:
|
|
|
|
- **Business Focus:** Describe WHAT the application does, not HOW
|
|
- **User Value:** Emphasize benefits and outcomes for users
|
|
- **Clear Language:** Write for non-technical stakeholders
|
|
- **Visual Thinking:** Use diagrams and flows where helpful
|
|
- **Future Ready:** Consider growth and evolution paths
|
|
|
|
### DON'T:
|
|
|
|
- **Technical Details:** No code snippets or implementation specifics
|
|
- **Technology Stack:** Save for 2-tech-stack.mdc document
|
|
- **Database Schemas:** Keep data models conceptual
|
|
- **API Specifications:** Focus on capabilities, not endpoints
|
|
- **Performance Metrics:** Describe goals, not technical benchmarks
|
|
|
|
## Output
|
|
|
|
- **Format:** Markdown (`.mdc`)
|
|
- **Location:** `.claude/rules/`
|
|
- **Filename:** `1-app-design-document.mdc`
|
|
|
|
## Execution Steps
|
|
|
|
### 1. Start with Analysis
|
|
|
|
- Use Read, Glob, and Grep to explore the codebase
|
|
- Identify key features and patterns
|
|
- Look for existing documentation
|
|
- **Use extended thinking:** "Think deeply about this codebase's architecture, business purpose, and how different components work together to serve users"
|
|
|
|
### 2. Interactive Q&A
|
|
|
|
- **MUST ASK PROJECT STAGE FIRST**
|
|
- Present questions with numbered/lettered options
|
|
- Wait for user responses before proceeding
|
|
|
|
### 3. Update Project Status in Cursor Rule
|
|
|
|
Update `.claude/rules/3-project-status.mdc` with the project stage information:
|
|
|
|
```markdown
|
|
---
|
|
description: Project status and stage-specific development guidelines
|
|
globs:
|
|
alwaysApply: true
|
|
---
|
|
|
|
# Project Status Guidelines
|
|
|
|
## Current Project Stage: [Stage Name]
|
|
|
|
**Stage**: [Pre-MVP | MVP | Production | Enterprise]
|
|
|
|
### DO Care About (Current Stage Priorities)
|
|
|
|
[Stage-specific DO priorities from template below]
|
|
|
|
### DO NOT Care About (Skip for Velocity)
|
|
|
|
[Stage-specific DON'T priorities from template below]
|
|
|
|
### Development Approach
|
|
|
|
[Stage-specific development focus]
|
|
|
|
## Stage-Based Development Guidelines
|
|
|
|
[Keep existing stage categories and guidelines from the original file]
|
|
```
|
|
|
|
**Stage-Specific Content:**
|
|
|
|
- **Pre-MVP**:
|
|
|
|
- ✅ DO: Core functionality, security basics, input validation, working features
|
|
- ❌ DON'T: Unit tests, performance optimization, accessibility polish, perfect code
|
|
- 🚀 Focus: Ship fast with security, iterate based on feedback
|
|
|
|
- **MVP**:
|
|
|
|
- ✅ DO: Critical path testing, basic monitoring, user feedback loops
|
|
- ❌ DON'T: Comprehensive test coverage, advanced patterns, premature optimization
|
|
- 🚀 Focus: Stability for early users, rapid iteration
|
|
|
|
- **Production**:
|
|
|
|
- ✅ DO: Testing, monitoring, performance, accessibility, documentation
|
|
- ❌ DON'T: Skip security reviews, ignore technical debt
|
|
- 🚀 Focus: Reliability, scalability, user experience
|
|
|
|
- **Enterprise**:
|
|
- ✅ DO: Comprehensive testing, security audits, team coordination, compliance
|
|
- ❌ DON'T: Skip documentation, ignore code standards
|
|
- 🚀 Focus: Team efficiency, maintainability, compliance
|
|
|
|
### 4. Generate Document
|
|
|
|
- Follow the standard structure
|
|
- Tailor content to project stage
|
|
- Keep language accessible
|
|
|
|
### 5. Save and Next Steps
|
|
|
|
- Create directories: `mkdir -p .claude/docs .claude/rules`
|
|
- Save design document: `.claude/rules/1-app-design-document.mdc`
|
|
- Update Claude rule: `.claude/rules/3-project-status.mdc`
|
|
- Suggest: "Would you like me to create a technical stack document next?"
|