docs: 초기 파일 추가 및 기본 설정 구성
- .git-commit-template.txt: 커밋 메시지 템플릿 추가 - .gitignore: OS 및 데이터베이스 관련 파일 무시 설정 추가 - .mcp.json: MCP 서버 설정 추가 - CLAUDE.md: SuperClaude 엔트리 포인트 문서 추가 - README.md: 프로젝트 템플릿 설명 추가 - .claude/COMMANDS.md: 명령어 실행 프레임워크 문서 추가 - .claude/FLAGS.md: 플래그 시스템 문서 추가 - .claude/MCP.md: MCP 서버 통합 문서 추가 - .claude/MODES.md: 운영 모드 문서 추가 - .claude/ORCHESTRATOR.md: 지능형 라우팅 시스템 문서 추가 - .claude/PERSONAS.md: 페르소나 시스템 문서 추가 - .claude/PRINCIPLES.md: 핵심 원칙 문서 추가 - .claude/RULES.md: 실행 가능한 규칙 문서 추가 - .claude/settings.json: 권한 설정 추가 - .claude/commands 디렉토리: 다양한 명령어 문서 추가 - .taskmaster/config.json: 기본 설정 파일 추가 - .taskmaster/docs 디렉토리: 문서 파일 추가 - .taskmaster/tasks/tasks.json: 기본 작업 파일 추가
This commit is contained in:
227
.claude/commands/canvas/create_from_dir.md
Normal file
227
.claude/commands/canvas/create_from_dir.md
Normal file
@ -0,0 +1,227 @@
|
||||
---
|
||||
allowed-tools: [Read, Glob, Grep, Write, MultiEdit, LS]
|
||||
description: Analyzes markdown files in a specified directory, groups related content, and generates a JSON Canvas with nodes and edges.
|
||||
---
|
||||
|
||||
# Create JSON Canvas from Directory
|
||||
|
||||
## Context
|
||||
- Project root: !`pwd`
|
||||
- User-specified directory: $ARGUMENTS (e.g., path to directory like ".claude/commands/planning")
|
||||
- Existing canvas example: @.claude/commands/index.canvas
|
||||
|
||||
## Goal
|
||||
Generate a JSON Canvas file that visually represents the structure of markdown files in the given directory, grouping related files into nodes, creating groups for subdirectories or related topics, and connecting them with edges based on logical relationships.
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Validate Input
|
||||
- Ensure $ARGUMENTS provides a valid directory path relative to the project root.
|
||||
- If no directory is provided, ask the user: "Please specify the directory path to analyze (e.g., .claude/commands/planning)."
|
||||
- Use LS or Glob to verify the directory exists and contains markdown files.
|
||||
|
||||
### 2. Analyze Directory Structure
|
||||
- List all markdown files (*.md) in the directory and subdirectories using Glob or LS.
|
||||
- For each markdown file, read its content using Read or ReadFile.
|
||||
- **Think deeply** about the file names, paths, and content to identify relationships:
|
||||
- Group files by subdirectory (e.g., all files in "1-mrd" under one group).
|
||||
- Identify thematic relationships (e.g., sequential files like "1-start-session.md" and "2-analyze-research-data.md").
|
||||
- Use Grep to search for keywords, headers, or references between files to determine edges (e.g., if one file references another).
|
||||
|
||||
### 3. Generate Nodes
|
||||
- Create nodes for each markdown file:
|
||||
- Type: "file"
|
||||
- File: the relative path to the markdown file.
|
||||
- Position (x, y), width, height: Calculate based on structure (e.g., arrange in a grid or hierarchical layout).
|
||||
- Create group nodes for subdirectories or logical groupings:
|
||||
- Type: "group"
|
||||
- Label: the subdirectory name or group theme.
|
||||
- Position and size to encompass child nodes.
|
||||
|
||||
### 4. Generate Edges
|
||||
- Create edges between related nodes:
|
||||
- From one file to the next in a sequence (e.g., from "1-start-session.md" to "2-analyze-research-data.md").
|
||||
- From groups to contained nodes if needed.
|
||||
- Use sides like "right" to "left" for horizontal connections.
|
||||
- Add labels if relationships are specific (e.g., "next step").
|
||||
- Ensure edges follow the JSON Canvas spec (fromNode, toNode, fromSide, toSide, etc.).
|
||||
|
||||
### 5. Assemble JSON Canvas
|
||||
- Compile nodes and edges into a JSON object following the JSON Canvas Spec.
|
||||
- Nodes in z-index order (background groups first).
|
||||
- **CRITICAL:** Validate the JSON structure against the spec (e.g., required fields like id, type, x, y, width, height).
|
||||
|
||||
### 6. Output the Canvas
|
||||
- Write the JSON to a new .canvas file in the specified directory or a default location (e.g., "<directory>/index.canvas").
|
||||
- If the file exists, use MultiEdit to update it carefully.
|
||||
|
||||
## Templates & Structures
|
||||
The output JSON should strictly follow this structure:
|
||||
|
||||
```json
|
||||
{
|
||||
"nodes": [
|
||||
// Group node example
|
||||
{
|
||||
"type": "group",
|
||||
"id": "group1",
|
||||
"x": 0,
|
||||
"y": 0,
|
||||
"width": 500,
|
||||
"height": 300,
|
||||
"label": "Group Label"
|
||||
},
|
||||
// File node example
|
||||
{
|
||||
"type": "file",
|
||||
"id": "file1",
|
||||
"x": 100,
|
||||
"y": 100,
|
||||
"width": 200,
|
||||
"height": 100,
|
||||
"file": "path/to/file.md"
|
||||
}
|
||||
],
|
||||
"edges": [
|
||||
{
|
||||
"id": "edge1",
|
||||
"fromNode": "file1",
|
||||
"fromSide": "right",
|
||||
"toNode": "file2",
|
||||
"toSide": "left",
|
||||
"toEnd": "arrow",
|
||||
"label": "Connection"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Best Practices / DO & DON'T
|
||||
|
||||
### ✅ DO: Maintain Hierarchical Structure
|
||||
- Reflect directory hierarchy in group nodes.
|
||||
- **Why:** Preserves the original organization for intuitive visualization.
|
||||
|
||||
### ✅ DO: Use Meaningful Layout
|
||||
- Position nodes logically (e.g., left-to-right for sequences).
|
||||
- **Why:** Improves readability and understanding of relationships.
|
||||
|
||||
### ❌ DON'T: Overlap Nodes
|
||||
- Ensure calculated positions prevent overlaps.
|
||||
- **Why:** Avoids visual clutter in the canvas.
|
||||
|
||||
### ❌ DON'T: Ignore Spec Requirements
|
||||
- Always include required fields like id, type, x, y, width, height.
|
||||
- **Why:** Ensures compatibility with JSON Canvas viewers.
|
||||
|
||||
## Output
|
||||
- **Format:** JSON file conforming to JSON Canvas Spec.
|
||||
- **Location:** In the analyzed directory (e.g., "<input_dir>/index.canvas") or user-specified.
|
||||
- **Filename:** "index.canvas" by default, or based on directory name.
|
||||
|
||||
## Example Usage
|
||||
/claude:canvas:create_from_dir .claude/commands/planning
|
||||
|
||||
|
||||
## JSON Canvas Spec
|
||||
|
||||
<small>Version 1.0 — 2024-03-11</small>
|
||||
|
||||
### Top level
|
||||
|
||||
The top level of JSON Canvas contains two arrays:
|
||||
|
||||
- `nodes` (optional, array of nodes)
|
||||
- `edges` (optional, array of edges)
|
||||
|
||||
### Nodes
|
||||
|
||||
Nodes are objects within the canvas. Nodes may be text, files, links, or groups.
|
||||
|
||||
Nodes are placed in the array in ascending order by z-index. The first node in the array should be displayed below all other nodes, and the last node in the array should be displayed on top of all other nodes.
|
||||
|
||||
#### Generic node
|
||||
|
||||
All nodes include the following attributes:
|
||||
|
||||
- `id` (required, string) is a unique ID for the node.
|
||||
- `type` (required, string) is the node type.
|
||||
- `text`
|
||||
- `file`
|
||||
- `link`
|
||||
- `group`
|
||||
- `x` (required, integer) is the `x` position of the node in pixels.
|
||||
- `y` (required, integer) is the `y` position of the node in pixels.
|
||||
- `width` (required, integer) is the width of the node in pixels.
|
||||
- `height` (required, integer) is the height of the node in pixels.
|
||||
- `color` (optional, `canvasColor`) is the color of the node, see the Color section.
|
||||
|
||||
#### Text type nodes
|
||||
|
||||
Text type nodes store text. Along with generic node attributes, text nodes include the following attribute:
|
||||
|
||||
- `text` (required, string) in plain text with Markdown syntax.
|
||||
|
||||
#### File type nodes
|
||||
|
||||
File type nodes reference other files or attachments, such as images, videos, etc. Along with generic node attributes, file nodes include the following attributes:
|
||||
|
||||
- `file` (required, string) is the path to the file within the system.
|
||||
- `subpath` (optional, string) is a subpath that may link to a heading or a block. Always starts with a `#`.
|
||||
|
||||
#### Link type nodes
|
||||
|
||||
Link type nodes reference a URL. Along with generic node attributes, link nodes include the following attribute:
|
||||
|
||||
- `url` (required, string)
|
||||
|
||||
#### Group type nodes
|
||||
|
||||
Group type nodes are used as a visual container for nodes within it. Along with generic node attributes, group nodes include the following attributes:
|
||||
|
||||
- `label` (optional, string) is a text label for the group.
|
||||
- `background` (optional, string) is the path to the background image.
|
||||
- `backgroundStyle` (optional, string) is the rendering style of the background image. Valid values:
|
||||
- `cover` fills the entire width and height of the node.
|
||||
- `ratio` maintains the aspect ratio of the background image.
|
||||
- `repeat` repeats the image as a pattern in both x/y directions.
|
||||
|
||||
### Edges
|
||||
|
||||
Edges are lines that connect one node to another.
|
||||
|
||||
- `id` (required, string) is a unique ID for the edge.
|
||||
- `fromNode` (required, string) is the node `id` where the connection starts.
|
||||
- `fromSide` (optional, string) is the side where this edge starts. Valid values:
|
||||
- `top`
|
||||
- `right`
|
||||
- `bottom`
|
||||
- `left`
|
||||
- `fromEnd` (optional, string) is the shape of the endpoint at the edge start. Defaults to `none` if not specified. Valid values:
|
||||
- `none`
|
||||
- `arrow`
|
||||
- `toNode` (required, string) is the node `id` where the connection ends.
|
||||
- `toSide` (optional, string) is the side where this edge ends. Valid values:
|
||||
- `top`
|
||||
- `right`
|
||||
- `bottom`
|
||||
- `left`
|
||||
- `toEnd` (optional, string) is the shape of the endpoint at the edge end. Defaults to `arrow` if not specified. Valid values:
|
||||
- `none`
|
||||
- `arrow`
|
||||
- `color` (optional, `canvasColor`) is the color of the line, see the Color section.
|
||||
- `label` (optional, string) is a text label for the edge.
|
||||
|
||||
|
||||
### Color
|
||||
|
||||
The `canvasColor` type is used to encode color data for nodes and edges. Colors attributes expect a string. Colors can be specified in hex format e.g. `"#FF0000"`, or using one of the preset colors, e.g. `"1"` for red. Six preset colors exist, mapped to the following numbers:
|
||||
|
||||
- `"1"` red
|
||||
- `"2"` orange
|
||||
- `"3"` yellow
|
||||
- `"4"` green
|
||||
- `"5"` cyan
|
||||
- `"6"` purple
|
||||
|
||||
Specific values for the preset colors are intentionally not defined so that applications can tailor the presets to their specific brand colors or color scheme.
|
||||
8
.claude/commands/debug.md
Normal file
8
.claude/commands/debug.md
Normal file
@ -0,0 +1,8 @@
|
||||
1. Reflect on 5-7 different possible sources of the problem
|
||||
2. Distill those down to 1-2 most likely sources
|
||||
3. Add additional logs to validate your assumptions and track the transformation of data structures throughout the application control flow before we move onto implementing the actual code fix
|
||||
4. Use the "getConsoleLogs", "getConsoleErrors", "getNetworkLogs" & "getNetworkErrors" tools to obtain any newly added web browser logs
|
||||
5. Obtain the server logs as well if accessible - otherwise, ask me to copy/paste them into the chat
|
||||
6. Deeply reflect on what could be wrong + produce a comprehensive analysis of the issue
|
||||
7. Suggest additional logs if the issue persists or if the source is not yet clear
|
||||
8. Once a fix is implemented, ask for approval to remove the previously added logs
|
||||
@ -0,0 +1,524 @@
|
||||
---
|
||||
allowed-tools: [Read, Write, Glob, TodoWrite]
|
||||
description: Creates a comprehensive system architecture framework including domain separation, layered architecture, and component responsibility definitions.
|
||||
---
|
||||
|
||||
# Create Architecture Framework
|
||||
|
||||
## Context
|
||||
- **User Request:** $ARGUMENTS
|
||||
- **PRD Source:** Identified by `--prd` argument (PRD session name or index).
|
||||
- **Source PRD:** Final PRD document from the specified PRD session directory.
|
||||
- **Architecture Directory:** `.taskmaster/docs/design/architecture/`
|
||||
|
||||
## Goal
|
||||
To transform product requirements from a completed PRD into a comprehensive system architecture framework that defines domain boundaries, architectural layers, component responsibilities, and foundational patterns necessary for scalable and maintainable software development.
|
||||
|
||||
## Process
|
||||
|
||||
1. **Identify Source PRD Session:**
|
||||
- Use the `--prd` argument to locate the correct PRD session directory (e.g., `.taskmaster/docs/prd/001-enterprise-expansion/`).
|
||||
- Find the final PRD document (`product-requirements-document_*.md`) within the session directory.
|
||||
|
||||
2. **Extract Architecture Requirements from PRD:**
|
||||
- **Functional Requirements:** Core features and business capabilities
|
||||
- **Non-Functional Requirements:** Performance, scalability, security, reliability
|
||||
- **Technical Constraints:** Platform requirements, integration needs, compliance
|
||||
- **User Experience Requirements:** Response time, availability, user load
|
||||
- **Business Requirements:** Growth projections, market constraints, budget limitations
|
||||
|
||||
3. **Determine Architecture Session Index:**
|
||||
- Scan the `.taskmaster/docs/design/architecture/` directory to find the highest existing session index.
|
||||
- Assign the next sequential number for the new architecture session.
|
||||
|
||||
4. **Create Architecture Session Directory:**
|
||||
- Create a new directory named `[index]-[prd_session_name]` inside `.taskmaster/docs/design/architecture/`.
|
||||
- Example: `.taskmaster/docs/design/architecture/001-enterprise-expansion/`
|
||||
|
||||
5. **Initialize Architecture Session State:**
|
||||
- Create a `_session-state.json` file in the new architecture session directory.
|
||||
- Initialize it with architecture session details:
|
||||
```json
|
||||
{
|
||||
"index": 1,
|
||||
"name": "prd-session-name",
|
||||
"type": "architecture",
|
||||
"status": "initialized",
|
||||
"created": "ISO datetime",
|
||||
"lastUpdated": "ISO datetime",
|
||||
"currentStep": "architecture_framework_creation",
|
||||
"completedSteps": [],
|
||||
"nextAction": "Generate comprehensive architecture framework",
|
||||
"sourceType": "prd",
|
||||
"sourceName": "prd-session-name",
|
||||
"architectureScope": "system-wide|domain-specific|service-specific",
|
||||
"architectureStyle": "layered|microservices|event-driven|hybrid",
|
||||
"architectureResults": {}
|
||||
}
|
||||
```
|
||||
|
||||
6. **Perform Domain Analysis:**
|
||||
- **Domain Identification:** Identify business domains and bounded contexts from PRD features
|
||||
- **Domain Modeling:** Create domain models and understand domain relationships
|
||||
- **Bounded Context Mapping:** Define context boundaries and integration patterns
|
||||
- **Domain Events:** Identify key domain events and workflows
|
||||
- **Subdomain Classification:** Classify subdomains as core, supporting, or generic
|
||||
|
||||
7. **Design Layered Architecture:**
|
||||
- **Presentation Layer:** User interface, API endpoints, controllers
|
||||
- **Application Layer:** Application services, use cases, workflow orchestration
|
||||
- **Domain Layer:** Domain entities, value objects, domain services, aggregates
|
||||
- **Infrastructure Layer:** Data access, external services, technical concerns
|
||||
- **Cross-Cutting Concerns:** Logging, security, monitoring, configuration
|
||||
|
||||
8. **Define Component Responsibilities:**
|
||||
- **Component Identification:** Identify major system components and modules
|
||||
- **Responsibility Assignment:** Define clear responsibilities for each component
|
||||
- **Interface Design:** Design component interfaces and contracts
|
||||
- **Dependency Management:** Establish dependency rules and patterns
|
||||
- **Component Interaction:** Define communication patterns between components
|
||||
|
||||
9. **Generate Architecture Framework Document:**
|
||||
- Create the primary architecture document named `architecture-framework_[prd_session_name].md`.
|
||||
- Structure content according to the architecture framework template.
|
||||
- Include:
|
||||
- **Architecture Overview:** High-level architecture vision and principles
|
||||
- **Domain Architecture:** Domain boundaries and context mapping
|
||||
- **Layered Architecture:** Layer definitions and responsibilities
|
||||
- **Component Architecture:** Component design and interfaces
|
||||
- **Architecture Patterns:** Key architectural patterns and decisions
|
||||
- **Quality Attributes:** Architecture support for quality requirements
|
||||
|
||||
10. **Update Session State:**
|
||||
- Set `status` to `framework_complete`.
|
||||
- Update `architectureResults` with architecture metrics and components.
|
||||
- Record completion timestamp.
|
||||
|
||||
11. **Notify User with Architecture Insights:**
|
||||
- Inform the user that the architecture framework has been successfully generated.
|
||||
- Provide the file path and key architectural highlights.
|
||||
- **Suggest logical next steps based on framework outcomes:**
|
||||
- "Your architecture framework is complete. Consider designing detailed components using `/design/system-architecture/2-design-components --name=[session_name]`"
|
||||
- "Review the domain boundaries with your team to validate business alignment."
|
||||
- "Use the layered architecture to guide development team organization and responsibilities."
|
||||
|
||||
## Templates & Structures
|
||||
|
||||
### Architecture Framework Template
|
||||
```markdown
|
||||
# System Architecture Framework: [PRD Session Name]
|
||||
|
||||
**Created:** [Date]
|
||||
**Source:** PRD Session: [PRD Session Name]
|
||||
**Architecture Style:** [Layered/Microservices/Event-Driven/Hybrid]
|
||||
**Target Scale:** [Small/Medium/Large/Enterprise]
|
||||
**Last Updated:** [Date]
|
||||
|
||||
---
|
||||
|
||||
## Architecture Overview
|
||||
|
||||
### Architecture Vision
|
||||
- **Vision Statement:** [Clear architectural vision aligned with business goals]
|
||||
- **Architecture Principles:** [Fundamental principles guiding architectural decisions]
|
||||
- **Design Philosophy:** [Overall approach to system design and evolution]
|
||||
- **Success Criteria:** [How architectural success will be measured]
|
||||
|
||||
### Architecture Drivers
|
||||
- **Business Drivers:** [Key business requirements driving architecture]
|
||||
- **Technical Drivers:** [Technical requirements and constraints]
|
||||
- **Quality Drivers:** [Quality attributes and non-functional requirements]
|
||||
- **Constraint Drivers:** [Platform, budget, time, and regulatory constraints]
|
||||
|
||||
### Architecture Characteristics
|
||||
- **Scalability:** [Horizontal and vertical scaling approach]
|
||||
- **Reliability:** [Fault tolerance and resilience patterns]
|
||||
- **Performance:** [Performance targets and optimization strategies]
|
||||
- **Security:** [Security architecture and protection mechanisms]
|
||||
- **Maintainability:** [Code organization and maintenance strategies]
|
||||
|
||||
---
|
||||
|
||||
## Domain Architecture
|
||||
|
||||
### Domain Identification
|
||||
#### Core Domain: [Primary Business Domain]
|
||||
- **Description:** [What this domain represents in the business]
|
||||
- **Key Entities:** [Main business entities and concepts]
|
||||
- **Business Rules:** [Critical business rules and constraints]
|
||||
- **Value Proposition:** [How this domain creates business value]
|
||||
|
||||
#### Supporting Domain: [Secondary Business Domain]
|
||||
- **Description:** [What this domain represents in the business]
|
||||
- **Key Entities:** [Main business entities and concepts]
|
||||
- **Business Rules:** [Critical business rules and constraints]
|
||||
- **Value Proposition:** [How this domain supports core business]
|
||||
|
||||
#### Generic Domain: [Utility Domain]
|
||||
- **Description:** [What this domain represents in the business]
|
||||
- **Key Entities:** [Main business entities and concepts]
|
||||
- **Business Rules:** [Critical business rules and constraints]
|
||||
- **Value Proposition:** [How this domain provides utility]
|
||||
|
||||
### Bounded Context Mapping
|
||||
#### Context 1: [Context Name]
|
||||
- **Responsibility:** [What this context is responsible for]
|
||||
- **Boundaries:** [Clear boundaries and what's included/excluded]
|
||||
- **Interfaces:** [How this context exposes its capabilities]
|
||||
- **Dependencies:** [Other contexts this depends on]
|
||||
|
||||
#### Context 2: [Context Name]
|
||||
- **Responsibility:** [What this context is responsible for]
|
||||
- **Boundaries:** [Clear boundaries and what's included/excluded]
|
||||
- **Interfaces:** [How this context exposes its capabilities]
|
||||
- **Dependencies:** [Other contexts this depends on]
|
||||
|
||||
### Domain Events
|
||||
- **Event 1:** [Event Name] - [When it occurs and what it represents]
|
||||
- **Event 2:** [Event Name] - [When it occurs and what it represents]
|
||||
- **Event 3:** [Event Name] - [When it occurs and what it represents]
|
||||
|
||||
### Context Integration Patterns
|
||||
- **Shared Kernel:** [Shared models and libraries between contexts]
|
||||
- **Customer-Supplier:** [Upstream/downstream relationships]
|
||||
- **Conformist:** [One context conforms to another's model]
|
||||
- **Anti-Corruption Layer:** [Protection against external models]
|
||||
|
||||
---
|
||||
|
||||
## Layered Architecture
|
||||
|
||||
### Presentation Layer
|
||||
#### Responsibility
|
||||
- User interface components and user interaction handling
|
||||
- API endpoints and request/response handling
|
||||
- Input validation and output formatting
|
||||
- User authentication and session management
|
||||
|
||||
#### Components
|
||||
- **Web Controllers:** [REST API controllers and request handlers]
|
||||
- **UI Components:** [User interface components and views]
|
||||
- **API Gateways:** [API gateway and routing logic]
|
||||
- **Authentication Middleware:** [Authentication and authorization components]
|
||||
|
||||
#### Design Patterns
|
||||
- **MVC Pattern:** [Model-View-Controller for web interfaces]
|
||||
- **API Gateway Pattern:** [Centralized API management]
|
||||
- **Frontend-Backend Separation:** [Clear separation of concerns]
|
||||
|
||||
### Application Layer
|
||||
#### Responsibility
|
||||
- Application services and use case orchestration
|
||||
- Business workflow coordination
|
||||
- Transaction management
|
||||
- Application-specific business logic
|
||||
|
||||
#### Components
|
||||
- **Application Services:** [Use case implementations and workflow coordination]
|
||||
- **Command Handlers:** [Command pattern implementations]
|
||||
- **Query Handlers:** [Query pattern implementations]
|
||||
- **Workflow Orchestrators:** [Business process coordination]
|
||||
|
||||
#### Design Patterns
|
||||
- **Command Query Responsibility Segregation (CQRS):** [Separate read/write operations]
|
||||
- **Mediator Pattern:** [Request/response handling]
|
||||
- **Unit of Work Pattern:** [Transaction management]
|
||||
|
||||
### Domain Layer
|
||||
#### Responsibility
|
||||
- Core business logic and domain rules
|
||||
- Domain entities and value objects
|
||||
- Domain services and aggregates
|
||||
- Business invariants and constraints
|
||||
|
||||
#### Components
|
||||
- **Domain Entities:** [Core business objects with identity]
|
||||
- **Value Objects:** [Immutable objects representing concepts]
|
||||
- **Domain Services:** [Business logic that doesn't belong to entities]
|
||||
- **Aggregates:** [Consistency boundaries and transaction scopes]
|
||||
- **Domain Events:** [Business events and event handlers]
|
||||
|
||||
#### Design Patterns
|
||||
- **Domain-Driven Design (DDD):** [Domain modeling and bounded contexts]
|
||||
- **Repository Pattern:** [Data access abstraction]
|
||||
- **Factory Pattern:** [Complex object creation]
|
||||
- **Strategy Pattern:** [Business rule variations]
|
||||
|
||||
### Infrastructure Layer
|
||||
#### Responsibility
|
||||
- Data persistence and external service integration
|
||||
- Technical infrastructure and cross-cutting concerns
|
||||
- Framework and technology-specific implementations
|
||||
- System integration and communication
|
||||
|
||||
#### Components
|
||||
- **Data Access Layer:** [Database access and ORM implementations]
|
||||
- **External Service Clients:** [Third-party service integrations]
|
||||
- **Message Brokers:** [Asynchronous communication infrastructure]
|
||||
- **Configuration Management:** [Application configuration and settings]
|
||||
|
||||
#### Design Patterns
|
||||
- **Repository Pattern:** [Data access abstraction]
|
||||
- **Adapter Pattern:** [External service integration]
|
||||
- **Decorator Pattern:** [Cross-cutting concerns]
|
||||
|
||||
---
|
||||
|
||||
## Component Architecture
|
||||
|
||||
### Component Identification
|
||||
#### Component 1: [Component Name]
|
||||
- **Purpose:** [What this component does and why it exists]
|
||||
- **Responsibilities:** [Specific responsibilities and capabilities]
|
||||
- **Interfaces:** [Public interfaces and contracts]
|
||||
- **Dependencies:** [Other components this depends on]
|
||||
- **Technology:** [Technology stack and frameworks]
|
||||
|
||||
#### Component 2: [Component Name]
|
||||
- **Purpose:** [What this component does and why it exists]
|
||||
- **Responsibilities:** [Specific responsibilities and capabilities]
|
||||
- **Interfaces:** [Public interfaces and contracts]
|
||||
- **Dependencies:** [Other components this depends on]
|
||||
- **Technology:** [Technology stack and frameworks]
|
||||
|
||||
### Component Interaction Patterns
|
||||
- **Synchronous Communication:** [REST APIs, direct method calls]
|
||||
- **Asynchronous Communication:** [Message queues, event streams]
|
||||
- **Data Sharing:** [Shared databases, data stores]
|
||||
- **Service Discovery:** [How components find each other]
|
||||
|
||||
### Component Deployment
|
||||
- **Deployment Units:** [How components are packaged and deployed]
|
||||
- **Scalability:** [How components scale independently]
|
||||
- **Fault Isolation:** [How component failures are contained]
|
||||
- **Monitoring:** [How components are monitored and observed]
|
||||
|
||||
---
|
||||
|
||||
## Architecture Patterns
|
||||
|
||||
### Architectural Style
|
||||
- **Primary Style:** [Layered/Microservices/Event-Driven/Hybrid]
|
||||
- **Style Rationale:** [Why this style was chosen]
|
||||
- **Style Benefits:** [Benefits this style provides]
|
||||
- **Style Trade-offs:** [Trade-offs and limitations]
|
||||
|
||||
### Key Patterns
|
||||
#### Pattern 1: [Pattern Name]
|
||||
- **Problem:** [What problem this pattern solves]
|
||||
- **Solution:** [How the pattern addresses the problem]
|
||||
- **Implementation:** [How this pattern is implemented]
|
||||
- **Benefits:** [Benefits of using this pattern]
|
||||
- **Trade-offs:** [Costs and limitations]
|
||||
|
||||
#### Pattern 2: [Pattern Name]
|
||||
- **Problem:** [What problem this pattern solves]
|
||||
- **Solution:** [How the pattern addresses the problem]
|
||||
- **Implementation:** [How this pattern is implemented]
|
||||
- **Benefits:** [Benefits of using this pattern]
|
||||
- **Trade-offs:** [Costs and limitations]
|
||||
|
||||
### Integration Patterns
|
||||
- **API Gateway:** [Centralized API management and routing]
|
||||
- **Service Mesh:** [Service-to-service communication]
|
||||
- **Event Sourcing:** [Event-driven state management]
|
||||
- **CQRS:** [Command Query Responsibility Segregation]
|
||||
|
||||
---
|
||||
|
||||
## Quality Attributes
|
||||
|
||||
### Performance Architecture
|
||||
- **Response Time:** [Target response times and performance budgets]
|
||||
- **Throughput:** [Expected transaction volumes and capacity]
|
||||
- **Resource Usage:** [Memory, CPU, and storage considerations]
|
||||
- **Caching Strategy:** [Caching layers and invalidation policies]
|
||||
|
||||
### Scalability Architecture
|
||||
- **Horizontal Scaling:** [Scale-out capabilities and patterns]
|
||||
- **Vertical Scaling:** [Scale-up capabilities and limitations]
|
||||
- **Auto-scaling:** [Automatic scaling triggers and policies]
|
||||
- **Load Distribution:** [Load balancing and traffic distribution]
|
||||
|
||||
### Reliability Architecture
|
||||
- **Fault Tolerance:** [Failure handling and recovery patterns]
|
||||
- **Resilience Patterns:** [Circuit breakers, retries, timeouts]
|
||||
- **Backup and Recovery:** [Data backup and disaster recovery]
|
||||
- **High Availability:** [Redundancy and failover mechanisms]
|
||||
|
||||
### Security Architecture
|
||||
- **Authentication:** [User authentication and identity management]
|
||||
- **Authorization:** [Access control and permission management]
|
||||
- **Data Protection:** [Encryption and data privacy]
|
||||
- **Security Monitoring:** [Threat detection and response]
|
||||
|
||||
### Maintainability Architecture
|
||||
- **Code Organization:** [Module structure and dependency management]
|
||||
- **Testing Strategy:** [Testing architecture and automation]
|
||||
- **Documentation:** [Architecture documentation and knowledge management]
|
||||
- **Evolution:** [Architecture evolution and refactoring strategies]
|
||||
|
||||
---
|
||||
|
||||
## Architecture Decisions
|
||||
|
||||
### Decision 1: [Decision Topic]
|
||||
- **Context:** [Situation requiring a decision]
|
||||
- **Decision:** [What was decided]
|
||||
- **Rationale:** [Why this decision was made]
|
||||
- **Consequences:** [Impact and implications]
|
||||
- **Alternatives:** [Other options considered]
|
||||
|
||||
### Decision 2: [Decision Topic]
|
||||
- **Context:** [Situation requiring a decision]
|
||||
- **Decision:** [What was decided]
|
||||
- **Rationale:** [Why this decision was made]
|
||||
- **Consequences:** [Impact and implications]
|
||||
- **Alternatives:** [Other options considered]
|
||||
|
||||
---
|
||||
|
||||
## Implementation Guidance
|
||||
|
||||
### Development Approach
|
||||
- **Development Methodology:** [Agile, incremental, iterative approach]
|
||||
- **Team Organization:** [How teams align with architecture]
|
||||
- **Technology Standards:** [Coding standards and technology guidelines]
|
||||
- **Quality Practices:** [Code review, testing, and quality assurance]
|
||||
|
||||
### Architecture Governance
|
||||
- **Architecture Review:** [Architecture review process and criteria]
|
||||
- **Change Management:** [How architecture changes are managed]
|
||||
- **Compliance:** [Architecture compliance and enforcement]
|
||||
- **Evolution:** [Architecture evolution and improvement]
|
||||
|
||||
### Risk Management
|
||||
- **Technical Risks:** [Key technical risks and mitigation strategies]
|
||||
- **Architecture Risks:** [Architecture-specific risks and responses]
|
||||
- **Integration Risks:** [Component integration and system risks]
|
||||
- **Performance Risks:** [Performance and scalability risks]
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
### Immediate Actions
|
||||
1. **Component Design:** [Design detailed component specifications]
|
||||
2. **Integration Planning:** [Plan component integration and communication]
|
||||
3. **Technology Selection:** [Select specific technologies and frameworks]
|
||||
4. **Prototype Development:** [Develop architecture proof-of-concept]
|
||||
|
||||
### Architecture Validation
|
||||
- **Architecture Review:** [Conduct formal architecture review]
|
||||
- **Stakeholder Alignment:** [Ensure stakeholder agreement and buy-in]
|
||||
- **Technical Validation:** [Validate technical feasibility and approach]
|
||||
- **Risk Assessment:** [Assess and mitigate architecture risks]
|
||||
|
||||
### Development Preparation
|
||||
- **Team Preparation:** [Prepare development teams for implementation]
|
||||
- **Environment Setup:** [Set up development and testing environments]
|
||||
- **Tooling Selection:** [Select development tools and frameworks]
|
||||
- **Documentation:** [Create detailed implementation documentation]
|
||||
|
||||
---
|
||||
|
||||
## Appendices
|
||||
|
||||
### A. PRD Requirements Analysis
|
||||
[Summary of PRD requirements and their architectural implications]
|
||||
|
||||
### B. Architecture Diagrams
|
||||
[High-level architecture diagrams and component relationships]
|
||||
|
||||
### C. Technology Evaluation
|
||||
[Technology evaluation criteria and selection rationale]
|
||||
|
||||
### D. Performance Modeling
|
||||
[Performance projections and capacity planning]
|
||||
|
||||
### E. Security Assessment
|
||||
[Security requirements and threat modeling]
|
||||
```
|
||||
|
||||
### Session State Structure
|
||||
```json
|
||||
{
|
||||
"index": 1,
|
||||
"name": "prd-session-name",
|
||||
"type": "architecture",
|
||||
"status": "framework_complete",
|
||||
"created": "ISO datetime",
|
||||
"lastUpdated": "ISO datetime",
|
||||
"currentStep": "framework_complete",
|
||||
"completedSteps": ["architecture_framework_creation", "domain_analysis", "layer_design"],
|
||||
"nextAction": "Ready for component design or integration architecture",
|
||||
"sourceType": "prd",
|
||||
"sourceName": "prd-session-name",
|
||||
"architectureScope": "system-wide",
|
||||
"architectureStyle": "layered",
|
||||
"architectureResults": {
|
||||
"domains": 3,
|
||||
"layers": 4,
|
||||
"components": 12,
|
||||
"patterns": 8,
|
||||
"qualityAttributes": 5,
|
||||
"decisions": 6,
|
||||
"createdDate": "ISO datetime"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
### ✅ DO: Requirements-Driven Architecture
|
||||
- **Start with PRD requirements** and ensure architecture serves business needs
|
||||
- **Prioritize quality attributes** based on business priorities and user needs
|
||||
- **Consider growth and evolution** when designing architectural foundations
|
||||
- **Balance flexibility with simplicity** to avoid over-engineering
|
||||
|
||||
**Why:** Requirements-driven architecture ensures that architectural decisions support business objectives and user value.
|
||||
|
||||
### ✅ DO: Domain-Driven Design
|
||||
- **Identify clear domain boundaries** and model business concepts accurately
|
||||
- **Use ubiquitous language** that bridges business and technical teams
|
||||
- **Separate core domains** from supporting and generic domains
|
||||
- **Design for domain evolution** and changing business requirements
|
||||
|
||||
**Why:** Domain-driven design creates architecture that reflects business reality and can evolve with business needs.
|
||||
|
||||
### ✅ DO: Layered Responsibility
|
||||
- **Maintain clear layer separation** with well-defined responsibilities
|
||||
- **Follow dependency rules** to ensure proper architectural flow
|
||||
- **Avoid layer violations** and maintain architectural integrity
|
||||
- **Design clean interfaces** between layers and components
|
||||
|
||||
**Why:** Layered responsibility creates maintainable, testable, and evolvable architecture.
|
||||
|
||||
### ❌ DON'T: Technology-First Architecture
|
||||
- **Don't start with technology choices** before understanding requirements
|
||||
- **Don't let technology constraints** drive architectural decisions
|
||||
- **Don't ignore business requirements** in favor of technical preferences
|
||||
- **Don't create architecture** that serves technology rather than business
|
||||
|
||||
**Why:** Technology-first architecture often results in solutions that don't meet business needs or user requirements.
|
||||
|
||||
### ❌ DON'T: Premature Optimization
|
||||
- **Don't optimize for performance** before understanding actual requirements
|
||||
- **Don't add complexity** for theoretical future needs
|
||||
- **Don't over-engineer** solutions beyond current requirements
|
||||
- **Don't ignore simplicity** in favor of sophisticated patterns
|
||||
|
||||
**Why:** Premature optimization creates unnecessary complexity and can hinder business agility and development velocity.
|
||||
|
||||
## Output
|
||||
- **Format:** Comprehensive architecture framework with domain and layer design
|
||||
- **Location:** `.taskmaster/docs/design/architecture/[index]-[prd_session_name]/`
|
||||
- **Primary Files:**
|
||||
- `architecture-framework_[prd_session_name].md` - Main architecture framework
|
||||
- `_session-state.json` - Session tracking and metadata
|
||||
|
||||
## Example Usage
|
||||
- **Create architecture framework from PRD:**
|
||||
`/design/system-architecture/1-create-architecture-framework --prd="enterprise-expansion"`
|
||||
- **Create by PRD index:**
|
||||
`/design/system-architecture/1-create-architecture-framework --prd="1"`
|
||||
@ -0,0 +1,785 @@
|
||||
---
|
||||
allowed-tools: [Read, Write, Glob, TodoWrite]
|
||||
description: Designs detailed system components with specifications, interfaces, and implementation guidelines based on architecture framework.
|
||||
---
|
||||
|
||||
# Design Components
|
||||
|
||||
## Context
|
||||
- **User Request:** $ARGUMENTS
|
||||
- **Architecture Session:** Identified by `--name` argument (architecture session name or index).
|
||||
- **Source Architecture:** Architecture framework document from the specified architecture session directory.
|
||||
- **Component Selection:** Optional `--components` argument to focus on specific components.
|
||||
- **Design Directory:** `.taskmaster/docs/design/architecture/`
|
||||
|
||||
## Goal
|
||||
To transform the high-level architecture framework into detailed component specifications that define interfaces, responsibilities, implementation patterns, and integration contracts necessary for development teams to build robust, maintainable software components.
|
||||
|
||||
## Process
|
||||
|
||||
1. **Identify Source Architecture Session:**
|
||||
- Use the `--name` argument to locate the correct architecture session directory (e.g., `.taskmaster/docs/design/architecture/001-enterprise-expansion/`).
|
||||
- Find the architecture framework document (`architecture-framework_*.md`) within the session directory.
|
||||
|
||||
2. **Extract Component Requirements from Architecture:**
|
||||
- **Component Identification:** Components identified in the architecture framework
|
||||
- **Layer Assignments:** Which architectural layer each component belongs to
|
||||
- **Domain Boundaries:** Domain context and bounded context for each component
|
||||
- **Quality Attributes:** Performance, security, scalability requirements per component
|
||||
- **Integration Points:** How components interact with each other
|
||||
|
||||
3. **Process Component Selection (if specified):**
|
||||
- If `--components` argument is provided, focus on specific components only
|
||||
- Parse comma-separated component names or indices
|
||||
- Validate that specified components exist in the architecture framework
|
||||
|
||||
4. **Perform Component Analysis:**
|
||||
- **Responsibility Definition:** Clear definition of what each component does
|
||||
- **Interface Design:** Public APIs, contracts, and communication protocols
|
||||
- **Dependency Analysis:** Dependencies on other components and external systems
|
||||
- **Data Flow Analysis:** How data flows through and between components
|
||||
- **Error Handling:** Error handling strategies and fault tolerance patterns
|
||||
|
||||
5. **Design Component Specifications:**
|
||||
- **Component Architecture:** Internal structure and sub-components
|
||||
- **Interface Contracts:** Detailed API specifications and data models
|
||||
- **Implementation Patterns:** Recommended design patterns and practices
|
||||
- **Technology Guidelines:** Technology stack and framework recommendations
|
||||
- **Testing Strategy:** Unit, integration, and contract testing approaches
|
||||
|
||||
6. **Generate Component Design Document:**
|
||||
- Create the component design document named `component-design_[architecture_session_name].md`.
|
||||
- Structure content according to the component design template.
|
||||
- Include:
|
||||
- **Component Overview:** High-level component landscape and relationships
|
||||
- **Component Specifications:** Detailed specifications for each component
|
||||
- **Interface Definitions:** API contracts and communication protocols
|
||||
- **Implementation Guidelines:** Development patterns and best practices
|
||||
- **Integration Patterns:** Component interaction and communication patterns
|
||||
- **Quality Assurance:** Testing and validation approaches
|
||||
|
||||
7. **Create Component Interface Specifications:**
|
||||
- Generate individual interface specification files for complex components
|
||||
- Create API documentation and contract definitions
|
||||
- Define data models and schema specifications
|
||||
- Document error handling and exception patterns
|
||||
|
||||
8. **Update Architecture Session State:**
|
||||
- Update the existing `_session-state.json` file in the architecture session directory.
|
||||
- Add component design completion status and results.
|
||||
- Update `completedSteps` and `nextAction` fields.
|
||||
|
||||
9. **Notify User with Component Insights:**
|
||||
- Inform the user that the component design has been successfully generated.
|
||||
- Provide file paths and key component highlights.
|
||||
- **Suggest logical next steps based on component design:**
|
||||
- "Your component design is complete. Consider defining integration architecture using `/design/system-architecture/3-integration-architecture --name=[session_name]`"
|
||||
- "Review the component interfaces with your development teams to ensure implementation feasibility."
|
||||
- "Use the component specifications to create detailed development tasks and sprint planning."
|
||||
|
||||
## Templates & Structures
|
||||
|
||||
### Component Design Template
|
||||
```markdown
|
||||
# Component Design: [Architecture Session Name]
|
||||
|
||||
**Created:** [Date]
|
||||
**Source:** Architecture Framework: [Architecture Session Name]
|
||||
**Component Scope:** [All Components / Specific Components]
|
||||
**Target Components:** [List of components if specific scope]
|
||||
**Last Updated:** [Date]
|
||||
|
||||
---
|
||||
|
||||
## Component Overview
|
||||
|
||||
### System Component Landscape
|
||||
- **Total Components:** [Number of components in the system]
|
||||
- **Layer Distribution:** [Number of components per architectural layer]
|
||||
- **Domain Distribution:** [Number of components per domain]
|
||||
- **Integration Complexity:** [Assessment of component integration complexity]
|
||||
|
||||
### Component Relationships
|
||||
- **Core Components:** [Components that are central to system functionality]
|
||||
- **Supporting Components:** [Components that support core functionality]
|
||||
- **Infrastructure Components:** [Components that provide technical infrastructure]
|
||||
- **Integration Components:** [Components that handle external integrations]
|
||||
|
||||
### Component Dependencies
|
||||
- **High-Level Dependencies:** [Major dependency relationships between components]
|
||||
- **Circular Dependencies:** [Any circular dependencies and resolution strategies]
|
||||
- **External Dependencies:** [Dependencies on external systems and services]
|
||||
|
||||
---
|
||||
|
||||
## Component Specifications
|
||||
|
||||
### Presentation Layer Components
|
||||
|
||||
#### Component 1: [Component Name]
|
||||
**Layer:** Presentation
|
||||
**Domain:** [Domain Context]
|
||||
**Responsibility:** [Primary responsibility and purpose]
|
||||
|
||||
##### Architecture
|
||||
- **Component Type:** [Controller/Gateway/UI Component/API Handler]
|
||||
- **Deployment Unit:** [How this component is deployed]
|
||||
- **Scalability:** [Horizontal/Vertical scaling characteristics]
|
||||
- **State Management:** [Stateless/Stateful and state handling approach]
|
||||
|
||||
##### Responsibilities
|
||||
- **Primary Responsibility:** [Main function of this component]
|
||||
- **Secondary Responsibilities:** [Additional functions and capabilities]
|
||||
- **Business Rules:** [Business logic handled by this component]
|
||||
- **Data Transformation:** [Data processing and transformation responsibilities]
|
||||
|
||||
##### Interface Definition
|
||||
```typescript
|
||||
// Public Interface
|
||||
interface ComponentName {
|
||||
// Core Methods
|
||||
methodName(request: RequestType): Promise<ResponseType>;
|
||||
|
||||
// Event Handlers
|
||||
onEvent(event: EventType): void;
|
||||
|
||||
// Lifecycle Methods
|
||||
initialize(): Promise<void>;
|
||||
shutdown(): Promise<void>;
|
||||
}
|
||||
|
||||
// Request/Response Types
|
||||
interface RequestType {
|
||||
// Request structure
|
||||
}
|
||||
|
||||
interface ResponseType {
|
||||
// Response structure
|
||||
}
|
||||
```
|
||||
|
||||
##### Dependencies
|
||||
- **Required Dependencies:** [Components this depends on]
|
||||
- **Optional Dependencies:** [Components this can optionally use]
|
||||
- **External Dependencies:** [External services and systems]
|
||||
- **Infrastructure Dependencies:** [Databases, message queues, etc.]
|
||||
|
||||
##### Data Flow
|
||||
- **Input Data:** [Data received from other components or external sources]
|
||||
- **Output Data:** [Data produced and sent to other components]
|
||||
- **Data Transformation:** [How data is processed and transformed]
|
||||
- **Data Validation:** [Input validation and sanitization]
|
||||
|
||||
##### Error Handling
|
||||
- **Error Types:** [Types of errors this component can encounter]
|
||||
- **Error Handling Strategy:** [How errors are handled and propagated]
|
||||
- **Retry Logic:** [Retry mechanisms and policies]
|
||||
- **Fallback Mechanisms:** [Fallback strategies for failures]
|
||||
|
||||
##### Quality Attributes
|
||||
- **Performance:** [Performance requirements and optimization strategies]
|
||||
- **Security:** [Security requirements and implementation approach]
|
||||
- **Reliability:** [Reliability requirements and fault tolerance]
|
||||
- **Maintainability:** [Code organization and maintenance considerations]
|
||||
|
||||
##### Testing Strategy
|
||||
- **Unit Testing:** [Unit testing approach and coverage]
|
||||
- **Integration Testing:** [Integration testing strategy]
|
||||
- **Contract Testing:** [API contract testing approach]
|
||||
- **Performance Testing:** [Performance testing requirements]
|
||||
|
||||
##### Implementation Guidelines
|
||||
- **Design Patterns:** [Recommended design patterns]
|
||||
- **Technology Stack:** [Recommended technologies and frameworks]
|
||||
- **Code Organization:** [Code structure and organization guidelines]
|
||||
- **Configuration:** [Configuration management approach]
|
||||
|
||||
### Application Layer Components
|
||||
|
||||
#### Component 2: [Component Name]
|
||||
**Layer:** Application
|
||||
**Domain:** [Domain Context]
|
||||
**Responsibility:** [Primary responsibility and purpose]
|
||||
|
||||
##### Architecture
|
||||
- **Component Type:** [Application Service/Command Handler/Query Handler/Orchestrator]
|
||||
- **Deployment Unit:** [How this component is deployed]
|
||||
- **Scalability:** [Horizontal/Vertical scaling characteristics]
|
||||
- **State Management:** [Stateless/Stateful and state handling approach]
|
||||
|
||||
##### Responsibilities
|
||||
- **Primary Responsibility:** [Main function of this component]
|
||||
- **Secondary Responsibilities:** [Additional functions and capabilities]
|
||||
- **Business Rules:** [Business logic handled by this component]
|
||||
- **Workflow Coordination:** [Business process coordination responsibilities]
|
||||
|
||||
##### Interface Definition
|
||||
```typescript
|
||||
// Application Service Interface
|
||||
interface ApplicationService {
|
||||
// Use Case Methods
|
||||
executeUseCase(command: CommandType): Promise<ResultType>;
|
||||
|
||||
// Query Methods
|
||||
handleQuery(query: QueryType): Promise<QueryResultType>;
|
||||
|
||||
// Workflow Methods
|
||||
coordinateWorkflow(workflow: WorkflowType): Promise<void>;
|
||||
}
|
||||
|
||||
// Command/Query Types
|
||||
interface CommandType {
|
||||
// Command structure
|
||||
}
|
||||
|
||||
interface QueryType {
|
||||
// Query structure
|
||||
}
|
||||
```
|
||||
|
||||
##### Dependencies
|
||||
- **Domain Dependencies:** [Domain services and repositories]
|
||||
- **Infrastructure Dependencies:** [Data access and external services]
|
||||
- **Cross-Cutting Dependencies:** [Logging, monitoring, configuration]
|
||||
|
||||
##### Data Flow
|
||||
- **Command Processing:** [How commands are processed]
|
||||
- **Query Processing:** [How queries are handled]
|
||||
- **Event Publishing:** [Events published by this component]
|
||||
- **Data Persistence:** [Data storage and retrieval patterns]
|
||||
|
||||
##### Error Handling
|
||||
- **Business Rule Violations:** [How business rule violations are handled]
|
||||
- **Infrastructure Failures:** [How infrastructure failures are managed]
|
||||
- **Transaction Management:** [Transaction handling and rollback strategies]
|
||||
- **Compensation Patterns:** [Compensation actions for failures]
|
||||
|
||||
##### Quality Attributes
|
||||
- **Performance:** [Performance requirements and optimization strategies]
|
||||
- **Security:** [Security requirements and implementation approach]
|
||||
- **Reliability:** [Reliability requirements and fault tolerance]
|
||||
- **Maintainability:** [Code organization and maintenance considerations]
|
||||
|
||||
##### Testing Strategy
|
||||
- **Unit Testing:** [Unit testing approach and coverage]
|
||||
- **Integration Testing:** [Integration testing strategy]
|
||||
- **Business Logic Testing:** [Business rule testing approach]
|
||||
- **End-to-End Testing:** [End-to-end testing requirements]
|
||||
|
||||
##### Implementation Guidelines
|
||||
- **Design Patterns:** [CQRS, Mediator, Unit of Work, etc.]
|
||||
- **Technology Stack:** [Recommended technologies and frameworks]
|
||||
- **Code Organization:** [Code structure and organization guidelines]
|
||||
- **Transaction Management:** [Transaction handling guidelines]
|
||||
|
||||
### Domain Layer Components
|
||||
|
||||
#### Component 3: [Component Name]
|
||||
**Layer:** Domain
|
||||
**Domain:** [Domain Context]
|
||||
**Responsibility:** [Primary responsibility and purpose]
|
||||
|
||||
##### Architecture
|
||||
- **Component Type:** [Domain Service/Entity/Value Object/Aggregate]
|
||||
- **Deployment Unit:** [How this component is deployed]
|
||||
- **Scalability:** [Horizontal/Vertical scaling characteristics]
|
||||
- **State Management:** [State handling and persistence approach]
|
||||
|
||||
##### Responsibilities
|
||||
- **Primary Responsibility:** [Main function of this component]
|
||||
- **Business Rules:** [Core business rules and invariants]
|
||||
- **Domain Logic:** [Domain-specific business logic]
|
||||
- **Data Integrity:** [Data consistency and validation responsibilities]
|
||||
|
||||
##### Interface Definition
|
||||
```typescript
|
||||
// Domain Service Interface
|
||||
interface DomainService {
|
||||
// Business Logic Methods
|
||||
performBusinessOperation(params: BusinessParams): BusinessResult;
|
||||
|
||||
// Validation Methods
|
||||
validateBusinessRules(entity: EntityType): ValidationResult;
|
||||
|
||||
// Calculation Methods
|
||||
calculateBusinessValue(input: InputType): CalculationResult;
|
||||
}
|
||||
|
||||
// Domain Types
|
||||
interface BusinessParams {
|
||||
// Business parameter structure
|
||||
}
|
||||
|
||||
interface BusinessResult {
|
||||
// Business result structure
|
||||
}
|
||||
```
|
||||
|
||||
##### Dependencies
|
||||
- **Domain Dependencies:** [Other domain services and entities]
|
||||
- **Infrastructure Dependencies:** [Repository interfaces]
|
||||
- **External Dependencies:** [External domain services if any]
|
||||
|
||||
##### Data Flow
|
||||
- **Entity Lifecycle:** [How entities are created, modified, and destroyed]
|
||||
- **Business Events:** [Domain events generated by this component]
|
||||
- **Validation Flow:** [How business rules are validated]
|
||||
- **State Transitions:** [Valid state transitions and constraints]
|
||||
|
||||
##### Error Handling
|
||||
- **Business Rule Violations:** [How business invariants are enforced]
|
||||
- **Domain Exceptions:** [Domain-specific exceptions and handling]
|
||||
- **Validation Failures:** [How validation failures are communicated]
|
||||
- **Consistency Enforcement:** [How data consistency is maintained]
|
||||
|
||||
##### Quality Attributes
|
||||
- **Performance:** [Performance requirements and optimization strategies]
|
||||
- **Security:** [Security requirements and implementation approach]
|
||||
- **Reliability:** [Reliability requirements and fault tolerance]
|
||||
- **Maintainability:** [Code organization and maintenance considerations]
|
||||
|
||||
##### Testing Strategy
|
||||
- **Unit Testing:** [Unit testing approach and coverage]
|
||||
- **Domain Testing:** [Domain logic testing strategy]
|
||||
- **Business Rule Testing:** [Business rule validation testing]
|
||||
- **Integration Testing:** [Integration testing with repositories]
|
||||
|
||||
##### Implementation Guidelines
|
||||
- **Design Patterns:** [Domain-Driven Design patterns]
|
||||
- **Technology Stack:** [Recommended technologies and frameworks]
|
||||
- **Code Organization:** [Code structure and organization guidelines]
|
||||
- **Business Rule Implementation:** [How to implement business rules]
|
||||
|
||||
### Infrastructure Layer Components
|
||||
|
||||
#### Component 4: [Component Name]
|
||||
**Layer:** Infrastructure
|
||||
**Domain:** [Domain Context]
|
||||
**Responsibility:** [Primary responsibility and purpose]
|
||||
|
||||
##### Architecture
|
||||
- **Component Type:** [Repository/External Service Client/Message Handler/Data Access]
|
||||
- **Deployment Unit:** [How this component is deployed]
|
||||
- **Scalability:** [Horizontal/Vertical scaling characteristics]
|
||||
- **State Management:** [Connection and resource management approach]
|
||||
|
||||
##### Responsibilities
|
||||
- **Primary Responsibility:** [Main function of this component]
|
||||
- **Data Access:** [Data persistence and retrieval responsibilities]
|
||||
- **External Integration:** [External service integration responsibilities]
|
||||
- **Technical Concerns:** [Cross-cutting technical concerns]
|
||||
|
||||
##### Interface Definition
|
||||
```typescript
|
||||
// Repository Interface
|
||||
interface Repository<T> {
|
||||
// CRUD Operations
|
||||
create(entity: T): Promise<T>;
|
||||
findById(id: string): Promise<T | null>;
|
||||
update(entity: T): Promise<T>;
|
||||
delete(id: string): Promise<void>;
|
||||
|
||||
// Query Operations
|
||||
findBy(criteria: QueryCriteria): Promise<T[]>;
|
||||
exists(criteria: QueryCriteria): Promise<boolean>;
|
||||
}
|
||||
|
||||
// External Service Interface
|
||||
interface ExternalServiceClient {
|
||||
// Service Operations
|
||||
callService(request: ServiceRequest): Promise<ServiceResponse>;
|
||||
|
||||
// Health Check
|
||||
healthCheck(): Promise<HealthStatus>;
|
||||
}
|
||||
```
|
||||
|
||||
##### Dependencies
|
||||
- **Database Dependencies:** [Database systems and drivers]
|
||||
- **External Service Dependencies:** [Third-party services and APIs]
|
||||
- **Infrastructure Dependencies:** [Message queues, caches, etc.]
|
||||
- **Configuration Dependencies:** [Configuration and secrets management]
|
||||
|
||||
##### Data Flow
|
||||
- **Data Access Patterns:** [How data is accessed and manipulated]
|
||||
- **Connection Management:** [Database connection and pooling]
|
||||
- **Error Handling:** [Database and service error handling]
|
||||
- **Performance Optimization:** [Caching and optimization strategies]
|
||||
|
||||
##### Error Handling
|
||||
- **Database Errors:** [Database connection and query error handling]
|
||||
- **External Service Errors:** [External service failure handling]
|
||||
- **Network Errors:** [Network connectivity and timeout handling]
|
||||
- **Resource Errors:** [Resource exhaustion and cleanup]
|
||||
|
||||
##### Quality Attributes
|
||||
- **Performance:** [Performance requirements and optimization strategies]
|
||||
- **Security:** [Security requirements and implementation approach]
|
||||
- **Reliability:** [Reliability requirements and fault tolerance]
|
||||
- **Maintainability:** [Code organization and maintenance considerations]
|
||||
|
||||
##### Testing Strategy
|
||||
- **Unit Testing:** [Unit testing approach and coverage]
|
||||
- **Integration Testing:** [Integration testing strategy]
|
||||
- **Database Testing:** [Database testing approach]
|
||||
- **External Service Testing:** [Service integration testing]
|
||||
|
||||
##### Implementation Guidelines
|
||||
- **Design Patterns:** [Repository, Adapter, Circuit Breaker, etc.]
|
||||
- **Technology Stack:** [Recommended technologies and frameworks]
|
||||
- **Code Organization:** [Code structure and organization guidelines]
|
||||
- **Resource Management:** [Connection and resource management]
|
||||
|
||||
---
|
||||
|
||||
## Interface Definitions
|
||||
|
||||
### API Contracts
|
||||
|
||||
#### REST API Specification
|
||||
```yaml
|
||||
# OpenAPI 3.0 Specification
|
||||
openapi: 3.0.0
|
||||
info:
|
||||
title: Component API
|
||||
version: 1.0.0
|
||||
description: API specification for component interfaces
|
||||
|
||||
paths:
|
||||
/api/resource:
|
||||
get:
|
||||
summary: Get resource
|
||||
parameters:
|
||||
- name: id
|
||||
in: query
|
||||
required: true
|
||||
schema:
|
||||
type: string
|
||||
responses:
|
||||
'200':
|
||||
description: Resource found
|
||||
content:
|
||||
application/json:
|
||||
schema:
|
||||
$ref: '#/components/schemas/Resource'
|
||||
'404':
|
||||
description: Resource not found
|
||||
post:
|
||||
summary: Create resource
|
||||
requestBody:
|
||||
required: true
|
||||
content:
|
||||
application/json:
|
||||
schema:
|
||||
$ref: '#/components/schemas/CreateResourceRequest'
|
||||
responses:
|
||||
'201':
|
||||
description: Resource created
|
||||
content:
|
||||
application/json:
|
||||
schema:
|
||||
$ref: '#/components/schemas/Resource'
|
||||
|
||||
components:
|
||||
schemas:
|
||||
Resource:
|
||||
type: object
|
||||
properties:
|
||||
id:
|
||||
type: string
|
||||
name:
|
||||
type: string
|
||||
status:
|
||||
type: string
|
||||
enum: [active, inactive]
|
||||
|
||||
CreateResourceRequest:
|
||||
type: object
|
||||
required:
|
||||
- name
|
||||
properties:
|
||||
name:
|
||||
type: string
|
||||
description:
|
||||
type: string
|
||||
```
|
||||
|
||||
#### Message Contracts
|
||||
```typescript
|
||||
// Event Message Contracts
|
||||
interface DomainEvent {
|
||||
eventId: string;
|
||||
eventType: string;
|
||||
aggregateId: string;
|
||||
aggregateType: string;
|
||||
eventData: any;
|
||||
timestamp: Date;
|
||||
version: number;
|
||||
}
|
||||
|
||||
// Command Message Contracts
|
||||
interface Command {
|
||||
commandId: string;
|
||||
commandType: string;
|
||||
payload: any;
|
||||
timestamp: Date;
|
||||
userId: string;
|
||||
}
|
||||
|
||||
// Query Message Contracts
|
||||
interface Query {
|
||||
queryId: string;
|
||||
queryType: string;
|
||||
parameters: any;
|
||||
timestamp: Date;
|
||||
userId: string;
|
||||
}
|
||||
```
|
||||
|
||||
### Integration Protocols
|
||||
|
||||
#### Synchronous Communication
|
||||
- **HTTP/REST:** [RESTful API patterns and conventions]
|
||||
- **gRPC:** [gRPC service definitions and protocols]
|
||||
- **GraphQL:** [GraphQL schema and query patterns]
|
||||
|
||||
#### Asynchronous Communication
|
||||
- **Message Queues:** [Message queue patterns and protocols]
|
||||
- **Event Streams:** [Event streaming patterns and schemas]
|
||||
- **Publish-Subscribe:** [Pub/sub patterns and topic structures]
|
||||
|
||||
#### Data Formats
|
||||
- **JSON:** [JSON schema definitions and conventions]
|
||||
- **Protocol Buffers:** [Protobuf definitions and usage]
|
||||
- **Avro:** [Avro schema definitions and evolution]
|
||||
|
||||
---
|
||||
|
||||
## Implementation Guidelines
|
||||
|
||||
### Development Patterns
|
||||
|
||||
#### Design Patterns by Layer
|
||||
##### Presentation Layer
|
||||
- **MVC Pattern:** [Model-View-Controller implementation]
|
||||
- **API Gateway Pattern:** [Centralized API management]
|
||||
- **Backend for Frontend (BFF):** [Client-specific backends]
|
||||
|
||||
##### Application Layer
|
||||
- **Command Query Responsibility Segregation (CQRS):** [Separate read/write operations]
|
||||
- **Mediator Pattern:** [Request/response handling]
|
||||
- **Unit of Work Pattern:** [Transaction management]
|
||||
|
||||
##### Domain Layer
|
||||
- **Domain-Driven Design (DDD):** [Domain modeling patterns]
|
||||
- **Repository Pattern:** [Data access abstraction]
|
||||
- **Factory Pattern:** [Complex object creation]
|
||||
- **Strategy Pattern:** [Business rule variations]
|
||||
|
||||
##### Infrastructure Layer
|
||||
- **Repository Pattern:** [Data access implementation]
|
||||
- **Adapter Pattern:** [External service integration]
|
||||
- **Circuit Breaker Pattern:** [Fault tolerance]
|
||||
- **Decorator Pattern:** [Cross-cutting concerns]
|
||||
|
||||
### Technology Guidelines
|
||||
|
||||
#### Programming Languages
|
||||
- **Primary Language:** [Main programming language and rationale]
|
||||
- **Secondary Languages:** [Additional languages for specific components]
|
||||
- **Language Standards:** [Coding standards and conventions]
|
||||
|
||||
#### Frameworks and Libraries
|
||||
- **Web Framework:** [Web framework selection and configuration]
|
||||
- **ORM Framework:** [Object-relational mapping framework]
|
||||
- **Testing Framework:** [Testing framework and tools]
|
||||
- **Logging Framework:** [Logging and monitoring framework]
|
||||
|
||||
#### Development Tools
|
||||
- **IDE Configuration:** [Development environment setup]
|
||||
- **Build Tools:** [Build automation and dependency management]
|
||||
- **Code Quality Tools:** [Static analysis and quality tools]
|
||||
- **Version Control:** [Version control practices and branching]
|
||||
|
||||
### Quality Assurance
|
||||
|
||||
#### Testing Strategy
|
||||
- **Unit Testing:** [Component-level testing approach]
|
||||
- **Integration Testing:** [Component integration testing]
|
||||
- **Contract Testing:** [API contract testing]
|
||||
- **End-to-End Testing:** [System-level testing]
|
||||
|
||||
#### Code Quality
|
||||
- **Code Reviews:** [Code review process and standards]
|
||||
- **Static Analysis:** [Static code analysis tools and rules]
|
||||
- **Documentation:** [Code documentation standards]
|
||||
- **Refactoring:** [Refactoring guidelines and practices]
|
||||
|
||||
#### Performance
|
||||
- **Performance Testing:** [Performance testing approach]
|
||||
- **Profiling:** [Performance profiling and optimization]
|
||||
- **Monitoring:** [Runtime monitoring and alerting]
|
||||
- **Optimization:** [Performance optimization strategies]
|
||||
|
||||
---
|
||||
|
||||
## Integration Patterns
|
||||
|
||||
### Component Communication
|
||||
|
||||
#### Synchronous Patterns
|
||||
- **Direct Method Calls:** [In-process component communication]
|
||||
- **HTTP APIs:** [RESTful API communication]
|
||||
- **RPC Calls:** [Remote procedure call patterns]
|
||||
|
||||
#### Asynchronous Patterns
|
||||
- **Message Queues:** [Queue-based communication]
|
||||
- **Event Streams:** [Event-driven communication]
|
||||
- **Publish-Subscribe:** [Pub/sub communication patterns]
|
||||
|
||||
#### Hybrid Patterns
|
||||
- **Request-Response with Events:** [Combined synchronous/asynchronous]
|
||||
- **Saga Pattern:** [Distributed transaction coordination]
|
||||
- **Event Sourcing:** [Event-based state management]
|
||||
|
||||
### Data Consistency
|
||||
|
||||
#### Consistency Patterns
|
||||
- **Strong Consistency:** [ACID transaction patterns]
|
||||
- **Eventual Consistency:** [BASE transaction patterns]
|
||||
- **Causal Consistency:** [Causal ordering patterns]
|
||||
|
||||
#### Conflict Resolution
|
||||
- **Last Write Wins:** [Conflict resolution strategy]
|
||||
- **Merge Strategies:** [Data merge and conflict resolution]
|
||||
- **Compensating Actions:** [Compensation patterns for failures]
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
|
||||
### Component Implementation
|
||||
1. **Development Planning:** [Plan component development order and dependencies]
|
||||
2. **Team Assignment:** [Assign development teams to components]
|
||||
3. **Interface Implementation:** [Implement component interfaces first]
|
||||
4. **Component Development:** [Develop component implementations]
|
||||
|
||||
### Integration Planning
|
||||
1. **Integration Architecture:** [Design component integration approach]
|
||||
2. **Communication Protocols:** [Implement communication mechanisms]
|
||||
3. **Data Flow Testing:** [Test data flow between components]
|
||||
4. **End-to-End Testing:** [Test complete system integration]
|
||||
|
||||
### Quality Assurance
|
||||
1. **Testing Implementation:** [Implement testing strategy]
|
||||
2. **Code Quality Setup:** [Set up code quality tools]
|
||||
3. **Performance Testing:** [Implement performance testing]
|
||||
4. **Security Testing:** [Implement security testing]
|
||||
|
||||
---
|
||||
|
||||
## Appendices
|
||||
|
||||
### A. Component Mapping Matrix
|
||||
[Matrix showing component relationships and dependencies]
|
||||
|
||||
### B. Interface Specifications
|
||||
[Detailed interface specifications for each component]
|
||||
|
||||
### C. Implementation Examples
|
||||
[Code examples and implementation patterns]
|
||||
|
||||
### D. Testing Examples
|
||||
[Testing examples and test case specifications]
|
||||
|
||||
### E. Performance Considerations
|
||||
[Performance analysis and optimization guidelines]
|
||||
```
|
||||
|
||||
### Updated Session State Structure
|
||||
```json
|
||||
{
|
||||
"index": 1,
|
||||
"name": "architecture-session-name",
|
||||
"type": "architecture",
|
||||
"status": "component_design_complete",
|
||||
"created": "ISO datetime",
|
||||
"lastUpdated": "ISO datetime",
|
||||
"currentStep": "component_design",
|
||||
"completedSteps": ["architecture_framework_creation", "domain_analysis", "layer_design", "component_design"],
|
||||
"nextAction": "Ready for integration architecture or summary generation",
|
||||
"sourceType": "prd",
|
||||
"sourceName": "prd-session-name",
|
||||
"architectureScope": "system-wide",
|
||||
"architectureStyle": "layered",
|
||||
"architectureResults": {
|
||||
"domains": 3,
|
||||
"layers": 4,
|
||||
"components": 12,
|
||||
"componentSpecs": 12,
|
||||
"interfaces": 24,
|
||||
"patterns": 8,
|
||||
"qualityAttributes": 5,
|
||||
"decisions": 6,
|
||||
"createdDate": "ISO datetime",
|
||||
"componentDesignDate": "ISO datetime"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
### ✅ DO: Interface-First Design
|
||||
- **Define clear interfaces** before implementing component internals
|
||||
- **Use contract-first approach** for API and message design
|
||||
- **Maintain interface stability** and versioning strategies
|
||||
- **Document interface contracts** comprehensively
|
||||
|
||||
**Why:** Interface-first design enables parallel development, reduces integration issues, and improves system maintainability.
|
||||
|
||||
### ✅ DO: Responsibility-Driven Design
|
||||
- **Assign single responsibility** to each component
|
||||
- **Define clear boundaries** between component responsibilities
|
||||
- **Minimize coupling** between components
|
||||
- **Maximize cohesion** within components
|
||||
|
||||
**Why:** Responsibility-driven design creates maintainable, testable, and evolvable components.
|
||||
|
||||
### ✅ DO: Quality-Driven Implementation
|
||||
- **Define quality requirements** for each component
|
||||
- **Implement appropriate patterns** for quality attributes
|
||||
- **Plan for testing** and quality assurance
|
||||
- **Consider operational requirements** from the start
|
||||
|
||||
**Why:** Quality-driven implementation ensures that components meet production requirements and performance expectations.
|
||||
|
||||
### ❌ DON'T: Premature Implementation Details
|
||||
- **Don't specify implementation details** too early in the design process
|
||||
- **Don't couple components** to specific technologies unnecessarily
|
||||
- **Don't ignore testing** and quality requirements
|
||||
- **Don't forget operational concerns** like monitoring and deployment
|
||||
|
||||
**Why:** Premature implementation details can constrain development flexibility and complicate system evolution.
|
||||
|
||||
### ❌ DON'T: Monolithic Component Design
|
||||
- **Don't create components** that are too large or complex
|
||||
- **Don't mix concerns** within a single component
|
||||
- **Don't ignore separation** of business and technical concerns
|
||||
- **Don't create tight coupling** between unrelated components
|
||||
|
||||
**Why:** Monolithic component design reduces maintainability, testability, and team productivity.
|
||||
|
||||
## Output
|
||||
- **Format:** Detailed component specifications with interfaces and guidelines
|
||||
- **Location:** `.taskmaster/docs/design/architecture/[index]-[architecture_session_name]/`
|
||||
- **Primary Files:**
|
||||
- `component-design_[architecture_session_name].md` - Main component design document
|
||||
- `_session-state.json` - Updated session state
|
||||
|
||||
## Example Usage
|
||||
- **Design all components from architecture:**
|
||||
`/design/system-architecture/2-design-components --name="enterprise-expansion"`
|
||||
- **Design specific components:**
|
||||
`/design/system-architecture/2-design-components --name="enterprise-expansion" --components="UserService,PaymentService"`
|
||||
- **Design by architecture index:**
|
||||
`/design/system-architecture/2-design-components --name="1"`
|
||||
File diff suppressed because it is too large
Load Diff
@ -0,0 +1,508 @@
|
||||
---
|
||||
allowed-tools: [Read, Write, Glob, TodoWrite]
|
||||
description: Generates a comprehensive architecture summary that consolidates all system architecture components into a unified documentation package.
|
||||
---
|
||||
|
||||
# Generate Architecture Summary
|
||||
|
||||
## Context
|
||||
- **User Request:** $ARGUMENTS
|
||||
- **Architecture Session:** Identified by `--name` argument (architecture session name or index).
|
||||
- **Source Documents:** All architecture documents from the specified architecture session directory.
|
||||
- **Output Format:** Optional `--format` argument (markdown, pdf, html, confluence).
|
||||
- **Summary Scope:** Optional `--scope` argument to focus on specific architecture areas.
|
||||
- **Design Directory:** `.taskmaster/docs/design/architecture/`
|
||||
|
||||
## Goal
|
||||
To create a comprehensive architecture summary that consolidates the architecture framework, component design, and integration architecture into a unified, stakeholder-ready documentation package that provides clear guidance for development teams and technical decision-makers.
|
||||
|
||||
## Process
|
||||
|
||||
1. **Identify Source Architecture Session:**
|
||||
- Use the `--name` argument to locate the correct architecture session directory (e.g., `.taskmaster/docs/design/architecture/001-enterprise-expansion/`).
|
||||
- Find all architecture documents within the session directory:
|
||||
- `architecture-framework_*.md`
|
||||
- `component-design_*.md`
|
||||
- `integration-architecture_*.md`
|
||||
- `_session-state.json`
|
||||
|
||||
2. **Extract Architecture Content:**
|
||||
- **Architecture Framework:** High-level architecture vision, domain boundaries, and layer design
|
||||
- **Component Design:** Detailed component specifications, interfaces, and implementation guidelines
|
||||
- **Integration Architecture:** Communication protocols, data flow, and service integration patterns
|
||||
- **Session Metadata:** Architecture session status, metrics, and completion details
|
||||
|
||||
3. **Process Summary Scope (if specified):**
|
||||
- If `--scope` argument is provided, focus on specific architecture areas
|
||||
- Supported scopes: `executive`, `technical`, `implementation`, `operations`
|
||||
- Parse and validate scope parameters
|
||||
|
||||
4. **Analyze Architecture Completeness:**
|
||||
- **Completeness Assessment:** Verify all architecture components are defined
|
||||
- **Consistency Analysis:** Check for consistency across architecture documents
|
||||
- **Gap Analysis:** Identify missing components or incomplete specifications
|
||||
- **Quality Assessment:** Evaluate architecture quality and adherence to best practices
|
||||
|
||||
5. **Generate Executive Summary:**
|
||||
- **Architecture Overview:** High-level architecture vision and business alignment
|
||||
- **Key Decisions:** Critical architectural decisions and their rationale
|
||||
- **Risk Assessment:** Architecture risks and mitigation strategies
|
||||
- **Implementation Roadmap:** Recommended implementation approach and timeline
|
||||
|
||||
6. **Create Technical Summary:**
|
||||
- **System Architecture:** Consolidated view of system structure and components
|
||||
- **Integration Patterns:** Summary of communication and integration approaches
|
||||
- **Quality Attributes:** Architecture support for performance, security, and scalability
|
||||
- **Technology Stack:** Recommended technologies and frameworks
|
||||
|
||||
7. **Generate Implementation Guide:**
|
||||
- **Development Approach:** Recommended development methodology and team organization
|
||||
- **Component Implementation:** Priority and sequence for component development
|
||||
- **Integration Strategy:** Approach for component integration and testing
|
||||
- **Quality Assurance:** Testing strategy and quality gates
|
||||
|
||||
8. **Create Operations Guide:**
|
||||
- **Deployment Architecture:** Deployment patterns and infrastructure requirements
|
||||
- **Monitoring Strategy:** Observability and monitoring approach
|
||||
- **Maintenance Guidelines:** Architecture evolution and maintenance procedures
|
||||
- **Troubleshooting Guide:** Common issues and resolution approaches
|
||||
|
||||
9. **Generate Architecture Summary Document:**
|
||||
- Create the architecture summary document named `architecture-summary_[architecture_session_name].md`.
|
||||
- Structure content according to the architecture summary template.
|
||||
- Include:
|
||||
- **Executive Summary:** High-level overview for stakeholders
|
||||
- **Technical Architecture:** Detailed technical specifications
|
||||
- **Implementation Guide:** Development and integration guidance
|
||||
- **Operations Guide:** Deployment and maintenance procedures
|
||||
- **Appendices:** Supporting documentation and references
|
||||
|
||||
10. **Create Supporting Documentation:**
|
||||
- Generate architecture diagrams and visual representations
|
||||
- Create component dependency matrices and relationship diagrams
|
||||
- Generate API documentation and interface specifications
|
||||
- Create implementation checklists and quality gates
|
||||
|
||||
11. **Process Output Format (if specified):**
|
||||
- If `--format` argument is provided, generate additional formats
|
||||
- Supported formats: `pdf`, `html`, `confluence`
|
||||
- Maintain consistent content across all formats
|
||||
|
||||
12. **Update Architecture Session State:**
|
||||
- Update the existing `_session-state.json` file in the architecture session directory.
|
||||
- Set status to `architecture_complete` and update completion metrics.
|
||||
- Add architecture summary generation status and results.
|
||||
|
||||
13. **Notify User with Architecture Summary:**
|
||||
- Inform the user that the architecture summary has been successfully generated.
|
||||
- Provide file paths and key architectural highlights.
|
||||
- **Suggest logical next steps based on architecture completion:**
|
||||
- "Your architecture summary is complete. Consider beginning UI/UX design using `/design/ui-ux/1-design-system --name=[session_name]`"
|
||||
- "Review the architecture summary with your stakeholders for approval and feedback."
|
||||
- "Use the implementation guide to create detailed development tasks and sprint planning."
|
||||
|
||||
## Templates & Structures
|
||||
|
||||
### Architecture Summary Template
|
||||
```markdown
|
||||
# Architecture Summary: [Architecture Session Name]
|
||||
|
||||
**Created:** [Date]
|
||||
**Architecture Session:** [Architecture Session Name]
|
||||
**Architecture Style:** [Layered/Microservices/Event-Driven/Hybrid]
|
||||
**Completeness:** [Complete/Partial]
|
||||
**Review Status:** [Pending/Approved/Needs Changes]
|
||||
**Last Updated:** [Date]
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
### Business Context
|
||||
- **Project Vision:** [High-level project vision and business objectives]
|
||||
- **Business Drivers:** [Key business requirements driving this architecture]
|
||||
- **Success Criteria:** [How architectural success will be measured]
|
||||
- **Stakeholder Alignment:** [Key stakeholders and their concerns addressed]
|
||||
|
||||
### Architecture Overview
|
||||
- **Architecture Style:** [Primary architectural style and rationale]
|
||||
- **System Scale:** [Expected system scale and capacity requirements]
|
||||
- **Key Components:** [Number and types of major system components]
|
||||
- **Integration Complexity:** [Assessment of integration complexity and challenges]
|
||||
|
||||
### Key Architectural Decisions
|
||||
#### Decision 1: [Decision Topic]
|
||||
- **Decision:** [What was decided]
|
||||
- **Rationale:** [Why this decision was made]
|
||||
- **Impact:** [Business and technical impact]
|
||||
- **Risks:** [Associated risks and mitigation strategies]
|
||||
|
||||
#### Decision 2: [Decision Topic]
|
||||
- **Decision:** [What was decided]
|
||||
- **Rationale:** [Why this decision was made]
|
||||
- **Impact:** [Business and technical impact]
|
||||
- **Risks:** [Associated risks and mitigation strategies]
|
||||
|
||||
### Risk Assessment
|
||||
- **High Risk:** [Critical risks requiring immediate attention]
|
||||
- **Medium Risk:** [Important risks requiring monitoring]
|
||||
- **Low Risk:** [Minor risks with acceptable impact]
|
||||
- **Risk Mitigation:** [Overall risk mitigation strategy]
|
||||
|
||||
### Implementation Roadmap
|
||||
- **Phase 1:** [Initial implementation phase and timeline]
|
||||
- **Phase 2:** [Subsequent phases and milestones]
|
||||
- **Critical Path:** [Dependencies and critical path items]
|
||||
- **Resource Requirements:** [Team size, skills, and infrastructure needs]
|
||||
|
||||
---
|
||||
|
||||
## Technical Architecture
|
||||
|
||||
### System Architecture Overview
|
||||
- **Domain Architecture:** [Number of domains and their relationships]
|
||||
- **Layer Architecture:** [Architectural layers and their responsibilities]
|
||||
- **Component Architecture:** [Major components and their interactions]
|
||||
- **Integration Architecture:** [Communication patterns and integration approaches]
|
||||
|
||||
### Domain Architecture
|
||||
#### Domain 1: [Domain Name]
|
||||
- **Purpose:** [What this domain represents in the business]
|
||||
- **Key Components:** [Major components within this domain]
|
||||
- **Boundaries:** [Clear domain boundaries and responsibilities]
|
||||
- **Integration Points:** [How this domain integrates with others]
|
||||
|
||||
#### Domain 2: [Domain Name]
|
||||
- **Purpose:** [What this domain represents in the business]
|
||||
- **Key Components:** [Major components within this domain]
|
||||
- **Boundaries:** [Clear domain boundaries and responsibilities]
|
||||
- **Integration Points:** [How this domain integrates with others]
|
||||
|
||||
### Component Architecture
|
||||
#### Component Summary
|
||||
- **Total Components:** [Number of components in the system]
|
||||
- **Layer Distribution:** [Components by architectural layer]
|
||||
- **Component Types:** [Distribution of component types]
|
||||
- **Integration Complexity:** [Assessment of component integration]
|
||||
|
||||
#### Key Components
|
||||
##### Component 1: [Component Name]
|
||||
- **Layer:** [Architectural layer]
|
||||
- **Purpose:** [Primary responsibility]
|
||||
- **Interfaces:** [Key interfaces and contracts]
|
||||
- **Dependencies:** [Major dependencies]
|
||||
- **Technology:** [Recommended technology stack]
|
||||
|
||||
##### Component 2: [Component Name]
|
||||
- **Layer:** [Architectural layer]
|
||||
- **Purpose:** [Primary responsibility]
|
||||
- **Interfaces:** [Key interfaces and contracts]
|
||||
- **Dependencies:** [Major dependencies]
|
||||
- **Technology:** [Recommended technology stack]
|
||||
|
||||
### Integration Architecture
|
||||
#### Communication Patterns
|
||||
- **Synchronous:** [REST APIs, gRPC, direct calls]
|
||||
- **Asynchronous:** [Message queues, event streams, pub/sub]
|
||||
- **Data Integration:** [Database integration and data sharing]
|
||||
- **External Integration:** [Third-party service integration]
|
||||
|
||||
#### Integration Protocols
|
||||
- **API Standards:** [REST, GraphQL, gRPC specifications]
|
||||
- **Message Formats:** [JSON, Protocol Buffers, Avro schemas]
|
||||
- **Security Protocols:** [Authentication, authorization, encryption]
|
||||
- **Error Handling:** [Error handling and retry patterns]
|
||||
|
||||
### Quality Attributes
|
||||
- **Performance:** [Response time, throughput, resource usage targets]
|
||||
- **Scalability:** [Horizontal and vertical scaling approaches]
|
||||
- **Reliability:** [Fault tolerance and resilience patterns]
|
||||
- **Security:** [Security architecture and protection mechanisms]
|
||||
- **Maintainability:** [Code organization and evolution strategies]
|
||||
|
||||
### Technology Stack
|
||||
- **Programming Languages:** [Primary and secondary languages]
|
||||
- **Frameworks:** [Web, application, and infrastructure frameworks]
|
||||
- **Databases:** [Database technologies and data stores]
|
||||
- **Infrastructure:** [Cloud platforms, containers, orchestration]
|
||||
- **Tools:** [Development, testing, and operational tools]
|
||||
|
||||
---
|
||||
|
||||
## Implementation Guide
|
||||
|
||||
### Development Approach
|
||||
- **Methodology:** [Agile, iterative, or other development approach]
|
||||
- **Team Organization:** [Team structure and responsibilities]
|
||||
- **Development Standards:** [Coding standards and best practices]
|
||||
- **Quality Practices:** [Code review, testing, and quality assurance]
|
||||
|
||||
### Component Implementation Priority
|
||||
#### Phase 1: Foundation Components
|
||||
- **Priority Components:** [Most critical components to implement first]
|
||||
- **Implementation Order:** [Recommended sequence of implementation]
|
||||
- **Dependencies:** [Key dependencies and blocking factors]
|
||||
- **Timeline:** [Estimated implementation timeline]
|
||||
|
||||
#### Phase 2: Core Features
|
||||
- **Feature Components:** [Core business functionality components]
|
||||
- **Integration Points:** [Key integration points to establish]
|
||||
- **Testing Strategy:** [Testing approach for this phase]
|
||||
- **Risk Management:** [Phase-specific risks and mitigation]
|
||||
|
||||
#### Phase 3: Advanced Features
|
||||
- **Enhancement Components:** [Advanced features and optimizations]
|
||||
- **Performance Optimization:** [Performance tuning and optimization]
|
||||
- **Monitoring Integration:** [Observability and monitoring setup]
|
||||
- **Security Hardening:** [Security enhancements and hardening]
|
||||
|
||||
### Integration Strategy
|
||||
- **Integration Testing:** [Approach for testing component integration]
|
||||
- **Contract Testing:** [API contract testing and validation]
|
||||
- **End-to-End Testing:** [System-level testing strategy]
|
||||
- **Performance Testing:** [Performance and load testing approach]
|
||||
|
||||
### Quality Assurance
|
||||
- **Testing Framework:** [Testing tools and frameworks]
|
||||
- **Code Quality:** [Static analysis and code quality tools]
|
||||
- **Security Testing:** [Security testing and vulnerability scanning]
|
||||
- **Performance Monitoring:** [Performance monitoring and optimization]
|
||||
|
||||
### Development Environment
|
||||
- **Local Development:** [Local development setup and tools]
|
||||
- **CI/CD Pipeline:** [Continuous integration and deployment]
|
||||
- **Environment Management:** [Development, staging, and production environments]
|
||||
- **Configuration Management:** [Configuration and secrets management]
|
||||
|
||||
---
|
||||
|
||||
## Operations Guide
|
||||
|
||||
### Deployment Architecture
|
||||
- **Deployment Strategy:** [Blue-green, canary, rolling deployments]
|
||||
- **Infrastructure Requirements:** [Hardware, network, and storage requirements]
|
||||
- **Scalability Configuration:** [Auto-scaling and load balancing setup]
|
||||
- **Environment Management:** [Multiple environment configuration]
|
||||
|
||||
### Monitoring and Observability
|
||||
- **Metrics Collection:** [System and application metrics]
|
||||
- **Logging Strategy:** [Centralized logging and log management]
|
||||
- **Distributed Tracing:** [Request tracing and performance monitoring]
|
||||
- **Alerting:** [Alert rules and notification channels]
|
||||
|
||||
### Maintenance and Evolution
|
||||
- **Architecture Evolution:** [How architecture will evolve over time]
|
||||
- **Component Lifecycle:** [Component upgrade and retirement process]
|
||||
- **Technology Updates:** [Framework and library update strategy]
|
||||
- **Legacy Migration:** [Migration from legacy systems]
|
||||
|
||||
### Troubleshooting Guide
|
||||
- **Common Issues:** [Frequent problems and their solutions]
|
||||
- **Diagnostic Tools:** [Tools and techniques for problem diagnosis]
|
||||
- **Performance Troubleshooting:** [Performance issue investigation]
|
||||
- **Security Incident Response:** [Security incident handling procedures]
|
||||
|
||||
### Backup and Recovery
|
||||
- **Backup Strategy:** [Data backup and recovery procedures]
|
||||
- **Disaster Recovery:** [Disaster recovery planning and testing]
|
||||
- **Business Continuity:** [Business continuity planning]
|
||||
- **Recovery Testing:** [Regular recovery testing and validation]
|
||||
|
||||
---
|
||||
|
||||
## Architecture Validation
|
||||
|
||||
### Completeness Assessment
|
||||
- **Architecture Coverage:** [Percentage of requirements covered by architecture]
|
||||
- **Component Completeness:** [All required components defined]
|
||||
- **Integration Completeness:** [All integrations designed and documented]
|
||||
- **Quality Attribute Coverage:** [All quality requirements addressed]
|
||||
|
||||
### Consistency Analysis
|
||||
- **Cross-Document Consistency:** [Consistency between architecture documents]
|
||||
- **Interface Consistency:** [Consistent interface definitions]
|
||||
- **Pattern Consistency:** [Consistent use of architectural patterns]
|
||||
- **Naming Consistency:** [Consistent naming conventions]
|
||||
|
||||
### Gap Analysis
|
||||
- **Missing Components:** [Components not yet defined or designed]
|
||||
- **Incomplete Specifications:** [Specifications requiring additional detail]
|
||||
- **Unaddressed Requirements:** [Requirements not covered by architecture]
|
||||
- **Integration Gaps:** [Missing integration points or specifications]
|
||||
|
||||
### Quality Assessment
|
||||
- **Architecture Quality:** [Overall architecture quality assessment]
|
||||
- **Best Practices Adherence:** [Adherence to architectural best practices]
|
||||
- **Pattern Usage:** [Appropriate use of architectural patterns]
|
||||
- **Documentation Quality:** [Quality and completeness of documentation]
|
||||
|
||||
---
|
||||
|
||||
## Recommendations
|
||||
|
||||
### Immediate Actions
|
||||
1. **Architecture Review:** [Conduct formal architecture review with stakeholders]
|
||||
2. **Gap Resolution:** [Address identified gaps and incomplete specifications]
|
||||
3. **Stakeholder Approval:** [Obtain stakeholder approval for architecture]
|
||||
4. **Implementation Planning:** [Create detailed implementation plan]
|
||||
|
||||
### Implementation Priorities
|
||||
1. **Critical Path:** [Focus on critical path components first]
|
||||
2. **Risk Mitigation:** [Prioritize high-risk components for early validation]
|
||||
3. **Value Delivery:** [Prioritize components that deliver early business value]
|
||||
4. **Foundation First:** [Build foundational components before advanced features]
|
||||
|
||||
### Long-term Considerations
|
||||
1. **Architecture Evolution:** [Plan for architecture evolution and growth]
|
||||
2. **Technology Refresh:** [Consider technology refresh cycles]
|
||||
3. **Team Growth:** [Plan for team growth and knowledge transfer]
|
||||
4. **Market Changes:** [Adapt architecture to changing market conditions]
|
||||
|
||||
---
|
||||
|
||||
## Appendices
|
||||
|
||||
### A. Architecture Diagrams
|
||||
[Comprehensive architecture diagrams and visual representations]
|
||||
|
||||
### B. Component Dependency Matrix
|
||||
[Matrix showing component relationships and dependencies]
|
||||
|
||||
### C. API Specifications
|
||||
[Detailed API specifications and documentation]
|
||||
|
||||
### D. Implementation Checklists
|
||||
[Checklists for component implementation and integration]
|
||||
|
||||
### E. Quality Gates
|
||||
[Quality gates and acceptance criteria for architecture phases]
|
||||
|
||||
### F. Reference Architecture
|
||||
[Links to reference architectures and best practices]
|
||||
|
||||
### G. Glossary
|
||||
[Architectural terms and definitions]
|
||||
|
||||
---
|
||||
|
||||
## Document Control
|
||||
|
||||
### Version History
|
||||
- **Version 1.0:** [Initial architecture summary creation]
|
||||
- **Version 1.1:** [First review and updates]
|
||||
- **Version 1.2:** [Stakeholder feedback incorporation]
|
||||
|
||||
### Review and Approval
|
||||
- **Technical Review:** [Technical review status and comments]
|
||||
- **Stakeholder Review:** [Stakeholder review and approval status]
|
||||
- **Architecture Board:** [Architecture board review and approval]
|
||||
|
||||
### Distribution
|
||||
- **Primary Audience:** [Development teams, architects, technical leads]
|
||||
- **Secondary Audience:** [Product managers, project managers, stakeholders]
|
||||
- **Distribution Method:** [Document sharing and notification approach]
|
||||
|
||||
### Maintenance
|
||||
- **Update Frequency:** [Regular update schedule and triggers]
|
||||
- **Change Management:** [Process for architecture changes]
|
||||
- **Version Control:** [Document version control and management]
|
||||
```
|
||||
|
||||
### Updated Session State Structure
|
||||
```json
|
||||
{
|
||||
"index": 1,
|
||||
"name": "architecture-session-name",
|
||||
"type": "architecture",
|
||||
"status": "architecture_complete",
|
||||
"created": "ISO datetime",
|
||||
"lastUpdated": "ISO datetime",
|
||||
"currentStep": "architecture_summary",
|
||||
"completedSteps": ["architecture_framework_creation", "domain_analysis", "layer_design", "component_design", "integration_architecture", "architecture_summary"],
|
||||
"nextAction": "Ready for UI/UX design or implementation planning",
|
||||
"sourceType": "prd",
|
||||
"sourceName": "prd-session-name",
|
||||
"architectureScope": "system-wide",
|
||||
"architectureStyle": "layered",
|
||||
"architectureResults": {
|
||||
"domains": 3,
|
||||
"layers": 4,
|
||||
"components": 12,
|
||||
"componentSpecs": 12,
|
||||
"interfaces": 24,
|
||||
"integrationPatterns": 15,
|
||||
"apiSpecs": 8,
|
||||
"messageSchemas": 6,
|
||||
"patterns": 8,
|
||||
"qualityAttributes": 5,
|
||||
"decisions": 6,
|
||||
"completeness": 95,
|
||||
"consistency": 92,
|
||||
"quality": 88,
|
||||
"createdDate": "ISO datetime",
|
||||
"componentDesignDate": "ISO datetime",
|
||||
"integrationArchitectureDate": "ISO datetime",
|
||||
"architectureSummaryDate": "ISO datetime"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
### ✅ DO: Comprehensive Documentation
|
||||
- **Include all architecture components** in the summary for complete coverage
|
||||
- **Maintain consistency** across all architecture documents and references
|
||||
- **Use stakeholder-appropriate language** for different audience sections
|
||||
- **Provide actionable guidance** for implementation teams
|
||||
|
||||
**Why:** Comprehensive documentation ensures all stakeholders have the information they need to make informed decisions and take appropriate actions.
|
||||
|
||||
### ✅ DO: Multi-Audience Approach
|
||||
- **Create executive summaries** for business stakeholders and decision-makers
|
||||
- **Provide technical details** for architects and development teams
|
||||
- **Include implementation guidance** for project managers and team leads
|
||||
- **Offer operational procedures** for DevOps and operations teams
|
||||
|
||||
**Why:** Multi-audience approach ensures the architecture summary serves all stakeholders effectively and supports different decision-making needs.
|
||||
|
||||
### ✅ DO: Quality Assessment
|
||||
- **Assess architecture completeness** and identify gaps or missing components
|
||||
- **Evaluate consistency** across architecture documents and specifications
|
||||
- **Validate quality attributes** and ensure requirements are met
|
||||
- **Provide recommendations** for improvement and optimization
|
||||
|
||||
**Why:** Quality assessment ensures the architecture meets standards and provides a foundation for successful implementation.
|
||||
|
||||
### ❌ DON'T: Information Overload
|
||||
- **Don't include excessive technical details** in executive summaries
|
||||
- **Don't create monolithic documents** that are difficult to navigate
|
||||
- **Don't ignore stakeholder needs** when structuring content
|
||||
- **Don't forget to highlight key decisions** and their rationale
|
||||
|
||||
**Why:** Information overload reduces the effectiveness of the architecture summary and makes it harder for stakeholders to extract relevant information.
|
||||
|
||||
### ❌ DON'T: Inconsistent Information
|
||||
- **Don't allow inconsistencies** between architecture documents
|
||||
- **Don't use different terminologies** for the same concepts
|
||||
- **Don't omit important decisions** or their rationale
|
||||
- **Don't ignore gaps** or incomplete specifications
|
||||
|
||||
**Why:** Inconsistent information creates confusion and can lead to implementation problems and misaligned expectations.
|
||||
|
||||
## Output
|
||||
- **Format:** Comprehensive architecture summary with multiple stakeholder perspectives
|
||||
- **Location:** `.taskmaster/docs/design/architecture/[index]-[architecture_session_name]/`
|
||||
- **Primary Files:**
|
||||
- `architecture-summary_[architecture_session_name].md` - Main architecture summary document
|
||||
- `_session-state.json` - Updated session state with completion status
|
||||
- **Additional Formats:** PDF, HTML, Confluence (if requested)
|
||||
|
||||
## Example Usage
|
||||
- **Generate complete architecture summary:**
|
||||
`/design/system-architecture/4-generate-architecture-summary --name="enterprise-expansion"`
|
||||
- **Generate executive summary only:**
|
||||
`/design/system-architecture/4-generate-architecture-summary --name="enterprise-expansion" --scope="executive"`
|
||||
- **Generate with PDF output:**
|
||||
`/design/system-architecture/4-generate-architecture-summary --name="enterprise-expansion" --format="pdf"`
|
||||
- **Generate by architecture index:**
|
||||
`/design/system-architecture/4-generate-architecture-summary --name="1"`
|
||||
654
.claude/commands/index.canvas
Normal file
654
.claude/commands/index.canvas
Normal file
@ -0,0 +1,654 @@
|
||||
{
|
||||
"nodes": [
|
||||
{
|
||||
"type": "group",
|
||||
"id": "planning-group",
|
||||
"x": 0,
|
||||
"y": 0,
|
||||
"width": 2200,
|
||||
"height": 1200,
|
||||
"label": "Planning Commands"
|
||||
},
|
||||
{
|
||||
"type": "group",
|
||||
"id": "planning-mrd",
|
||||
"x": 50,
|
||||
"y": 50,
|
||||
"width": 900,
|
||||
"height": 500,
|
||||
"label": "1. MRD Process"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "mrd-1",
|
||||
"x": 100,
|
||||
"y": 100,
|
||||
"width": 400,
|
||||
"height": 200,
|
||||
"file": ".claude/commands/planning/1-mrd/1-start-session.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "mrd-2",
|
||||
"x": 520,
|
||||
"y": 100,
|
||||
"width": 400,
|
||||
"height": 200,
|
||||
"file": ".claude/commands/planning/1-mrd/2-analyze-research-data.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "mrd-3",
|
||||
"x": 100,
|
||||
"y": 320,
|
||||
"width": 400,
|
||||
"height": 200,
|
||||
"file": ".claude/commands/planning/1-mrd/3-generate-mrd-document.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "mrd-4",
|
||||
"x": 520,
|
||||
"y": 320,
|
||||
"width": 400,
|
||||
"height": 200,
|
||||
"file": ".claude/commands/planning/1-mrd/4-compare-mrd-versions.md"
|
||||
},
|
||||
{
|
||||
"type": "group",
|
||||
"id": "planning-brainstorm",
|
||||
"x": 1000,
|
||||
"y": 50,
|
||||
"width": 500,
|
||||
"height": 500,
|
||||
"label": "2. Brainstorm Process"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "brainstorm-1",
|
||||
"x": 1050,
|
||||
"y": 100,
|
||||
"width": 400,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/planning/2-brainstorm/1-start-brainstorm.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "brainstorm-2",
|
||||
"x": 1050,
|
||||
"y": 220,
|
||||
"width": 400,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/planning/2-brainstorm/2-analyze-ideas.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "brainstorm-3",
|
||||
"x": 1050,
|
||||
"y": 340,
|
||||
"width": 400,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/planning/2-brainstorm/3-generate-brainstorm-summary.md"
|
||||
},
|
||||
{
|
||||
"type": "group",
|
||||
"id": "planning-roadmap",
|
||||
"x": 1550,
|
||||
"y": 50,
|
||||
"width": 500,
|
||||
"height": 500,
|
||||
"label": "3. Roadmap Process"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "roadmap-1",
|
||||
"x": 1600,
|
||||
"y": 100,
|
||||
"width": 400,
|
||||
"height": 200,
|
||||
"file": ".claude/commands/planning/3-roadmap/1-create-from-mrd.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "roadmap-2",
|
||||
"x": 1600,
|
||||
"y": 320,
|
||||
"width": 400,
|
||||
"height": 200,
|
||||
"file": ".claude/commands/planning/3-roadmap/2-create-from-brainstorm.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "planning-create-prd",
|
||||
"x": 50,
|
||||
"y": 600,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/planning/create-prd.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "planning-create-prd-interactive",
|
||||
"x": 370,
|
||||
"y": 600,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/planning/create-prd-interactive.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "planning-parse-prd",
|
||||
"x": 690,
|
||||
"y": 600,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/planning/parse-prd.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "planning-create-app-design",
|
||||
"x": 50,
|
||||
"y": 720,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/planning/create-app-design.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "planning-update-app-design",
|
||||
"x": 370,
|
||||
"y": 720,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/planning/update-app-design.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "planning-create-tech-stack",
|
||||
"x": 690,
|
||||
"y": 720,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/planning/create-tech-stack.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "planning-update-tech-stack",
|
||||
"x": 1010,
|
||||
"y": 720,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/planning/update-tech-stack.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "planning-create-rule",
|
||||
"x": 50,
|
||||
"y": 840,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/planning/create-rule.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "planning-update-rule",
|
||||
"x": 370,
|
||||
"y": 840,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/planning/update-rule.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "planning-create-doc",
|
||||
"x": 690,
|
||||
"y": 840,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/planning/create-doc.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "planning-update-project-structure",
|
||||
"x": 1010,
|
||||
"y": 840,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/planning/update-project-structure.md"
|
||||
},
|
||||
{
|
||||
"type": "group",
|
||||
"id": "task-group",
|
||||
"x": 2300,
|
||||
"y": 0,
|
||||
"width": 1200,
|
||||
"height": 800,
|
||||
"label": "Task Management"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "task-spec",
|
||||
"x": 2350,
|
||||
"y": 50,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/task/spec.md",
|
||||
"color": "4"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "task-list",
|
||||
"x": 2350,
|
||||
"y": 170,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/task/list.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "task-show",
|
||||
"x": 2670,
|
||||
"y": 170,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/task/show.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "task-next",
|
||||
"x": 2990,
|
||||
"y": 170,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/task/next.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "task-add",
|
||||
"x": 2350,
|
||||
"y": 290,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/task/add.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "task-add-interactive",
|
||||
"x": 2670,
|
||||
"y": 290,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/task/add-interactive.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "task-update",
|
||||
"x": 2350,
|
||||
"y": 410,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/task/update-task.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "task-update-interactive",
|
||||
"x": 2670,
|
||||
"y": 410,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/task/update-task-interactive.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "task-expand",
|
||||
"x": 2350,
|
||||
"y": 530,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/task/expand.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "task-done",
|
||||
"x": 2670,
|
||||
"y": 530,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/task/done.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "task-move",
|
||||
"x": 2990,
|
||||
"y": 530,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/task/move.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "task-research",
|
||||
"x": 2350,
|
||||
"y": 650,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/task/research.md",
|
||||
"color": "5"
|
||||
},
|
||||
{
|
||||
"type": "group",
|
||||
"id": "research-group",
|
||||
"x": 3600,
|
||||
"y": 0,
|
||||
"width": 600,
|
||||
"height": 400,
|
||||
"label": "Research Commands"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "research-task",
|
||||
"x": 3650,
|
||||
"y": 50,
|
||||
"width": 500,
|
||||
"height": 80,
|
||||
"file": ".claude/commands/research/task.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "research-architecture",
|
||||
"x": 3650,
|
||||
"y": 150,
|
||||
"width": 500,
|
||||
"height": 80,
|
||||
"file": ".claude/commands/research/architecture.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "research-tech",
|
||||
"x": 3650,
|
||||
"y": 250,
|
||||
"width": 500,
|
||||
"height": 80,
|
||||
"file": ".claude/commands/research/tech.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "research-security",
|
||||
"x": 3650,
|
||||
"y": 350,
|
||||
"width": 500,
|
||||
"height": 80,
|
||||
"file": ".claude/commands/research/security.md"
|
||||
},
|
||||
{
|
||||
"type": "group",
|
||||
"id": "design-group",
|
||||
"x": 0,
|
||||
"y": 1300,
|
||||
"width": 1800,
|
||||
"height": 600,
|
||||
"label": "Design Commands"
|
||||
},
|
||||
{
|
||||
"type": "group",
|
||||
"id": "design-architecture",
|
||||
"x": 50,
|
||||
"y": 1350,
|
||||
"width": 1700,
|
||||
"height": 500,
|
||||
"label": "System Architecture"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "arch-1",
|
||||
"x": 100,
|
||||
"y": 1400,
|
||||
"width": 380,
|
||||
"height": 150,
|
||||
"file": ".claude/commands/design/1-system-architecture/1-create-architecture-framework.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "arch-2",
|
||||
"x": 500,
|
||||
"y": 1400,
|
||||
"width": 380,
|
||||
"height": 150,
|
||||
"file": ".claude/commands/design/1-system-architecture/2-design-components.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "arch-3",
|
||||
"x": 900,
|
||||
"y": 1400,
|
||||
"width": 380,
|
||||
"height": 150,
|
||||
"file": ".claude/commands/design/1-system-architecture/3-integration-architecture.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "arch-4",
|
||||
"x": 1300,
|
||||
"y": 1400,
|
||||
"width": 380,
|
||||
"height": 150,
|
||||
"file": ".claude/commands/design/1-system-architecture/4-generate-architecture-summary.md"
|
||||
},
|
||||
{
|
||||
"type": "group",
|
||||
"id": "misc-group",
|
||||
"x": 1900,
|
||||
"y": 1300,
|
||||
"width": 700,
|
||||
"height": 400,
|
||||
"label": "Misc Commands"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "snippet-create",
|
||||
"x": 1950,
|
||||
"y": 1350,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/snippets/create-snippet.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "canvas-create",
|
||||
"x": 2270,
|
||||
"y": 1350,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/canvas/create_from_dir.md"
|
||||
},
|
||||
{
|
||||
"type": "file",
|
||||
"id": "debug",
|
||||
"x": 1950,
|
||||
"y": 1470,
|
||||
"width": 300,
|
||||
"height": 100,
|
||||
"file": ".claude/commands/debug.md",
|
||||
"color": "1"
|
||||
}
|
||||
],
|
||||
"edges": [
|
||||
{
|
||||
"id": "mrd-flow-1",
|
||||
"fromNode": "mrd-1",
|
||||
"fromSide": "right",
|
||||
"toNode": "mrd-2",
|
||||
"toSide": "left",
|
||||
"toEnd": "arrow",
|
||||
"label": "next"
|
||||
},
|
||||
{
|
||||
"id": "mrd-flow-2",
|
||||
"fromNode": "mrd-2",
|
||||
"fromSide": "bottom",
|
||||
"toNode": "mrd-3",
|
||||
"toSide": "top",
|
||||
"toEnd": "arrow"
|
||||
},
|
||||
{
|
||||
"id": "mrd-flow-3",
|
||||
"fromNode": "mrd-3",
|
||||
"fromSide": "right",
|
||||
"toNode": "mrd-4",
|
||||
"toSide": "left",
|
||||
"toEnd": "arrow"
|
||||
},
|
||||
{
|
||||
"id": "brainstorm-flow-1",
|
||||
"fromNode": "brainstorm-1",
|
||||
"fromSide": "bottom",
|
||||
"toNode": "brainstorm-2",
|
||||
"toSide": "top",
|
||||
"toEnd": "arrow"
|
||||
},
|
||||
{
|
||||
"id": "brainstorm-flow-2",
|
||||
"fromNode": "brainstorm-2",
|
||||
"fromSide": "bottom",
|
||||
"toNode": "brainstorm-3",
|
||||
"toSide": "top",
|
||||
"toEnd": "arrow"
|
||||
},
|
||||
{
|
||||
"id": "roadmap-flow-1",
|
||||
"fromNode": "roadmap-1",
|
||||
"fromSide": "bottom",
|
||||
"toNode": "roadmap-2",
|
||||
"toSide": "top",
|
||||
"toEnd": "arrow"
|
||||
},
|
||||
{
|
||||
"id": "mrd-to-roadmap",
|
||||
"fromNode": "planning-mrd",
|
||||
"fromSide": "right",
|
||||
"toNode": "roadmap-1",
|
||||
"toSide": "left",
|
||||
"toEnd": "arrow",
|
||||
"label": "MRD → Roadmap"
|
||||
},
|
||||
{
|
||||
"id": "brainstorm-to-roadmap",
|
||||
"fromNode": "planning-brainstorm",
|
||||
"fromSide": "right",
|
||||
"toNode": "roadmap-2",
|
||||
"toSide": "left",
|
||||
"toEnd": "arrow",
|
||||
"label": "Brainstorm → Roadmap"
|
||||
},
|
||||
{
|
||||
"id": "prd-to-parse",
|
||||
"fromNode": "planning-create-prd",
|
||||
"fromSide": "right",
|
||||
"toNode": "planning-parse-prd",
|
||||
"toSide": "left",
|
||||
"toEnd": "arrow",
|
||||
"label": "create → parse"
|
||||
},
|
||||
{
|
||||
"id": "prd-interactive-to-parse",
|
||||
"fromNode": "planning-create-prd-interactive",
|
||||
"fromSide": "right",
|
||||
"toNode": "planning-parse-prd",
|
||||
"toSide": "left",
|
||||
"toEnd": "arrow"
|
||||
},
|
||||
{
|
||||
"id": "planning-to-task",
|
||||
"fromNode": "planning-group",
|
||||
"fromSide": "right",
|
||||
"toNode": "task-group",
|
||||
"toSide": "left",
|
||||
"toEnd": "arrow",
|
||||
"label": "Planning → Tasks",
|
||||
"color": "3"
|
||||
},
|
||||
{
|
||||
"id": "task-to-research",
|
||||
"fromNode": "task-research",
|
||||
"fromSide": "right",
|
||||
"toNode": "research-group",
|
||||
"toSide": "left",
|
||||
"toEnd": "arrow",
|
||||
"label": "Task Research"
|
||||
},
|
||||
{
|
||||
"id": "arch-flow-1",
|
||||
"fromNode": "arch-1",
|
||||
"fromSide": "right",
|
||||
"toNode": "arch-2",
|
||||
"toSide": "left",
|
||||
"toEnd": "arrow"
|
||||
},
|
||||
{
|
||||
"id": "arch-flow-2",
|
||||
"fromNode": "arch-2",
|
||||
"fromSide": "right",
|
||||
"toNode": "arch-3",
|
||||
"toSide": "left",
|
||||
"toEnd": "arrow"
|
||||
},
|
||||
{
|
||||
"id": "arch-flow-3",
|
||||
"fromNode": "arch-3",
|
||||
"fromSide": "right",
|
||||
"toNode": "arch-4",
|
||||
"toSide": "left",
|
||||
"toEnd": "arrow"
|
||||
},
|
||||
{
|
||||
"id": "planning-to-design",
|
||||
"fromNode": "planning-group",
|
||||
"fromSide": "bottom",
|
||||
"toNode": "design-group",
|
||||
"toSide": "top",
|
||||
"toEnd": "arrow",
|
||||
"label": "Planning → Design",
|
||||
"color": "2"
|
||||
},
|
||||
{
|
||||
"id": "task-add-link",
|
||||
"fromNode": "task-add",
|
||||
"fromSide": "right",
|
||||
"toNode": "task-add-interactive",
|
||||
"toSide": "left",
|
||||
"label": "interactive"
|
||||
},
|
||||
{
|
||||
"id": "task-update-link",
|
||||
"fromNode": "task-update",
|
||||
"fromSide": "right",
|
||||
"toNode": "task-update-interactive",
|
||||
"toSide": "left",
|
||||
"label": "interactive"
|
||||
},
|
||||
{
|
||||
"id": "app-design-link",
|
||||
"fromNode": "planning-create-app-design",
|
||||
"fromSide": "right",
|
||||
"toNode": "planning-update-app-design",
|
||||
"toSide": "left",
|
||||
"label": "update"
|
||||
},
|
||||
{
|
||||
"id": "tech-stack-link",
|
||||
"fromNode": "planning-create-tech-stack",
|
||||
"fromSide": "right",
|
||||
"toNode": "planning-update-tech-stack",
|
||||
"toSide": "left",
|
||||
"label": "update"
|
||||
},
|
||||
{
|
||||
"id": "rule-link",
|
||||
"fromNode": "planning-create-rule",
|
||||
"fromSide": "right",
|
||||
"toNode": "planning-update-rule",
|
||||
"toSide": "left",
|
||||
"label": "update"
|
||||
}
|
||||
]
|
||||
}
|
||||
100
.claude/commands/planning/1-mrd/1-start-session.md
Normal file
100
.claude/commands/planning/1-mrd/1-start-session.md
Normal file
@ -0,0 +1,100 @@
|
||||
---
|
||||
allowed-tools: [Bash, Read, Write, Glob]
|
||||
description: Starts a new or updated MRD (Market Requirements Document) research session.
|
||||
---
|
||||
|
||||
# Start MRD Research Session
|
||||
|
||||
## Context
|
||||
- **User Request:** $ARGUMENTS
|
||||
- **MRD Directory:** `.taskmaster/docs/mrd/`
|
||||
- **Existing Sessions:** !`ls -ld .taskmaster/docs/mrd/*/ 2>/dev/null || echo "No existing sessions found"`
|
||||
|
||||
## Goal
|
||||
To initialize a new or updated Market Requirements Document (MRD) research session, set up the dedicated workspace, and present the first research task to the user.
|
||||
|
||||
## Process
|
||||
1. **Determine Session Index:**
|
||||
- Scan the `.taskmaster/docs/mrd/` directory to find the highest existing session index.
|
||||
- Assign the next sequential number for the new session.
|
||||
|
||||
2. **Create Session Directory:**
|
||||
- Create a new directory named `[index]-[session_name]` inside `.taskmaster/docs/mrd/`.
|
||||
- Example: `.taskmaster/docs/mrd/001-mvp-launch/`
|
||||
|
||||
3. **Handle Update Session (if `--from` is provided):**
|
||||
- Copy all `0*_*.md` user research files from the base session directory to the new session directory.
|
||||
- Generate a `_00_update_kickoff_report.md` file. This report will compare the goals of the base session and the new session, highlighting key assumptions that need to be re-validated.
|
||||
|
||||
4. **Initialize Session State:**
|
||||
- Create a `_session-state.json` file in the new session directory.
|
||||
- Initialize it with session details (index, name, status: 'initialized', etc.).
|
||||
|
||||
5. **Interactive Hypothesis Definition:**
|
||||
- This step is a structured conversation to build the foundational `01_initial_hypothesis.md`.
|
||||
|
||||
- **For a new session:**
|
||||
- The AI will ask a series of clarifying questions to build the hypothesis, such as:
|
||||
1. "What is the core problem you are trying to solve?"
|
||||
2. "Who is the primary target audience for this product?"
|
||||
3. "At a high level, what is your proposed solution?"
|
||||
4. "What is the unique value proposition? Why will users choose it over alternatives?"
|
||||
- After gathering the user's answers, the AI will synthesize them into a coherent initial hypothesis.
|
||||
- The AI saves this synthesized content into the `01_initial_hypothesis.md` file.
|
||||
|
||||
- **For an update session (`--from` is used):**
|
||||
- The AI first presents the key findings from the generated `_00_update_kickoff_report.md`.
|
||||
- It then asks for the user's input on the re-validation points. For example: "The report suggests we need to re-validate our target audience. Has your understanding of the target customer changed? If so, how?"
|
||||
- The user's feedback is incorporated to refine the session's starting assumptions, which can be noted in the kickoff report or a new hypothesis file.
|
||||
|
||||
6. **Assign First Task and Generate Research Prompt:**
|
||||
- Based on the session's goal and initial hypothesis, the AI selects the most logical first research task from the examples below.
|
||||
- It clearly presents this task to the user, specifying the filename for the output.
|
||||
- **Crucially**, it must also generate a detailed, self-contained research prompt that can be used by any external agent or tool. This prompt should be presented to the user in a structured format.
|
||||
|
||||
**Research Prompt Generation Template:**
|
||||
The AI will use the newly created `01_initial_hypothesis.md` to construct a prompt like this:
|
||||
```
|
||||
### Research Prompt: [Objective of the Task]
|
||||
|
||||
**1. Project Context:**
|
||||
- **Product/Idea:** [Synthesized from 01_initial_hypothesis.md - e.g., "A platform connecting eco-friendly suppliers with small businesses."]
|
||||
- **Core Problem:** [From hypothesis - e.g., "Small businesses struggle to find and verify sustainable suppliers."]
|
||||
- **Target Audience:** [From hypothesis - e.g., "Owners of small to medium-sized retail businesses."]
|
||||
- **Proposed Solution:** [From hypothesis - e.g., "A curated, searchable marketplace with a built-in verification system."]
|
||||
|
||||
**2. Research Objective:**
|
||||
- [A clear goal for this specific research task, e.g., "To deeply understand the competitive landscape for our proposed solution."]
|
||||
|
||||
**3. Key Research Questions:**
|
||||
- [A list of 3-5 specific questions. For competitor analysis, it could be:]
|
||||
- Who are the top 3 direct and indirect competitors?
|
||||
- What are their pricing models and key features?
|
||||
- What are their primary strengths and weaknesses (SWOT)?
|
||||
- What market segment do they primarily target?
|
||||
|
||||
**4. Expected Deliverables:**
|
||||
- A summary of findings.
|
||||
- Detailed answers to each key research question.
|
||||
- A concluding analysis of opportunities and threats for our product.
|
||||
```
|
||||
|
||||
**First Research Task Examples:**
|
||||
- **Task:** "Define the target market size, segments, and create detailed user personas."
|
||||
- **Filename:** `02_market_and_persona.md`
|
||||
- **Task:** "Validate the core problem this product aims to solve and outline the proposed solution's unique value proposition."
|
||||
- **Filename:** `02_problem_and_solution.md`
|
||||
- **Task:** "Identify the top 3-5 direct and indirect competitors and analyze their strengths, weaknesses, and market positioning."
|
||||
- **Filename:** `02_competitive_landscape.md`
|
||||
- **Task:** "Brainstorm a list of potential core features that address the initial hypothesis and align with the target user's needs."
|
||||
- **Filename:** `02_initial_feature_ideas.md`
|
||||
- **Task:** "Define the key success metrics and Key Performance Indicators (KPIs) that will be used to measure the product's success."
|
||||
- **Filename:** `02_success_metrics.md`
|
||||
|
||||
- After presenting the task and the detailed prompt, the AI will conclude with: "Once you have completed your research and saved it to the specified file, please run the `/planning/mrd/2-analyze-research-data` command to proceed."
|
||||
|
||||
## Example Usage
|
||||
- **Start a new session:**
|
||||
`/planning/mrd/1-start-session --name="mvp-launch"`
|
||||
- **Start a session based on a previous one:**
|
||||
`/planning/mrd/1-start-session --name="enterprise-expansion" --from="mvp-launch"`
|
||||
91
.claude/commands/planning/1-mrd/2-analyze-research-data.md
Normal file
91
.claude/commands/planning/1-mrd/2-analyze-research-data.md
Normal file
@ -0,0 +1,91 @@
|
||||
---
|
||||
allowed-tools: [Read, Write, Glob]
|
||||
description: Analyzes user-submitted research data, provides insights, and suggests the next research step.
|
||||
---
|
||||
|
||||
# Analyze Research Data
|
||||
|
||||
## Context
|
||||
- **User Request:** $ARGUMENTS
|
||||
- **Session Name/Index:** Passed via `--name` argument.
|
||||
- **Session State File:** `_session-state.json` within the specified session directory.
|
||||
|
||||
## Goal
|
||||
To analyze the latest research file(s) submitted by the user within a specific MRD session, generate a summary of insights, and propose the next logical research task to continue the workflow.
|
||||
|
||||
## Process
|
||||
1. **Identify Target Session:**
|
||||
- Use the `--name` argument to locate the correct session directory (e.g., `.taskmaster/docs/mrd/001-mvp-launch/`).
|
||||
|
||||
2. **Read Session State:**
|
||||
- Read the `_session-state.json` file to understand the current context.
|
||||
- Identify the `lastAnalyzedFile` to determine which new files need to be processed.
|
||||
|
||||
3. **Find and Analyze New Research:**
|
||||
- Scan the session directory for any `0*_*.md` files created or modified after `lastAnalyzedFile`.
|
||||
- Read the content of the new research file(s).
|
||||
|
||||
4. **Generate AI Summary:**
|
||||
- Analyze the research content to extract key findings, patterns, opportunities, and threats.
|
||||
- Create or update a corresponding summary file named `_summary_[topic].md` (e.g., `_summary_market_and_persona.md`). This provides a digestible, AI-driven analysis for the user.
|
||||
|
||||
5. **Update Session State with Intelligent Next Action:**
|
||||
- Update the `_session-state.json` file:
|
||||
- Set `status` to `analysis_in_progress`.
|
||||
- Update `lastAnalyzedFile` to the name of the file just analyzed.
|
||||
- **Formulate the `nextAction`:**
|
||||
- The AI must first review all existing `0*_*` research files in the session directory to understand which topics from the "Standard Research Topics" list below have already been covered.
|
||||
- Based on the analysis of the current file and the list of completed topics, the AI will determine the next logical, uncovered research area.
|
||||
- It will then formulate a clear, actionable `nextAction` string.
|
||||
|
||||
**Standard Research Topics (in logical order):**
|
||||
1. **Initial Hypothesis (`01_initial_hypothesis.md`)**: Core problem, target audience, proposed solution.
|
||||
2. **Market & Persona Analysis (`02_market_and_persona.md`)**: Market size, segments, user demographics, needs, and pain points.
|
||||
3. **Competitive Landscape (`03_competitor_analysis.md`)**: Direct/indirect competitors, SWOT analysis, market positioning.
|
||||
4. **Value Proposition & Solution (`04_value_proposition.md`)**: Detailed breakdown of the solution, unique selling points, feature ideas.
|
||||
5. **Pricing & Business Model (`05_pricing_analysis.md`)**: Revenue streams, pricing strategies, cost analysis.
|
||||
6. **Go-to-Market Strategy (`06_go_to_market.md`)**: Marketing channels, sales process, initial customer acquisition plan.
|
||||
7. **Success Metrics & KPIs (`07_success_metrics.md`)**: How to measure product success.
|
||||
|
||||
6. **Report to User with Context and Next Research Prompt:**
|
||||
- Present a concise summary of the analysis from the current research file.
|
||||
- Clearly state the next logical research task and the filename for the output.
|
||||
- **Crucially**, generate a new, updated, self-contained research prompt for this next task. This prompt must synthesize all relevant context from the *entire session* so far (i.e., from `01_...` up to the latest `_summary_...` file).
|
||||
|
||||
**Updated Research Prompt Generation Template:**
|
||||
The AI will use all existing session files (`0*_*` and `_summary_*`) to construct a prompt like this:
|
||||
```
|
||||
### Research Prompt: [Objective of the NEXT Task]
|
||||
|
||||
**1. Project Context (Updated):**
|
||||
- **Product/Idea:** [e.g., "A platform connecting eco-friendly suppliers with small businesses."]
|
||||
- **Key Findings So Far:**
|
||||
- [Insight from summary_market_and_persona.md: e.g., "Identified a key persona 'Eco-conscious Cafe Owner' who values supply chain transparency."]
|
||||
- [Insight from summary_competitor_analysis.md: e.g., "Major competitors focus on large enterprises, leaving a gap in the SMB market."]
|
||||
- [Latest insight...]
|
||||
|
||||
**2. Research Objective:**
|
||||
- [A clear goal for the NEXT research task, e.g., "To define a compelling value proposition and initial feature set based on our market and competitor analysis."]
|
||||
|
||||
**3. Key Research Questions:**
|
||||
- [A list of 3-5 specific questions for the next task. For value proposition, it could be:]
|
||||
- Based on the key findings, what is our unique value proposition?
|
||||
- What core features must we build to deliver this value to our target persona?
|
||||
- How can we differentiate ourselves from the identified competitors?
|
||||
|
||||
**4. Expected Deliverables:**
|
||||
- A clear statement of the value proposition.
|
||||
- A prioritized list of core features.
|
||||
- An explanation of the differentiation strategy.
|
||||
```
|
||||
|
||||
- **Conclude with a clear call to action:**
|
||||
- Instruct the user to run the same `/planning/mrd/2-analyze-research-data` command after creating the next research file.
|
||||
- **Crucially**, emphasize that they must use the **current session name or index** for the `--name` parameter, as the command always analyzes the latest progress within the *current session*.
|
||||
- **Example Conclusion:** "Once you have completed this research and saved it to `04_value_proposition.md`, please run `/planning/mrd/2-analyze-research-data --name"` again to analyze the new data."
|
||||
|
||||
## Example Usage
|
||||
- **Analyze the latest research in a session:**
|
||||
`/planning/mrd/2-analyze-research-data --name="mvp-launch"`
|
||||
- **Analyze by index:**
|
||||
`/planning/mrd/2-analyze-research-data --name="1"`
|
||||
45
.claude/commands/planning/1-mrd/3-generate-mrd-document.md
Normal file
45
.claude/commands/planning/1-mrd/3-generate-mrd-document.md
Normal file
@ -0,0 +1,45 @@
|
||||
---
|
||||
allowed-tools: [Read, Write, Glob]
|
||||
description: Generates the final MRD document by consolidating all research and analysis from a session.
|
||||
---
|
||||
|
||||
# Generate MRD Document
|
||||
|
||||
## Context
|
||||
- **User Request:** $ARGUMENTS
|
||||
- **Session Name/Index:** Passed via `--name` argument.
|
||||
- **All Session Files:** All `0*_*.md` (user research) and `_summary_*.md` (AI analysis) files within the target session directory.
|
||||
|
||||
## Goal
|
||||
To synthesize all research findings and AI-generated analyses from a completed MRD session into a single, coherent, and well-structured Market Requirements Document (MRD).
|
||||
|
||||
## Process
|
||||
1. **Identify Target Session:**
|
||||
- Use the `--name` argument to locate the correct session directory.
|
||||
|
||||
2. **Aggregate All Session Data:**
|
||||
- Read the content of all user research files (`0*_*.md`) within the directory.
|
||||
- Read the content of all AI-generated summary files (`_summary_*.md`).
|
||||
|
||||
3. **Synthesize and Structure Content:**
|
||||
- Comprehensively analyze the aggregated information.
|
||||
- Logically map the findings to the standard sections of an MRD template (e.g., Market Problem, Target Audience, Competitive Landscape, Requirements).
|
||||
- Rewrite and rephrase the content to ensure a consistent tone and narrative flow throughout the document.
|
||||
|
||||
4. **Generate Final MRD File:**
|
||||
- Create the final document named `mrd_[session_name].md`.
|
||||
- Populate it with the structured, synthesized content.
|
||||
|
||||
5. **Finalize Session State:**
|
||||
- Update the `_session-state.json` file by setting the `status` to `finalized`. This marks the session as complete.
|
||||
|
||||
6. **Notify User and Suggest Next Step:**
|
||||
- Inform the user that the MRD document has been successfully generated and provide the file path.
|
||||
- Proactively suggest the next logical step in the SDLC, which is to define a product roadmap.
|
||||
- Example: "Your MRD is complete. Would you like to proceed with defining the product roadmap using `/planning/roadmap/1-define-roadmap`?"
|
||||
|
||||
## Example Usage
|
||||
- **Generate MRD for a session:**
|
||||
`/planning/mrd/3-generate-mrd-document --name="mvp-launch"`
|
||||
- **Generate by index:**
|
||||
`/planning/mrd/3-generate-mrd-document --name="1"`
|
||||
46
.claude/commands/planning/1-mrd/4-compare-mrd-versions.md
Normal file
46
.claude/commands/planning/1-mrd/4-compare-mrd-versions.md
Normal file
@ -0,0 +1,46 @@
|
||||
---
|
||||
allowed-tools: [Read, Write, Glob]
|
||||
description: Compares two different MRD versions (sessions) and generates a strategic change report.
|
||||
---
|
||||
|
||||
# Compare MRD Versions
|
||||
|
||||
## Context
|
||||
- **User Request:** $ARGUMENTS
|
||||
- **Base Session:** Identified by the `--base` argument (name or index).
|
||||
- **Compare Session:** Identified by the `--compare` argument (name or index).
|
||||
- **Final MRD Documents:** The `market-requirements-document_*.md` file from each of the two specified session directories.
|
||||
|
||||
## Goal
|
||||
To provide a clear, actionable comparison report that highlights the strategic evolution between two different MRD versions. This helps stakeholders quickly understand changes in market perception, target audience, competitive landscape, and overall strategy over time.
|
||||
|
||||
## Process
|
||||
1. **Identify Target Sessions:**
|
||||
- Locate the directories for the base and compare sessions using the provided arguments.
|
||||
|
||||
2. **Read Final MRD Documents:**
|
||||
- From each session directory, read the final `market-requirements-document_*.md` file.
|
||||
|
||||
3. **Perform Comparative Analysis:**
|
||||
- Systematically compare the two documents, section by section.
|
||||
- Identify and extract key differences, such as:
|
||||
- Changes in target market or user personas.
|
||||
- Shifts in the competitive landscape.
|
||||
- Updates to key performance indicators (KPIs) or success metrics.
|
||||
- Evolution of core product requirements.
|
||||
- Modifications in pricing or business model assumptions.
|
||||
|
||||
4. **Generate Comparison Report:**
|
||||
- Create a new Markdown file named `mrd_comparison_report_[base]_vs_[compare].md`.
|
||||
- Structure the report to clearly present the side-by-side comparison and a summary of the most significant strategic changes.
|
||||
|
||||
5. **Notify User with Key Insights:**
|
||||
- Inform the user that the comparison report has been generated and provide the file path.
|
||||
- Present a high-level summary of the most critical findings.
|
||||
- Example: "The comparison is complete. The most significant change is the shift in target market from SMBs to Enterprise customers. You can find the detailed report at..."
|
||||
|
||||
## Example Usage
|
||||
- **Compare two sessions by name:**
|
||||
`/planning/mrd/4-compare-mrd-versions --base="mvp-launch" --compare="enterprise-expansion"`
|
||||
- **Compare by index:**
|
||||
`/planning/mrd/4-compare-mrd-versions --base="1" --compare="2"`
|
||||
215
.claude/commands/planning/2-brainstorm/1-start-brainstorm.md
Normal file
215
.claude/commands/planning/2-brainstorm/1-start-brainstorm.md
Normal file
@ -0,0 +1,215 @@
|
||||
---
|
||||
allowed-tools: [Read, Write, Glob, TodoWrite]
|
||||
description: Starts a new brainstorming session for creative idea generation and systematic organization.
|
||||
---
|
||||
|
||||
# Start Brainstorming Session
|
||||
|
||||
## Context
|
||||
- **User Request:** $ARGUMENTS
|
||||
- **Brainstorm Directory:** `.taskmaster/docs/brainstorm/`
|
||||
- **Existing Sessions:** !`ls -ld .taskmaster/docs/brainstorm/*/ 2>/dev/null || echo "No existing brainstorm sessions found"`
|
||||
|
||||
## Goal
|
||||
To initialize a new brainstorming session, set up the dedicated workspace, and guide the user through a structured creative ideation process that transforms abstract concepts into organized, actionable ideas.
|
||||
|
||||
## Process
|
||||
1. **Determine Session Index:**
|
||||
- Scan the `.taskmaster/docs/brainstorm/` directory to find the highest existing session index.
|
||||
- Assign the next sequential number for the new session.
|
||||
|
||||
2. **Create Session Directory:**
|
||||
- Create a new directory named `[index]-[session_name]` inside `.taskmaster/docs/brainstorm/`.
|
||||
- Example: `.taskmaster/docs/brainstorm/001-product-features/`
|
||||
|
||||
3. **Initialize Session State:**
|
||||
- Create a `_session-state.json` file in the new session directory.
|
||||
- Initialize it with session details:
|
||||
```json
|
||||
{
|
||||
"index": 1,
|
||||
"name": "session-name",
|
||||
"type": "brainstorm",
|
||||
"status": "initialized",
|
||||
"created": "2025-01-16T00:00:00Z",
|
||||
"lastUpdated": "2025-01-16T00:00:00Z",
|
||||
"currentStep": "ideation_setup",
|
||||
"completedSteps": [],
|
||||
"nextAction": "Begin interactive ideation setup",
|
||||
"brainstormType": "creative|problem-solving|feature-expansion",
|
||||
"targetDomain": "user-defined",
|
||||
"ideationResults": {}
|
||||
}
|
||||
```
|
||||
|
||||
4. **Interactive Brainstorming Setup:**
|
||||
- Engage the user in a structured conversation to define the brainstorming scope and approach.
|
||||
- **Ask clarifying questions to build the foundational framework:**
|
||||
1. **"What type of brainstorming session do you want to conduct?"**
|
||||
- a) **Creative Ideation** - Generate innovative product concepts, features, or solutions
|
||||
- b) **Problem-Solving** - Address specific challenges or obstacles
|
||||
- c) **Feature Expansion** - Explore variations and improvements of existing ideas
|
||||
- d) **Market Opportunities** - Identify new business or market possibilities
|
||||
|
||||
2. **"What is the central topic or challenge you want to explore?"**
|
||||
- Prompt for a clear, concise problem statement or topic focus
|
||||
|
||||
3. **"Who is your target audience or user group?"**
|
||||
- Define the primary beneficiaries of the ideas being generated
|
||||
|
||||
4. **"What constraints or parameters should guide the brainstorming?"**
|
||||
- Budget limitations, technical constraints, timeline, regulatory requirements, etc.
|
||||
|
||||
5. **"What success criteria will you use to evaluate ideas?"**
|
||||
- Feasibility, impact, innovation level, resource requirements, market potential
|
||||
|
||||
6. **"How many ideas are you aiming to generate?"**
|
||||
- Set a target number to guide the brainstorming intensity (e.g., 20-50 ideas)
|
||||
|
||||
5. **Generate Initial Framework Document:**
|
||||
- Create `01_brainstorm_framework.md` file with the synthesized setup information.
|
||||
- Include:
|
||||
- Session objectives and scope
|
||||
- Target audience and constraints
|
||||
- Success criteria and evaluation framework
|
||||
- Ideation methodology to be used
|
||||
|
||||
6. **Assign First Ideation Task:**
|
||||
- Based on the brainstorming type and framework, present the first ideation task.
|
||||
- Provide structured guidance and creative prompts.
|
||||
- **Generate a detailed, self-contained ideation prompt:**
|
||||
|
||||
**Ideation Prompt Generation Template:**
|
||||
```
|
||||
### Ideation Prompt: [Brainstorming Session Name]
|
||||
|
||||
**1. Session Context:**
|
||||
- **Topic/Challenge:** [From framework - e.g., "Improving user onboarding experience"]
|
||||
- **Target Audience:** [From framework - e.g., "First-time SaaS users aged 25-45"]
|
||||
- **Brainstorm Type:** [From framework - e.g., "Creative Ideation"]
|
||||
- **Constraints:** [From framework - e.g., "Mobile-first design, 3-step maximum process"]
|
||||
|
||||
**2. Ideation Objective:**
|
||||
- [Clear goal for this ideation session, e.g., "Generate 30+ innovative ideas for streamlining user onboarding"]
|
||||
|
||||
**3. Creative Prompts:**
|
||||
- [3-5 specific creative triggers, e.g.:]
|
||||
- "How might we make onboarding feel like a game?"
|
||||
- "What if users could onboard through storytelling?"
|
||||
- "How can we reduce cognitive load in the first 60 seconds?"
|
||||
|
||||
**4. Ideation Techniques:**
|
||||
- **Technique 1:** [e.g., "Rapid Fire - Generate 1 idea per minute for 20 minutes"]
|
||||
- **Technique 2:** [e.g., "SCAMPER Method - Substitute, Combine, Adapt, Modify, Put to other use, Eliminate, Reverse"]
|
||||
- **Technique 3:** [e.g., "What If Scenarios - Explore extreme possibilities"]
|
||||
|
||||
**5. Documentation Format:**
|
||||
- Record each idea with: Title, Description (2-3 sentences), Potential Impact (1-10), Implementation Difficulty (1-10)
|
||||
- Group similar ideas into themes as you go
|
||||
- Note any breakthrough moments or unexpected connections
|
||||
|
||||
**6. Success Metrics:**
|
||||
- [Target number of ideas and quality indicators from framework]
|
||||
```
|
||||
|
||||
7. **Conclude with Clear Next Steps:**
|
||||
- Instruct the user to document their ideas in `02_idea_generation.md`
|
||||
- Provide the complete ideation prompt for reference
|
||||
- **Example conclusion:** "Once you have completed your ideation session and documented your ideas in `02_idea_generation.md`, please run `/planning/brainstorm/2-analyze-ideas --name=[session_name]` to analyze and organize your ideas."
|
||||
|
||||
## Templates & Structures
|
||||
|
||||
### Brainstorm Framework Template
|
||||
```markdown
|
||||
# Brainstorm Framework: [Session Name]
|
||||
|
||||
## Session Overview
|
||||
- **Type:** [Creative Ideation/Problem-Solving/Feature Expansion/Market Opportunities]
|
||||
- **Central Topic:** [Core challenge or focus area]
|
||||
- **Target Audience:** [Primary beneficiaries]
|
||||
- **Session Date:** [Date]
|
||||
|
||||
## Constraints & Parameters
|
||||
- [List of limitations, requirements, or boundaries]
|
||||
|
||||
## Success Criteria
|
||||
- [Evaluation framework for generated ideas]
|
||||
|
||||
## Ideation Methodology
|
||||
- [Specific techniques and approaches to be used]
|
||||
|
||||
## Expected Outcomes
|
||||
- [Target number of ideas and desired quality level]
|
||||
```
|
||||
|
||||
### Session State Structure
|
||||
```json
|
||||
{
|
||||
"index": 1,
|
||||
"name": "session-name",
|
||||
"type": "brainstorm",
|
||||
"status": "initialized|in_progress|completed",
|
||||
"created": "ISO datetime",
|
||||
"lastUpdated": "ISO datetime",
|
||||
"currentStep": "current_step_name",
|
||||
"completedSteps": ["step1", "step2"],
|
||||
"nextAction": "specific next action description",
|
||||
"brainstormType": "creative|problem-solving|feature-expansion|market-opportunities",
|
||||
"targetDomain": "user-defined domain",
|
||||
"ideationResults": {
|
||||
"totalIdeas": 0,
|
||||
"categorizedIdeas": {},
|
||||
"topConcepts": []
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
### ✅ DO: Encourage Divergent Thinking
|
||||
- **Create a judgment-free environment** where all ideas are welcomed
|
||||
- **Use time-boxed sessions** to maintain energy and focus
|
||||
- **Prompt for quantity over quality** initially - refinement comes later
|
||||
- **Encourage wild ideas** - they often lead to breakthrough innovations
|
||||
- **Build on others' ideas** - use "Yes, and..." approach
|
||||
|
||||
**Why:** Divergent thinking generates the raw material for innovation. Premature evaluation kills creativity.
|
||||
|
||||
### ✅ DO: Provide Structure Within Creativity
|
||||
- **Use proven ideation techniques** (SCAMPER, Mind Mapping, Six Thinking Hats)
|
||||
- **Set clear time boundaries** for each ideation round
|
||||
- **Rotate between different creative approaches** to stimulate varied thinking
|
||||
- **Document everything** - even "bad" ideas can spark good ones
|
||||
|
||||
**Why:** Structure provides a framework that actually enhances creativity rather than constraining it.
|
||||
|
||||
### ❌ DON'T: Judge Ideas During Generation
|
||||
- **No criticism or evaluation** during the ideation phase
|
||||
- **Don't overthink feasibility** - focus on possibilities
|
||||
- **Avoid perfectionism** - capture ideas quickly and move on
|
||||
- **Don't let one person dominate** - ensure equal participation
|
||||
|
||||
**Why:** Evaluation and criticism shut down the creative process. Separation of divergent and convergent thinking is crucial.
|
||||
|
||||
### ❌ DON'T: Skip the Framework Phase
|
||||
- **Don't start ideating without clear objectives**
|
||||
- **Don't ignore constraints** - they actually help focus creativity
|
||||
- **Don't proceed without success criteria** - how will you know when you're done?
|
||||
|
||||
**Why:** A clear framework ensures the brainstorming session produces actionable results rather than random ideas.
|
||||
|
||||
## Output
|
||||
- **Format:** Multiple Markdown files within session directory
|
||||
- **Location:** `.taskmaster/docs/brainstorm/[index]-[session_name]/`
|
||||
- **Primary Files:**
|
||||
- `_session-state.json` - Session tracking and metadata
|
||||
- `01_brainstorm_framework.md` - Session setup and parameters
|
||||
- `02_idea_generation.md` - Raw ideation output (user-created)
|
||||
|
||||
## Example Usage
|
||||
- **Start a new creative session:**
|
||||
`/planning/brainstorm/1-start-brainstorm --name="product-features"`
|
||||
- **Start a problem-solving session:**
|
||||
`/planning/brainstorm/1-start-brainstorm --name="user-retention-challenges"`
|
||||
- **Start a feature expansion session:**
|
||||
`/planning/brainstorm/1-start-brainstorm --name="dashboard-improvements"`
|
||||
260
.claude/commands/planning/2-brainstorm/2-analyze-ideas.md
Normal file
260
.claude/commands/planning/2-brainstorm/2-analyze-ideas.md
Normal file
@ -0,0 +1,260 @@
|
||||
---
|
||||
allowed-tools: [Read, Write, Glob]
|
||||
description: Analyzes generated ideas from brainstorming session, categorizes them, and suggests next steps for refinement.
|
||||
---
|
||||
|
||||
# Analyze Brainstorming Ideas
|
||||
|
||||
## Context
|
||||
- **User Request:** $ARGUMENTS
|
||||
- **Session Name/Index:** Passed via `--name` argument.
|
||||
- **Session State File:** `_session-state.json` within the specified brainstorm session directory.
|
||||
|
||||
## Goal
|
||||
To analyze the raw ideas generated during the brainstorming session, organize them systematically, identify patterns and themes, evaluate their potential, and provide actionable recommendations for the next phase of development.
|
||||
|
||||
## Process
|
||||
1. **Identify Target Session:**
|
||||
- Use the `--name` argument to locate the correct brainstorm session directory (e.g., `.taskmaster/docs/brainstorm/001-product-features/`).
|
||||
|
||||
2. **Read Session State and Context:**
|
||||
- Read the `_session-state.json` file to understand the session context.
|
||||
- Review the `01_brainstorm_framework.md` file to understand the original objectives and constraints.
|
||||
- Identify the `lastAnalyzedFile` to determine which new files need to be processed.
|
||||
|
||||
3. **Find and Analyze New Ideas:**
|
||||
- Scan the session directory for any `0*_*.md` files created or modified after `lastAnalyzedFile`.
|
||||
- Read the content of the new idea files (typically `02_idea_generation.md`).
|
||||
- Parse and extract individual ideas from the documentation.
|
||||
|
||||
4. **Systematic Idea Analysis:**
|
||||
- **Categorize Ideas:** Group similar ideas into logical themes or categories.
|
||||
- **Evaluate Feasibility:** Assess implementation difficulty and resource requirements.
|
||||
- **Assess Impact Potential:** Evaluate the potential value and significance of each idea.
|
||||
- **Identify Patterns:** Look for recurring themes, innovative approaches, or breakthrough concepts.
|
||||
- **Spot Combinations:** Identify ideas that could be merged or built upon each other.
|
||||
|
||||
5. **Generate Analysis Summary:**
|
||||
- Create a comprehensive analysis file named `_analysis_[topic].md` (e.g., `_analysis_product_features.md`).
|
||||
- Include:
|
||||
- **Executive Summary:** High-level overview of the ideation results
|
||||
- **Idea Categorization:** Organized themes with grouped ideas
|
||||
- **Top Concepts:** Highest-potential ideas based on evaluation criteria
|
||||
- **Feasibility Matrix:** Ideas plotted against impact vs. difficulty
|
||||
- **Pattern Analysis:** Recurring themes and innovative approaches
|
||||
- **Combination Opportunities:** Ideas that could be merged or enhanced
|
||||
- **Quick Wins:** Low-effort, high-impact ideas for immediate implementation
|
||||
- **Moonshot Ideas:** High-risk, high-reward concepts for future consideration
|
||||
|
||||
6. **Update Session State with Intelligent Next Action:**
|
||||
- Update the `_session-state.json` file:
|
||||
- Set `status` to `analysis_complete`.
|
||||
- Update `lastAnalyzedFile` to the name of the file just analyzed.
|
||||
- Update `ideationResults` with quantitative summary.
|
||||
- Formulate the `nextAction` based on the analysis results.
|
||||
|
||||
**Standard Next Actions (contextual selection):**
|
||||
- **If many high-quality ideas generated:** "Create refined concept selection with priority ranking"
|
||||
- **If ideas need validation:** "Conduct concept validation with target users"
|
||||
- **If ideas are too broad:** "Focus and refine top 3-5 concepts"
|
||||
- **If ready for development:** "Generate final brainstorm summary and transition to PRD"
|
||||
|
||||
7. **Report Analysis Results with Actionable Recommendations:**
|
||||
- Present a concise summary of the analysis findings.
|
||||
- Highlight the most promising ideas and their potential impact.
|
||||
- Provide specific recommendations for next steps.
|
||||
- **Generate a refined ideation prompt if additional brainstorming is needed:**
|
||||
|
||||
**Refined Ideation Prompt Template:**
|
||||
```
|
||||
### Refined Ideation Prompt: [Focus Area from Analysis]
|
||||
|
||||
**1. Analysis Context:**
|
||||
- **Total Ideas Generated:** [Number]
|
||||
- **Key Themes Identified:** [List of main categories]
|
||||
- **Top Concepts:** [2-3 highest-potential ideas]
|
||||
- **Gaps Identified:** [Areas needing more exploration]
|
||||
|
||||
**2. Refinement Objective:**
|
||||
- [Specific goal for additional ideation, e.g., "Deepen the top 3 concepts with detailed implementation approaches"]
|
||||
|
||||
**3. Focused Prompts:**
|
||||
- [3-5 specific questions to guide refinement]
|
||||
- [Based on gaps or promising areas from analysis]
|
||||
|
||||
**4. Success Criteria:**
|
||||
- [Updated criteria based on analysis results]
|
||||
```
|
||||
|
||||
8. **Conclude with Clear Next Steps:**
|
||||
- Instruct the user on the recommended next action.
|
||||
- Provide the filename for any additional work needed.
|
||||
- **Example conclusion:** "Based on the analysis, I recommend focusing on the top 5 concepts. Please create `03_concept_refinement.md` with detailed development of these ideas, then run `/planning/brainstorm/2-analyze-ideas --name=[session_name]` again to analyze the refined concepts."
|
||||
|
||||
## Templates & Structures
|
||||
|
||||
### Analysis Summary Template
|
||||
```markdown
|
||||
# Brainstorm Analysis: [Session Name]
|
||||
|
||||
## Executive Summary
|
||||
- **Total Ideas Generated:** [Number]
|
||||
- **Analysis Date:** [Date]
|
||||
- **Key Insight:** [One-sentence summary of main finding]
|
||||
|
||||
## Idea Categorization
|
||||
|
||||
### Category 1: [Theme Name]
|
||||
- **Description:** [What this category represents]
|
||||
- **Ideas:** [List of related ideas]
|
||||
- **Potential Impact:** [Assessment]
|
||||
|
||||
### Category 2: [Theme Name]
|
||||
- **Description:** [What this category represents]
|
||||
- **Ideas:** [List of related ideas]
|
||||
- **Potential Impact:** [Assessment]
|
||||
|
||||
## Top Concepts (Prioritized)
|
||||
|
||||
### 1. [Concept Name]
|
||||
- **Description:** [Detailed explanation]
|
||||
- **Impact Score:** [1-10]
|
||||
- **Feasibility Score:** [1-10]
|
||||
- **Why it's promising:** [Reasoning]
|
||||
|
||||
### 2. [Concept Name]
|
||||
- **Description:** [Detailed explanation]
|
||||
- **Impact Score:** [1-10]
|
||||
- **Feasibility Score:** [1-10]
|
||||
- **Why it's promising:** [Reasoning]
|
||||
|
||||
## Feasibility Matrix
|
||||
|
||||
### Quick Wins (High Impact, Low Effort)
|
||||
- [List of ideas]
|
||||
|
||||
### Major Projects (High Impact, High Effort)
|
||||
- [List of ideas]
|
||||
|
||||
### Fill-ins (Low Impact, Low Effort)
|
||||
- [List of ideas]
|
||||
|
||||
### Questionable (Low Impact, High Effort)
|
||||
- [List of ideas]
|
||||
|
||||
## Pattern Analysis
|
||||
- **Recurring Themes:** [Common patterns across ideas]
|
||||
- **Innovative Approaches:** [Unique or breakthrough concepts]
|
||||
- **User-Centric Focus:** [Ideas that strongly address user needs]
|
||||
|
||||
## Combination Opportunities
|
||||
- **Idea A + Idea B:** [Potential synergies]
|
||||
- **Theme-based Combinations:** [Ways to merge related concepts]
|
||||
|
||||
## Recommendations
|
||||
|
||||
### Immediate Next Steps
|
||||
1. [Specific action recommendation]
|
||||
2. [Specific action recommendation]
|
||||
3. [Specific action recommendation]
|
||||
|
||||
### Future Considerations
|
||||
- [Longer-term opportunities]
|
||||
- [Areas for additional brainstorming]
|
||||
|
||||
## Gaps and Missing Elements
|
||||
- [Areas that need more exploration]
|
||||
- [Stakeholder perspectives not yet considered]
|
||||
```
|
||||
|
||||
### Updated Session State Structure
|
||||
```json
|
||||
{
|
||||
"index": 1,
|
||||
"name": "session-name",
|
||||
"type": "brainstorm",
|
||||
"status": "analysis_complete",
|
||||
"created": "ISO datetime",
|
||||
"lastUpdated": "ISO datetime",
|
||||
"currentStep": "idea_analysis",
|
||||
"completedSteps": ["ideation_setup", "idea_generation"],
|
||||
"nextAction": "specific recommendation based on analysis",
|
||||
"brainstormType": "creative|problem-solving|feature-expansion|market-opportunities",
|
||||
"targetDomain": "user-defined domain",
|
||||
"ideationResults": {
|
||||
"totalIdeas": 42,
|
||||
"categorizedIdeas": {
|
||||
"user-experience": 12,
|
||||
"technical-innovation": 8,
|
||||
"business-model": 6
|
||||
},
|
||||
"topConcepts": [
|
||||
{
|
||||
"name": "concept-name",
|
||||
"impactScore": 9,
|
||||
"feasibilityScore": 7,
|
||||
"category": "user-experience"
|
||||
}
|
||||
],
|
||||
"analysisDate": "ISO datetime"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
### ✅ DO: Systematic Categorization
|
||||
- **Use consistent criteria** for grouping ideas into themes
|
||||
- **Look for natural clusters** rather than forcing artificial categories
|
||||
- **Consider multiple perspectives** (user, business, technical) when categorizing
|
||||
- **Document rationale** for categorization decisions
|
||||
|
||||
**Why:** Systematic organization makes patterns visible and helps identify the most promising areas for development.
|
||||
|
||||
### ✅ DO: Balanced Evaluation
|
||||
- **Assess both impact and feasibility** for each idea
|
||||
- **Consider short-term and long-term potential** separately
|
||||
- **Factor in resource constraints** from the original framework
|
||||
- **Use consistent scoring criteria** across all ideas
|
||||
|
||||
**Why:** Balanced evaluation ensures that both ambitious and practical ideas receive appropriate consideration.
|
||||
|
||||
### ✅ DO: Identify Synergies
|
||||
- **Look for complementary ideas** that could be combined
|
||||
- **Consider sequential implementation** where one idea enables another
|
||||
- **Explore theme-based combinations** that address multiple user needs
|
||||
- **Document potential integration points** between related concepts
|
||||
|
||||
**Why:** Combinations often produce more powerful solutions than individual ideas in isolation.
|
||||
|
||||
### ❌ DON'T: Dismiss Ideas Too Quickly
|
||||
- **Don't eliminate ideas based on initial impressions** - analyze them systematically
|
||||
- **Don't ignore "wild" ideas** - they often contain valuable insights
|
||||
- **Don't let feasibility bias** overshadow potentially transformative concepts
|
||||
- **Don't assume resource constraints** are permanent - they may change
|
||||
|
||||
**Why:** Premature dismissal can eliminate breakthrough opportunities that might be valuable with different approaches or timing.
|
||||
|
||||
### ❌ DON'T: Over-Analyze
|
||||
- **Don't spend excessive time** on obviously weak ideas
|
||||
- **Don't get stuck in analysis paralysis** - aim for actionable insights
|
||||
- **Don't perfect the analysis** - focus on identifying clear next steps
|
||||
- **Don't analyze in isolation** - consider the original framework and constraints
|
||||
|
||||
**Why:** Over-analysis can delay progress and obscure the most important insights needed for decision-making.
|
||||
|
||||
## Output
|
||||
- **Format:** Markdown analysis file
|
||||
- **Location:** `.taskmaster/docs/brainstorm/[index]-[session_name]/`
|
||||
- **Primary Files:**
|
||||
- `_analysis_[topic].md` - Comprehensive idea analysis
|
||||
- `_session-state.json` - Updated session state
|
||||
- Optional: `03_concept_refinement.md` - Additional refinement (user-created)
|
||||
|
||||
## Example Usage
|
||||
- **Analyze ideas from a session:**
|
||||
`/planning/brainstorm/2-analyze-ideas --name="product-features"`
|
||||
- **Analyze by index:**
|
||||
`/planning/brainstorm/2-analyze-ideas --name="1"`
|
||||
- **Re-analyze after refinement:**
|
||||
`/planning/brainstorm/2-analyze-ideas --name="product-features"` (automatically detects new files)
|
||||
@ -0,0 +1,321 @@
|
||||
---
|
||||
allowed-tools: [Read, Write, Glob]
|
||||
description: Generates the final brainstorm summary document by consolidating all ideation and analysis from a session.
|
||||
---
|
||||
|
||||
# Generate Brainstorm Summary
|
||||
|
||||
## Context
|
||||
- **User Request:** $ARGUMENTS
|
||||
- **Session Name/Index:** Passed via `--name` argument.
|
||||
- **All Session Files:** All `0*_*.md` (user ideation) and `_analysis_*.md` (AI analysis) files within the target brainstorm session directory.
|
||||
|
||||
## Goal
|
||||
To synthesize all ideation activities and analytical insights from a completed brainstorming session into a single, coherent, and actionable Brainstorm Summary Document that can serve as input for product development, PRD creation, or further strategic planning.
|
||||
|
||||
## Process
|
||||
1. **Identify Target Session:**
|
||||
- Use the `--name` argument to locate the correct brainstorm session directory.
|
||||
|
||||
2. **Aggregate All Session Data:**
|
||||
- Read the content of the brainstorm framework file (`01_brainstorm_framework.md`).
|
||||
- Read the content of all user ideation files (`02_idea_generation.md`, `03_concept_refinement.md`, etc.).
|
||||
- Read the content of all AI analysis files (`_analysis_*.md`).
|
||||
- Read the session state file (`_session-state.json`) for metadata and context.
|
||||
|
||||
3. **Synthesize and Structure Content:**
|
||||
- Comprehensively analyze the aggregated information.
|
||||
- Identify the most valuable insights and breakthrough concepts.
|
||||
- Create a coherent narrative that connects the ideation process to actionable outcomes.
|
||||
- Organize content into a logical structure that supports decision-making.
|
||||
|
||||
4. **Generate Executive Summary:**
|
||||
- Create a high-level overview that captures:
|
||||
- Session objectives and approach
|
||||
- Key quantitative results (total ideas, categories, etc.)
|
||||
- Most significant insights and breakthrough concepts
|
||||
- Recommended next steps and implementation priorities
|
||||
|
||||
5. **Develop Concept Portfolio:**
|
||||
- **Tier 1 Concepts:** Highest-priority ideas ready for immediate development
|
||||
- **Tier 2 Concepts:** Promising ideas requiring further validation or refinement
|
||||
- **Tier 3 Concepts:** Innovative ideas for future consideration
|
||||
- **Quick Wins:** Low-effort, high-impact ideas for immediate implementation
|
||||
|
||||
6. **Create Implementation Roadmap:**
|
||||
- Prioritize concepts based on impact, feasibility, and strategic alignment
|
||||
- Suggest logical sequencing for development
|
||||
- Identify resource requirements and dependencies
|
||||
- Provide transition guidance to next phase (PRD, development, etc.)
|
||||
|
||||
7. **Generate Final Summary Document:**
|
||||
- Create the final document named `brainstorm-summary_[session_name].md`.
|
||||
- Structure the content according to the template below.
|
||||
- Ensure the document is actionable and ready for stakeholder review.
|
||||
|
||||
8. **Finalize Session State:**
|
||||
- Update the `_session-state.json` file by setting the `status` to `completed`.
|
||||
- Record final metrics and outcomes.
|
||||
- This marks the brainstorming session as complete.
|
||||
|
||||
9. **Notify User and Suggest Next Steps:**
|
||||
- Inform the user that the brainstorm summary has been successfully generated.
|
||||
- Provide the file path and key highlights.
|
||||
- Proactively suggest logical next steps based on the session outcomes.
|
||||
- **Example suggestions:**
|
||||
- "Your brainstorm summary is complete. Based on the results, I recommend creating a PRD using `/planning/prd/2-create-from-brainstorm --name=[session_name]`"
|
||||
- "Consider validating the top 3 concepts with target users before proceeding to development"
|
||||
- "The technical concepts suggest creating a roadmap with `/planning/roadmap/1-define-roadmap --from-brainstorm=[session_name]`"
|
||||
|
||||
## Templates & Structures
|
||||
|
||||
### Brainstorm Summary Document Template
|
||||
```markdown
|
||||
# Brainstorm Summary: [Session Name]
|
||||
|
||||
**Session Date:** [Date]
|
||||
**Session Type:** [Creative Ideation/Problem-Solving/Feature Expansion/Market Opportunities]
|
||||
**Facilitator:** AI-Guided Brainstorming System
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
### Session Overview
|
||||
- **Objective:** [Original brainstorming objective]
|
||||
- **Target Domain:** [Area of focus]
|
||||
- **Constraints:** [Key limitations and parameters]
|
||||
- **Duration:** [Time span of session]
|
||||
|
||||
### Key Results
|
||||
- **Total Ideas Generated:** [Number]
|
||||
- **Major Categories:** [List of main themes]
|
||||
- **Breakthrough Concepts:** [Number of innovative ideas]
|
||||
- **Implementation-Ready Ideas:** [Number of actionable concepts]
|
||||
|
||||
### Strategic Insights
|
||||
- **Primary Finding:** [Most significant insight]
|
||||
- **Market Opportunity:** [Key opportunities identified]
|
||||
- **Innovation Potential:** [Assessment of creative breakthrough]
|
||||
|
||||
---
|
||||
|
||||
## Concept Portfolio
|
||||
|
||||
### Tier 1: Priority Concepts (Ready for Development)
|
||||
|
||||
#### 1. [Concept Name]
|
||||
- **Description:** [Detailed explanation]
|
||||
- **Impact Potential:** [High/Medium/Low] - [Reasoning]
|
||||
- **Feasibility:** [High/Medium/Low] - [Assessment]
|
||||
- **Resource Requirements:** [Estimated effort]
|
||||
- **Success Criteria:** [How to measure success]
|
||||
- **Next Steps:** [Specific actions needed]
|
||||
|
||||
#### 2. [Concept Name]
|
||||
- **Description:** [Detailed explanation]
|
||||
- **Impact Potential:** [High/Medium/Low] - [Reasoning]
|
||||
- **Feasibility:** [High/Medium/Low] - [Assessment]
|
||||
- **Resource Requirements:** [Estimated effort]
|
||||
- **Success Criteria:** [How to measure success]
|
||||
- **Next Steps:** [Specific actions needed]
|
||||
|
||||
### Tier 2: Promising Concepts (Require Validation)
|
||||
|
||||
#### [Concept Name]
|
||||
- **Description:** [Brief explanation]
|
||||
- **Why Promising:** [Potential value]
|
||||
- **Validation Needed:** [What needs to be tested/confirmed]
|
||||
- **Timeline:** [When to revisit]
|
||||
|
||||
### Tier 3: Future Innovations (Long-term Potential)
|
||||
|
||||
#### [Concept Name]
|
||||
- **Description:** [Brief explanation]
|
||||
- **Innovation Factor:** [What makes it unique]
|
||||
- **Barriers:** [Current limitations]
|
||||
- **Future Triggers:** [Conditions that would make it viable]
|
||||
|
||||
---
|
||||
|
||||
## Implementation Roadmap
|
||||
|
||||
### Phase 1: Quick Wins (0-3 months)
|
||||
- **[Concept Name]:** [Brief description and rationale]
|
||||
- **[Concept Name]:** [Brief description and rationale]
|
||||
- **Success Metrics:** [How to measure progress]
|
||||
|
||||
### Phase 2: Core Development (3-12 months)
|
||||
- **[Concept Name]:** [Brief description and rationale]
|
||||
- **[Concept Name]:** [Brief description and rationale]
|
||||
- **Dependencies:** [What needs to be in place]
|
||||
|
||||
### Phase 3: Innovation Projects (12+ months)
|
||||
- **[Concept Name]:** [Brief description and rationale]
|
||||
- **[Concept Name]:** [Brief description and rationale]
|
||||
- **Research Requirements:** [Additional investigation needed]
|
||||
|
||||
---
|
||||
|
||||
## Category Analysis
|
||||
|
||||
### [Category Name]
|
||||
- **Theme:** [What this category represents]
|
||||
- **Ideas Count:** [Number of ideas in this category]
|
||||
- **Top Concepts:** [Best ideas from this category]
|
||||
- **Implementation Notes:** [Special considerations]
|
||||
|
||||
### [Category Name]
|
||||
- **Theme:** [What this category represents]
|
||||
- **Ideas Count:** [Number of ideas in this category]
|
||||
- **Top Concepts:** [Best ideas from this category]
|
||||
- **Implementation Notes:** [Special considerations]
|
||||
|
||||
---
|
||||
|
||||
## Process Insights
|
||||
|
||||
### What Worked Well
|
||||
- [Effective ideation techniques]
|
||||
- [Productive creative approaches]
|
||||
- [Successful breakthrough moments]
|
||||
|
||||
### Lessons Learned
|
||||
- [Key insights about the creative process]
|
||||
- [Unexpected discoveries]
|
||||
- [Process improvements for future sessions]
|
||||
|
||||
### Recommended Improvements
|
||||
- [Suggestions for future brainstorming sessions]
|
||||
- [Areas for deeper exploration]
|
||||
- [Stakeholder input needed]
|
||||
|
||||
---
|
||||
|
||||
## Next Steps & Recommendations
|
||||
|
||||
### Immediate Actions (Next 2 weeks)
|
||||
1. [Specific action with owner and timeline]
|
||||
2. [Specific action with owner and timeline]
|
||||
3. [Specific action with owner and timeline]
|
||||
|
||||
### Medium-term Priorities (Next 3 months)
|
||||
1. [Strategic action with requirements]
|
||||
2. [Strategic action with requirements]
|
||||
3. [Strategic action with requirements]
|
||||
|
||||
### Long-term Vision (6-12 months)
|
||||
1. [Vision-level action with success criteria]
|
||||
2. [Vision-level action with success criteria]
|
||||
|
||||
### Suggested Transition
|
||||
- **If moving to PRD:** [Specific concepts to focus on]
|
||||
- **If moving to Roadmap:** [Technical considerations identified]
|
||||
- **If additional brainstorming needed:** [Areas requiring deeper exploration]
|
||||
|
||||
---
|
||||
|
||||
## Appendices
|
||||
|
||||
### A. Full Idea Inventory
|
||||
[Complete list of all ideas generated, organized by category]
|
||||
|
||||
### B. Evaluation Criteria
|
||||
[Detailed scoring methodology used for concept evaluation]
|
||||
|
||||
### C. Session Artifacts
|
||||
- Original framework document
|
||||
- Raw ideation outputs
|
||||
- Analysis summaries
|
||||
```
|
||||
|
||||
### Final Session State Structure
|
||||
```json
|
||||
{
|
||||
"index": 1,
|
||||
"name": "session-name",
|
||||
"type": "brainstorm",
|
||||
"status": "completed",
|
||||
"created": "ISO datetime",
|
||||
"lastUpdated": "ISO datetime",
|
||||
"currentStep": "summary_complete",
|
||||
"completedSteps": ["ideation_setup", "idea_generation", "idea_analysis", "summary_creation"],
|
||||
"nextAction": "Session complete - ready for PRD/Roadmap transition",
|
||||
"brainstormType": "creative|problem-solving|feature-expansion|market-opportunities",
|
||||
"targetDomain": "user-defined domain",
|
||||
"ideationResults": {
|
||||
"totalIdeas": 42,
|
||||
"categorizedIdeas": {
|
||||
"user-experience": 12,
|
||||
"technical-innovation": 8,
|
||||
"business-model": 6
|
||||
},
|
||||
"topConcepts": [
|
||||
{
|
||||
"name": "concept-name",
|
||||
"impactScore": 9,
|
||||
"feasibilityScore": 7,
|
||||
"category": "user-experience",
|
||||
"tier": 1
|
||||
}
|
||||
],
|
||||
"analysisDate": "ISO datetime",
|
||||
"summaryGenerated": "ISO datetime"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
### ✅ DO: Create Actionable Outcomes
|
||||
- **Focus on implementation-ready concepts** rather than abstract ideas
|
||||
- **Provide specific next steps** for each priority concept
|
||||
- **Include success criteria** and measurable outcomes
|
||||
- **Consider resource requirements** realistically
|
||||
|
||||
**Why:** A brainstorm summary should bridge creative thinking with practical execution.
|
||||
|
||||
### ✅ DO: Maintain Strategic Perspective
|
||||
- **Align concepts with original objectives** and constraints
|
||||
- **Consider business impact** alongside creative merit
|
||||
- **Evaluate concepts within competitive context** if relevant
|
||||
- **Think about scalability** and long-term potential
|
||||
|
||||
**Why:** Strategic alignment ensures that creative outputs serve business objectives.
|
||||
|
||||
### ✅ DO: Preserve Creative Insights
|
||||
- **Document breakthrough moments** and innovative approaches
|
||||
- **Capture unexpected connections** between ideas
|
||||
- **Preserve minority opinions** and unconventional thinking
|
||||
- **Note process insights** for future brainstorming sessions
|
||||
|
||||
**Why:** Creative insights often contain valuable intelligence that extends beyond specific ideas.
|
||||
|
||||
### ❌ DON'T: Oversimplify Complex Ideas
|
||||
- **Don't reduce innovative concepts** to simple feature requests
|
||||
- **Don't ignore implementation complexity** when it's relevant
|
||||
- **Don't dismiss ideas** that don't fit current priorities
|
||||
- **Don't lose nuance** in the synthesis process
|
||||
|
||||
**Why:** Oversimplification can destroy the value of creative insights and innovative thinking.
|
||||
|
||||
### ❌ DON'T: Skip Prioritization
|
||||
- **Don't present all ideas as equally important** - provide clear hierarchy
|
||||
- **Don't ignore feasibility constraints** when prioritizing
|
||||
- **Don't forget about resource limitations** in implementation planning
|
||||
- **Don't avoid making recommendations** - stakeholders need guidance
|
||||
|
||||
**Why:** Unprioritized outputs create decision paralysis and reduce the value of the brainstorming investment.
|
||||
|
||||
## Output
|
||||
- **Format:** Comprehensive Markdown document
|
||||
- **Location:** `.taskmaster/docs/brainstorm/[index]-[session_name]/`
|
||||
- **Primary Files:**
|
||||
- `brainstorm-summary_[session_name].md` - Final comprehensive summary
|
||||
- `_session-state.json` - Updated to completed status
|
||||
|
||||
## Example Usage
|
||||
- **Generate summary for a session:**
|
||||
`/planning/brainstorm/3-generate-brainstorm-summary --name="product-features"`
|
||||
- **Generate by index:**
|
||||
`/planning/brainstorm/3-generate-brainstorm-summary --name="1"`
|
||||
113
.claude/commands/planning/3-roadmap/1-create-from-mrd.md
Normal file
113
.claude/commands/planning/3-roadmap/1-create-from-mrd.md
Normal file
@ -0,0 +1,113 @@
|
||||
---
|
||||
allowed-tools: [Read, Write]
|
||||
description: Creates a PRD direction roadmap from an existing MRD, suggesting phased PRD development for key features with improvement directions.
|
||||
---
|
||||
|
||||
# Create PRD Direction Roadmap from MRD
|
||||
|
||||
## Context
|
||||
- User Request: $ARGUMENTS
|
||||
- MRD Session: Identified by --name argument (session name or index).
|
||||
- Source MRD: Final market-requirements-document_*.md file from the specified MRD session directory.
|
||||
- Roadmap Directory: .taskmaster/docs/roadmap/
|
||||
|
||||
## Goal
|
||||
To transform market requirements from an MRD into a focused roadmap that suggests phased PRD development for key features, providing directions for iterative improvements without timelines or session states.
|
||||
|
||||
## Process
|
||||
|
||||
1. **Identify Source MRD:**
|
||||
- Use the --name argument to locate the correct MRD session directory (e.g., .taskmaster/docs/mrd/001-enterprise-expansion/).
|
||||
- Read the final MRD document (market-requirements-document_*.md) to extract key market insights, user requirements, and feature ideas.
|
||||
|
||||
2. **Extract Key Elements from MRD:**
|
||||
- **Market and User Insights:** Identify target segments, pain points, and opportunities.
|
||||
- **Feature Opportunities:** Map MRD requirements to potential features, prioritizing based on business impact and feasibility.
|
||||
- **Improvement Directions:** For each feature, suggest iterative refinement paths (e.g., from basic MVP to advanced versions).
|
||||
|
||||
3. **Generate PRD Direction Roadmap:**
|
||||
- Create a single comprehensive document outlining phased PRD suggestions for features.
|
||||
- Structure the content using the PRD Direction Roadmap Template, focusing on iterative PRD development and improvement suggestions.
|
||||
- Ensure the roadmap emphasizes directions for PRD creation, such as starting with core features and evolving through user feedback.
|
||||
|
||||
4. **Notify User with Key Insights:**
|
||||
- Inform the user that the PRD direction roadmap has been generated.
|
||||
- Provide the file path and highlight top feature suggestions.
|
||||
- Suggest next steps: "Proceed to create detailed PRDs for suggested features using /planning/prd/1-create-from-roadmap --name=[roadmap_name] --feature=[feature_id]"
|
||||
|
||||
## Templates & Structures
|
||||
|
||||
### PRD Direction Roadmap Template
|
||||
```markdown
|
||||
# PRD Direction Roadmap: [MRD Session Name]
|
||||
|
||||
**Created:** [Date]
|
||||
**Source:** MRD Session: [MRD Session Name]
|
||||
**Focus:** Phased PRD Development and Improvement Directions
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
- **Overview:** High-level suggestions for PRD development based on MRD insights.
|
||||
- **Key Features:** [Number] prioritized features with phased PRD directions.
|
||||
- **Improvement Approach:** Iterative refinement from core to advanced implementations.
|
||||
|
||||
---
|
||||
|
||||
## Feature Suggestions
|
||||
|
||||
### Feature 1: [Feature Name]
|
||||
- **MRD Basis:** [Relevant insights from MRD, e.g., user pain points].
|
||||
- **Phased PRD Directions:**
|
||||
- **Phase 1 (Core):** Basic PRD focusing on MVP functionality.
|
||||
- **Phase 2 (Improvement):** Add user feedback loops and refinements.
|
||||
- **Phase 3 (Advanced):** Integrate scalability and edge cases.
|
||||
- **Improvement Suggestions:** [e.g., Start with user testing, evolve based on metrics like adoption rate].
|
||||
|
||||
### Feature 2: [Feature Name]
|
||||
- **MRD Basis:** [Relevant insights].
|
||||
- **Phased PRD Directions:** [Similar phased structure].
|
||||
- **Improvement Suggestions:** [Specific directions].
|
||||
|
||||
---
|
||||
|
||||
## Overall Improvement Strategy
|
||||
- **Iteration Model:** Use user feedback to refine PRDs iteratively.
|
||||
- **Prioritization Criteria:** Based on MRD impact and feasibility.
|
||||
- **Success Indicators:** [e.g., Alignment with market needs, measurable user value].
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
- Create PRD for Feature 1 using suggested directions.
|
||||
- Validate improvements through prototypes or user tests.
|
||||
```
|
||||
|
||||
## Best Practices / DO & DON'T
|
||||
|
||||
### ✅ DO: Focus on Iterative PRD Directions
|
||||
- Emphasize phased approaches that guide PRD evolution from basic to advanced.
|
||||
- Suggest specific improvement ideas tied to MRD insights.
|
||||
**Why:** This ensures the roadmap drives actionable, evolving PRD creation.
|
||||
|
||||
### ✅ DO: Prioritize Based on MRD Insights
|
||||
- Rank features by market impact and user needs from the MRD.
|
||||
- Include rationale for each suggestion.
|
||||
**Why:** Maintains alignment with original market requirements.
|
||||
|
||||
### ❌ DON'T: Include Timelines or Deadlines
|
||||
- Avoid any time-based planning or horizons.
|
||||
**Why:** Focus solely on directional guidance for PRD development.
|
||||
|
||||
### ❌ DON'T: Add Unnecessary Complexity
|
||||
- Keep suggestions concise and directly tied to PRD phases.
|
||||
**Why:** The goal is to provide clear directions, not over-engineer the roadmap.
|
||||
|
||||
## Output
|
||||
- **Format:** Markdown document.
|
||||
- **Location:** .taskmaster/docs/roadmap/
|
||||
- **Filename:** roadmap-prd-directions_[mrd_session_name].md
|
||||
|
||||
## Example Usage
|
||||
- Create PRD direction roadmap from MRD session: /planning/roadmap/1-create-from-mrd --name="enterprise-expansion"
|
||||
- Create by MRD index: /planning/roadmap/1-create-from-mrd --name="1"
|
||||
113
.claude/commands/planning/3-roadmap/2-create-from-brainstorm.md
Normal file
113
.claude/commands/planning/3-roadmap/2-create-from-brainstorm.md
Normal file
@ -0,0 +1,113 @@
|
||||
---
|
||||
allowed-tools: [Read, Write]
|
||||
description: Creates a PRD direction roadmap from a brainstorming session, suggesting phased PRD development for key features with improvement directions.
|
||||
---
|
||||
|
||||
# Create PRD Direction Roadmap from Brainstorm
|
||||
|
||||
## Context
|
||||
- User Request: $ARGUMENTS
|
||||
- Brainstorm Session: Identified by --name argument (session name or index).
|
||||
- Source Brainstorm: Final brainstorm-summary_*.md file from the specified brainstorm session directory.
|
||||
- Roadmap Directory: .taskmaster/docs/roadmap/
|
||||
|
||||
## Goal
|
||||
To transform creative ideas from a brainstorming session into a focused roadmap that suggests phased PRD development for key features, providing directions for iterative improvements without timelines or session states.
|
||||
|
||||
## Process
|
||||
|
||||
1. **Identify Source Brainstorm:**
|
||||
- Use the --name argument to locate the correct brainstorm session directory (e.g., .taskmaster/docs/brainstorm/001-product-features/).
|
||||
- Read the final brainstorm summary document (brainstorm-summary_*.md) to extract key concepts and ideas.
|
||||
|
||||
2. **Extract Key Elements from Brainstorm:**
|
||||
- **Creative Insights:** Identify high-priority ideas and themes.
|
||||
- **Feature Opportunities:** Map brainstorm concepts to potential features, prioritizing by innovation potential.
|
||||
- **Improvement Directions:** For each feature, suggest iterative refinement paths (e.g., from initial idea to refined implementation).
|
||||
|
||||
3. **Generate PRD Direction Roadmap:**
|
||||
- Create a single comprehensive document outlining phased PRD suggestions for features.
|
||||
- Structure the content using the PRD Direction Roadmap Template, focusing on iterative PRD development and improvement suggestions.
|
||||
- Ensure the roadmap emphasizes directions for PRD creation, such as evolving ideas through validation and refinement.
|
||||
|
||||
4. **Notify User with Key Insights:**
|
||||
- Inform the user that the PRD direction roadmap has been generated.
|
||||
- Provide the file path and highlight top feature suggestions.
|
||||
- Suggest next steps: "Proceed to create detailed PRDs for suggested features using /planning/prd/2-create-from-brainstorm --name=[brainstorm_session_name] --feature=[feature_id]"
|
||||
|
||||
## Templates & Structures
|
||||
|
||||
### PRD Direction Roadmap Template
|
||||
```markdown
|
||||
# PRD Direction Roadmap: [Brainstorm Session Name]
|
||||
|
||||
**Created:** [Date]
|
||||
**Source:** Brainstorm Session: [Brainstorm Session Name]
|
||||
**Focus:** Phased PRD Development and Improvement Directions
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
- **Overview:** High-level suggestions for PRD development based on brainstorm ideas.
|
||||
- **Key Features:** [Number] prioritized features with phased PRD directions.
|
||||
- **Improvement Approach:** Iterative refinement from concepts to advanced implementations.
|
||||
|
||||
---
|
||||
|
||||
## Feature Suggestions
|
||||
|
||||
### Feature 1: [Feature Name]
|
||||
- **Brainstorm Basis:** [Relevant ideas from brainstorm, e.g., innovative concepts].
|
||||
- **Phased PRD Directions:**
|
||||
- **Phase 1 (Core):** Basic PRD focusing on initial idea validation.
|
||||
- **Phase 2 (Improvement):** Incorporate feedback for refinements.
|
||||
- **Phase 3 (Advanced):** Add scalability and integration ideas.
|
||||
- **Improvement Suggestions:** [e.g., Prototype testing, evolve based on user engagement metrics].
|
||||
|
||||
### Feature 2: [Feature Name]
|
||||
- **Brainstorm Basis:** [Relevant ideas].
|
||||
- **Phased PRD Directions:** [Similar phased structure].
|
||||
- **Improvement Suggestions:** [Specific directions].
|
||||
|
||||
---
|
||||
|
||||
## Overall Improvement Strategy
|
||||
- **Iteration Model:** Use brainstorm feedback to refine PRDs iteratively.
|
||||
- **Prioritization Criteria:** Based on innovation impact and feasibility.
|
||||
- **Success Indicators:** [e.g., Alignment with creative goals, measurable improvements].
|
||||
|
||||
---
|
||||
|
||||
## Next Steps
|
||||
- Create PRD for Feature 1 using suggested directions.
|
||||
- Validate improvements through prototypes or user tests.
|
||||
```
|
||||
|
||||
## Best Practices / DO & DON'T
|
||||
|
||||
### ✅ DO: Focus on Iterative PRD Directions
|
||||
- Emphasize phased approaches that guide PRD evolution from ideas to refinements.
|
||||
- Suggest specific improvement ideas tied to brainstorm concepts.
|
||||
**Why:** This ensures the roadmap drives actionable, evolving PRD creation.
|
||||
|
||||
### ✅ DO: Prioritize Based on Brainstorm Insights
|
||||
- Rank features by creative impact and feasibility from the brainstorm.
|
||||
- Include rationale for each suggestion.
|
||||
**Why:** Maintains alignment with original innovative ideas.
|
||||
|
||||
### ❌ DON'T: Include Timelines or Deadlines
|
||||
- Avoid any time-based planning or horizons.
|
||||
**Why:** Focus solely on directional guidance for PRD development.
|
||||
|
||||
### ❌ DON'T: Add Unnecessary Complexity
|
||||
- Keep suggestions concise and directly tied to PRD phases.
|
||||
**Why:** The goal is to provide clear directions, not over-engineer the roadmap.
|
||||
|
||||
## Output
|
||||
- **Format:** Markdown document.
|
||||
- **Location:** .taskmaster/docs/roadmap/
|
||||
- **Filename:** roadmap-prd-directions_[brainstorm_session_name].md
|
||||
|
||||
## Example Usage
|
||||
- Create PRD direction roadmap from brainstorm session: /planning/roadmap/2-create-from-brainstorm --name="product-features"
|
||||
- Create by brainstorm index: /planning/roadmap/2-create-from-brainstorm --name="1"
|
||||
282
.claude/commands/planning/create-app-design.md
Normal file
282
.claude/commands/planning/create-app-design.md
Normal file
@ -0,0 +1,282 @@
|
||||
---
|
||||
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 .taskmaster/docs/ 2>/dev/null || echo "No .taskmaster/docs 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 .taskmaster/docs/
|
||||
- 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.md` "Project Status" section
|
||||
- Set appropriate DO/DON'T priorities for the stage
|
||||
- Document stage-specific development guidelines
|
||||
|
||||
### 5. Generate Document
|
||||
|
||||
Create comprehensive app design document following the standard structure
|
||||
|
||||
### 6. Save and Organize
|
||||
|
||||
- Create `.taskmaster/docs/` directory if needed
|
||||
- Save as `app-design-document.md`
|
||||
- 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 tech-stack.md document
|
||||
- **Database Schemas:** Keep data models conceptual
|
||||
- **API Specifications:** Focus on capabilities, not endpoints
|
||||
- **Performance Metrics:** Describe goals, not technical benchmarks
|
||||
|
||||
## Output
|
||||
|
||||
- **Format:** Markdown (`.md`)
|
||||
- **Location:** `.taskmaster/docs/`
|
||||
- **Filename:** `app-design-document.md`
|
||||
|
||||
## 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
|
||||
|
||||
```markdown
|
||||
## Project Status
|
||||
|
||||
**Current Stage**: [Stage from user response]
|
||||
|
||||
### DO Care About (Production-Ready Foundation)
|
||||
|
||||
[Stage-specific priorities]
|
||||
|
||||
### DO NOT Care About (Skip for Velocity)
|
||||
|
||||
[Stage-specific items to skip]
|
||||
|
||||
### Development Approach
|
||||
|
||||
[Stage-specific development focus]
|
||||
```
|
||||
|
||||
### 4. Generate Document
|
||||
|
||||
- Follow the standard structure
|
||||
- Tailor content to project stage
|
||||
- Keep language accessible
|
||||
|
||||
### 5. Save and Next Steps
|
||||
|
||||
- Create directory: `mkdir -p .taskmaster/docs`
|
||||
- Save document: `.taskmaster/docs/app-design-document.md`
|
||||
- Suggest: "Would you like me to create a technical stack document next?"
|
||||
51
.claude/commands/planning/create-doc.md
Normal file
51
.claude/commands/planning/create-doc.md
Normal file
@ -0,0 +1,51 @@
|
||||
# Feature Documentation Generator
|
||||
|
||||
When asked to enter "Documentation Mode" for a specific feature, I will:
|
||||
|
||||
1. **Analyze the feature scope**: First, I'll ask 3-5 clarifying questions to understand exactly what feature needs to be documented and its boundaries.
|
||||
|
||||
2. **Review existing documentation**: Before generating new documentation, I'll check and reference these existing guides:
|
||||
|
||||
- Authentication patterns → @.cursor/rules/2106-auth.mdc
|
||||
- CRUD implementation → @.cursor/rules/2105-crud.mdc
|
||||
- Router implementation → @.cursor/rules/2102-router.mdc
|
||||
- Schema definition → @.cursor/rules/2101-schema-prisma.mdc
|
||||
- End-to-end feature specs → @.cursor/rules/2100-spec.mdc
|
||||
- tRPC React Query integration → @.cursor/rules/2103-trpc-react-query.mdc
|
||||
|
||||
3. **Conduct comprehensive codebase exploration**: I'll systematically search for and identify all relevant files and components that contribute to the feature, including:
|
||||
|
||||
- Entry points and main components
|
||||
- State management
|
||||
- API interactions
|
||||
- Utility functions
|
||||
- Types and interfaces
|
||||
- Configuration files
|
||||
|
||||
4. **Generate a structured documentation** with these sections:
|
||||
|
||||
- **Feature Overview**: High-level description of the feature's purpose and functionality
|
||||
- **Core Files Map**: List of essential files with their paths and a brief description of their role
|
||||
- **Data Flow**: How data moves through the system for this feature
|
||||
- **Key Dependencies**: External libraries or internal services the feature relies on
|
||||
- **Configuration Options**: Any configurable aspects of the feature
|
||||
- **Extension Points**: How the feature can be extended or customized
|
||||
- **Implementation References**: Links to relevant sections in existing documentation that were used or should be followed
|
||||
|
||||
5. **Include code snippets** for critical sections with line numbers and file paths in the format:
|
||||
|
||||
```startLine:endLine:filepath
|
||||
// Code snippet here
|
||||
```
|
||||
|
||||
6. **Create a visual representation** of the component hierarchy or data flow if applicable (described in text format that can be converted to a diagram).
|
||||
|
||||
7. **Summarize implementation patterns** used in the feature that should be followed when extending it, referencing existing documentation where applicable:
|
||||
- Authentication patterns if the feature requires protection
|
||||
- CRUD patterns if the feature involves data operations
|
||||
- Error handling patterns
|
||||
- Router implementation patterns
|
||||
- Schema patterns
|
||||
- React Query patterns
|
||||
|
||||
The final documentation will be comprehensive enough that someone could continue development on this feature with minimal additional context beyond the generated document and the referenced existing documentation.
|
||||
116
.claude/commands/planning/create-prd-interactive.md
Normal file
116
.claude/commands/planning/create-prd-interactive.md
Normal file
@ -0,0 +1,116 @@
|
||||
---
|
||||
allowed-tools: Bash, Read, Write, Glob, Grep, Task, TodoWrite, mcp__taskmaster-ai__parse_prd
|
||||
description: Generate a PRD interactively with clarifying questions for complex features
|
||||
---
|
||||
|
||||
# Generate a Product Requirements Document (PRD)
|
||||
|
||||
## Context
|
||||
|
||||
- **User Request:** $ARGUMENTS
|
||||
- **Project Root:** !`pwd`
|
||||
- **Existing PRDs:** !`ls -la .taskmaster/docs/prd-*.md 2>/dev/null || echo "No existing PRDs found"`
|
||||
- **Project Status:** @CLAUDE.md#project-status
|
||||
- **Tech Stack:** @.taskmaster/docs/tech-stack.md
|
||||
- **Project Structure:** !`bash .claude/scripts/tree.sh`
|
||||
- **PRD Template:** @.taskmaster/templates/example_prd.md
|
||||
|
||||
## Goal
|
||||
|
||||
To create a detailed Product Requirements Document (PRD) in Markdown format. The PRD should be clear, actionable, and suitable for a junior developer to understand and implement.
|
||||
|
||||
## Process
|
||||
|
||||
1. **Analyze Feature Request:** Think deeply about the user's feature request and its implications for the codebase.
|
||||
|
||||
2. **Codebase Analysis:**
|
||||
|
||||
- Search for relevant existing code patterns
|
||||
- Review components that might be affected
|
||||
- Identify potential integration points
|
||||
- Consider architectural impacts
|
||||
|
||||
3. **Ask Clarifying Questions:**
|
||||
|
||||
- Ask 4-6 targeted questions based on codebase analysis
|
||||
- Provide lettered/numbered options for easy response
|
||||
- Focus on understanding the "what" and "why", not the "how"
|
||||
|
||||
4. **Generate PRD:**
|
||||
|
||||
- Follow the example PRD structure exactly
|
||||
- Include all required sections from the template
|
||||
- Ensure clarity for junior developers
|
||||
|
||||
5. **Save and Next Steps:**
|
||||
- Save as `prd-[feature-name].md` in `.taskmaster/docs/`
|
||||
- Suggest running Task Master parse command
|
||||
|
||||
## Clarifying Questions Framework
|
||||
|
||||
Adapt questions based on the specific feature request provided above. Consider these areas:
|
||||
|
||||
- **Problem/Goal:** "What problem does this feature solve for the user?" or "What is the main goal we want to achieve with this feature?"
|
||||
- **Target User:** "Who is the primary user of this feature?"
|
||||
- **Core Functionality:** "Can you describe the key actions a user should be able to perform with this feature?"
|
||||
- **User Stories:** "Could you provide a few user stories? (e.g., As a [type of user], I want to [perform an action] so that [benefit].)"
|
||||
- **User Experience:** "Describe the user journey and key user flows for this feature"
|
||||
- **Scope/Boundaries:** "Are there any specific things this feature _should not_ do (non-goals)?"
|
||||
- **Technical Integration:** "What existing systems or components should this integrate with?"
|
||||
- **Data Requirements:** "What kind of data does this feature need to display or manipulate?"
|
||||
- **Design/UI:** "Are there any existing design patterns or UI guidelines to follow?" or "Can you describe the desired look and feel?"
|
||||
- **Development Phases:** "Should this be built in phases? What's the MVP vs future enhancements?"
|
||||
- **Dependencies:** "What needs to be built first? Are there logical dependencies?"
|
||||
- **Success Criteria:** "How will we know when this feature is successfully implemented?"
|
||||
- **Edge Cases:** "Are there any potential risks or technical challenges we should consider?"
|
||||
|
||||
## PRD Structure Requirements
|
||||
|
||||
The PRD must follow the exact structure from @.taskmaster/templates/example_prd.md:
|
||||
|
||||
### `<context>` Section
|
||||
|
||||
1. **Overview:** High-level overview of the product/feature, what problem it solves, who it's for, and why it's valuable
|
||||
2. **Project Context:** Include the standard project status information. CRITICIAL: DO NOT forget this section. Read the mentioned files if needed.
|
||||
3. **Core Features:** List and describe the main features, including what each does, why it's important, and how it works at a high level
|
||||
4. **User Experience:** Describe user personas, key user flows, and UI/UX considerations
|
||||
|
||||
### `<PRD>` Section
|
||||
|
||||
1. **Technical Architecture:** System components, data models, APIs and integrations, infrastructure requirements
|
||||
2. **Development Roadmap:** Break down into phases (MVP requirements, future enhancements) focusing on scope and detailing exactly what needs to be built
|
||||
3. **Logical Dependency Chain:** Define the logical order of development, which features need to be built first, getting quickly to something usable/visible, properly pacing and scoping each feature
|
||||
4. **Risks and Mitigations:** Technical challenges, figuring out the MVP that can be built upon, resource constraints
|
||||
5. **Appendix:** Research findings, technical specifications, additional information
|
||||
|
||||
## Target Audience
|
||||
|
||||
Assume the primary reader of the PRD is a **junior developer**. Therefore, requirements should be explicit, unambiguous, and avoid jargon where possible. Provide enough detail for them to understand the feature's purpose and core logic.
|
||||
|
||||
## Output
|
||||
|
||||
- **Format:** Markdown (`.md`)
|
||||
- **Location:** `.taskmaster/docs/`
|
||||
- **Filename:** `prd-[feature-name].md`
|
||||
|
||||
## Final Instructions
|
||||
|
||||
1. **Think deeply** about the feature request and its architectural implications
|
||||
2. **Do NOT start implementing** - only create the PRD document
|
||||
3. **Ask clarifying questions** with lettered/numbered options
|
||||
4. **Generate complete PRD** following the template structure exactly
|
||||
5. **Save the PRD** to `.taskmaster/docs/prd-[feature-name].md`
|
||||
6. **Suggest next step:** "Use `/parse` or `task-master parse-prd .taskmaster/docs/prd-[feature-name].md` to convert this PRD into Task Master tasks"
|
||||
|
||||
## Example Usage
|
||||
|
||||
```
|
||||
/project:prd user authentication system
|
||||
```
|
||||
|
||||
This will:
|
||||
|
||||
1. Analyze the codebase for existing auth patterns
|
||||
2. Ask questions about auth requirements
|
||||
3. Generate a comprehensive PRD
|
||||
4. Save it as `prd-user-authentication.md`
|
||||
230
.claude/commands/planning/create-prd.md
Normal file
230
.claude/commands/planning/create-prd.md
Normal file
@ -0,0 +1,230 @@
|
||||
---
|
||||
allowed-tools: [Read, Write, Glob, Grep, Bash, Task, TodoWrite]
|
||||
description: Creates a PRD document compatible with Task Master's parse-prd command, with quick and interactive modes
|
||||
---
|
||||
|
||||
# Create PRD for Task Master
|
||||
|
||||
## Context
|
||||
- **User Request:** $ARGUMENTS
|
||||
- **Mode:** Extract from arguments using `--quick` flag (default: interactive)
|
||||
- **Source Type (optional):** Extract from arguments using `--source=[mrd|brainstorm|roadmap|scratch]`
|
||||
- **Source Name (optional):** Extract from arguments using `--name=[session-name]`
|
||||
- **Project Root:** !`pwd`
|
||||
- **Existing PRDs:** !`ls -la .taskmaster/docs/prd-*.md 2>/dev/null || echo "No existing PRDs found"`
|
||||
- **Project Status:** @CLAUDE.md#project-status
|
||||
- **Project Structure:** !`bash .claude/scripts/tree.sh`
|
||||
- **Tech Stack:** @.taskmaster/docs/tech-stack.md
|
||||
- **PRD Template:** @.taskmaster/templates/example_prd.md
|
||||
- **PRD Directory:** `.taskmaster/docs/`
|
||||
|
||||
## Goal
|
||||
Create a concise, focused Product Requirements Document (PRD) that Task Master can parse to generate tasks.json. Supports two modes:
|
||||
- **Quick Mode (`--quick`)**: Generate PRD immediately without questions, making intelligent assumptions
|
||||
- **Interactive Mode (default)**: Ask clarifying questions for more accurate requirements gathering
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Parse Arguments and Determine Mode
|
||||
- Extract `--quick`, `--source`, and `--name` from user arguments
|
||||
- Determine mode: Quick (no questions) or Interactive (with questions)
|
||||
- If source specified, validate it exists
|
||||
|
||||
### 2. Codebase Analysis (Both Modes)
|
||||
**Think deeply** about the project context:
|
||||
- Search for relevant existing code patterns
|
||||
- Review components that might be affected
|
||||
- Identify potential integration points
|
||||
- Consider architectural impacts
|
||||
- Analyze tech stack and project structure
|
||||
|
||||
### 3A. Quick Mode Process (`--quick`)
|
||||
If quick mode is enabled:
|
||||
- **Make intelligent assumptions** based on common patterns and codebase analysis
|
||||
- **Load source content** if specified (MRD, Brainstorm, Roadmap)
|
||||
- **Generate PRD immediately** without asking questions
|
||||
- **Document all assumptions** in a dedicated section
|
||||
- **Skip to step 4** (Generate PRD Document)
|
||||
|
||||
### 3B. Interactive Mode Process (Default)
|
||||
If interactive mode (no `--quick` flag):
|
||||
- **Load source content** if specified:
|
||||
- **MRD**: Load from `.taskmaster/docs/mrd/[name]/` - focus on market requirements
|
||||
- **Brainstorm**: Load from `.taskmaster/docs/brainstorm/[name]/` - focus on creative ideas
|
||||
- **Roadmap**: Load from `.taskmaster/docs/roadmap/[name]/` - focus on timeline, priorities
|
||||
- **Scratch**: Start fresh with Q&A
|
||||
- **Ask focused questions** to gather essential information:
|
||||
- **Project Status**: Pre-MVP, MVP, Production, or Enterprise?
|
||||
- **Core Problem**: What problem does this solve?
|
||||
- **Target Users**: Who will use this?
|
||||
- **Key Features**: What are the 3-5 core features?
|
||||
- **Technical Approach**: High-level architecture approach?
|
||||
- **MVP Scope**: What's the minimum viable version?
|
||||
|
||||
### 4. Generate PRD Document
|
||||
Create PRD following Task Master template structure exactly:
|
||||
|
||||
**Important:** Follow the exact structure from @.taskmaster/templates/example_prd.md
|
||||
|
||||
#### PRD Structure:
|
||||
```markdown
|
||||
<context>
|
||||
# Overview
|
||||
[High-level overview of the product/feature, what problem it solves, who it's for, and why it's valuable]
|
||||
|
||||
# Project Context
|
||||
**Project Status: [Stage]**
|
||||
|
||||
- Read this file: `.taskmaster/docs/app-design-document.md` - App design document
|
||||
- Read this file: `.taskmaster/docs/tech-stack.md` - Tech stack, architecture
|
||||
[Stage-appropriate DO/DON'T guidelines based on project status]
|
||||
|
||||
# Core Features
|
||||
[List and describe main features - what each does, why it's important, how it works at high level]
|
||||
|
||||
# User Experience
|
||||
[User personas, key user flows, UI/UX considerations]
|
||||
</context>
|
||||
<PRD>
|
||||
|
||||
# Technical Architecture
|
||||
[System components, data models, APIs and integrations, infrastructure requirements]
|
||||
|
||||
# Development Roadmap
|
||||
## MVP Phase
|
||||
[Essential features for first usable version]
|
||||
|
||||
## Enhancement Phase
|
||||
[Additional features and improvements]
|
||||
|
||||
## Scale Phase
|
||||
[Performance, security, and scale features]
|
||||
|
||||
# Logical Dependency Chain
|
||||
[Development order - what needs to be built first, getting quickly to something usable/visible, properly pacing and scoping each feature]
|
||||
|
||||
# Risks and Mitigations
|
||||
[Technical challenges, figuring out MVP that can be built upon, resource constraints]
|
||||
|
||||
# Appendix
|
||||
[Research findings, technical specifications, additional information]
|
||||
</PRD>
|
||||
```
|
||||
|
||||
#### For Quick Mode Only:
|
||||
Include an "Assumptions" section immediately after the `<context>` opening tag:
|
||||
```markdown
|
||||
<context>
|
||||
# Assumptions
|
||||
[Document key assumptions made about requirements, default choices for ambiguous features, suggested areas that may need refinement]
|
||||
|
||||
# Overview
|
||||
[Continue with normal structure...]
|
||||
```
|
||||
|
||||
### 5. Save PRD and Guide Next Steps
|
||||
- Save to `.taskmaster/docs/prd-[name].md`
|
||||
- Suggest next steps:
|
||||
```
|
||||
PRD created successfully! Next steps:
|
||||
1. Review: `.taskmaster/docs/prd-[name].md`
|
||||
2. Generate tasks: `task-master parse-prd .taskmaster/docs/prd-[name].md`
|
||||
3. Or use tagged workflow:
|
||||
- `task-master add-tag [feature-name] --description="[description]"`
|
||||
- `task-master use-tag [feature-name]`
|
||||
- `task-master parse-prd .taskmaster/docs/prd-[name].md`
|
||||
```
|
||||
|
||||
## Mode Selection Guide
|
||||
|
||||
### ✅ Use Quick Mode (`--quick`) for:
|
||||
- **Simple CRUD features** - Standard create/read/update/delete operations
|
||||
- **Standard UI components** - Common interface elements with clear patterns
|
||||
- **Well-defined integrations** - Integrations with clear API specifications
|
||||
- **Features with precedent** - Similar features already exist in the codebase
|
||||
- **Time-sensitive requests** - When you need a PRD quickly to start development
|
||||
|
||||
### ✅ Use Interactive Mode (default) for:
|
||||
- **Complex architectural changes** - Features affecting system design
|
||||
- **Features with unknowns** - Requirements that need clarification
|
||||
- **Security-critical features** - Features requiring detailed security analysis
|
||||
- **Multi-system features** - Features affecting multiple systems or teams
|
||||
- **First-time implementations** - New types of features without existing patterns
|
||||
|
||||
## Best Practices
|
||||
|
||||
### ✅ DO: Keep It Focused
|
||||
- **Write concise, actionable content** that translates directly to development tasks
|
||||
- **Focus on what to build**, not extensive market analysis or business justification
|
||||
- **Use clear feature descriptions** that developers can implement
|
||||
- **Define logical dependencies** to guide development order
|
||||
|
||||
**Why:** Task Master needs clear, implementable requirements to generate meaningful tasks.
|
||||
|
||||
### ✅ DO: Think in Development Phases
|
||||
- **Start with true MVP** - the minimum that provides value
|
||||
- **Build incrementally** - each phase should be independently valuable
|
||||
- **Consider dependencies** - what needs to be built first?
|
||||
- **Keep phases balanced** - avoid too much in one phase
|
||||
|
||||
**Why:** Phased development ensures continuous delivery and reduces risk.
|
||||
|
||||
### ❌ DON'T: Over-Document
|
||||
- **Don't write lengthy market analysis** - keep context brief
|
||||
- **Don't create complex user journeys** - focus on core flows
|
||||
- **Don't specify implementation details** - that's for tasks
|
||||
- **Don't include project management details** - timelines, resources, etc.
|
||||
|
||||
**Why:** PRDs should be requirements documents, not project plans or technical specifications.
|
||||
|
||||
### ❌ DON'T: Create Without Purpose
|
||||
- **Don't generate PRDs for trivial features** - just create tasks directly
|
||||
- **Don't duplicate existing PRDs** - update instead
|
||||
- **Don't create multiple PRDs for one feature** - keep it consolidated
|
||||
- **Don't forget the parse step** - PRDs need to be parsed to be useful
|
||||
|
||||
**Why:** PRDs are for substantial features that need structured planning.
|
||||
|
||||
## Output
|
||||
- **Format:** Markdown (.md) following Task Master template
|
||||
- **Location:** `.taskmaster/docs/`
|
||||
- **Filename:** `prd-[descriptive-name].md`
|
||||
|
||||
## Example Usage
|
||||
|
||||
### Interactive Mode (Default)
|
||||
```bash
|
||||
# Create PRD from scratch with questions
|
||||
/planning/prd/create new payment system
|
||||
|
||||
# Create PRD from MRD with questions
|
||||
/planning/prd/create --source=mrd --name=mvp-launch payment features
|
||||
|
||||
# Create PRD from brainstorm with questions
|
||||
/planning/prd/create --source=brainstorm --name=feature-ideas user dashboard
|
||||
|
||||
# Create PRD from roadmap with questions
|
||||
/planning/prd/create --source=roadmap --name=q1-2024 phase 1 features
|
||||
```
|
||||
|
||||
### Quick Mode
|
||||
```bash
|
||||
# Create PRD immediately without questions
|
||||
/planning/prd/create --quick user profile page with avatar upload
|
||||
|
||||
# Quick PRD from MRD
|
||||
/planning/prd/create --quick --source=mrd --name=mvp-launch payment features
|
||||
|
||||
# Quick PRD from brainstorm
|
||||
/planning/prd/create --quick --source=brainstorm --name=feature-ideas dashboard
|
||||
|
||||
# Quick PRD from roadmap
|
||||
/planning/prd/create --quick --source=roadmap --name=q1-2024 auth system
|
||||
```
|
||||
|
||||
## Quick Mode Benefits
|
||||
- **Immediate Results**: No waiting for Q&A session
|
||||
- **Intelligent Assumptions**: Based on codebase analysis and common patterns
|
||||
- **Documented Assumptions**: Clear record of what was assumed for later refinement
|
||||
- **Codebase-Informed**: Leverages existing patterns and architectural decisions
|
||||
- **Fast Iteration**: Quickly generate PRDs for multiple features
|
||||
260
.claude/commands/planning/create-rule.md
Normal file
260
.claude/commands/planning/create-rule.md
Normal file
@ -0,0 +1,260 @@
|
||||
---
|
||||
allowed-tools: Read, Glob, Grep, Write, MultiEdit, TodoWrite, Bash
|
||||
description: Create a new Cursor rule file with proper structure and conventions
|
||||
---
|
||||
|
||||
# Create Cursor Rule
|
||||
|
||||
**User Request:** $ARGUMENTS
|
||||
|
||||
## Context
|
||||
|
||||
- Rules directory: !`ls -la .cursor/rules/*.mdc 2>/dev/null | wc -l | xargs -I {} echo "{} existing rules"`
|
||||
- Existing rules: !`ls -1 .cursor/rules/*.mdc 2>/dev/null | sed 's/.*\///' | head -10 || echo "No rules yet"`
|
||||
- Rule guidelines: @.cursor/rules/cursor-rules.mdc
|
||||
|
||||
## Goal
|
||||
|
||||
Create a new Cursor rule file that follows the established conventions and structure. The rule should be actionable, well-documented, and reference actual code patterns from the codebase.
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Analyze Rule Request
|
||||
|
||||
**Think deeply about what patterns or conventions this rule should enforce.**
|
||||
|
||||
Consider:
|
||||
|
||||
- What problem does this rule solve?
|
||||
- What patterns should it enforce?
|
||||
- What anti-patterns should it prevent?
|
||||
- Which files or areas of code does it apply to?
|
||||
- Are there existing examples in the codebase?
|
||||
|
||||
### 2. Search for Patterns
|
||||
|
||||
Search the codebase for:
|
||||
|
||||
- Existing implementations to reference
|
||||
- Common patterns that need standardization
|
||||
- Anti-patterns to discourage
|
||||
- Related code that demonstrates the rule
|
||||
|
||||
### 3. Interactive Rule Design
|
||||
|
||||
Ask clarifying questions about:
|
||||
|
||||
- Specific file patterns (globs)
|
||||
- When the rule should apply
|
||||
- Exceptions or edge cases
|
||||
- Related existing rules
|
||||
|
||||
### 4. Generate Rule File
|
||||
|
||||
Create comprehensive rule following the standard structure:
|
||||
|
||||
- YAML frontmatter
|
||||
- Clear description
|
||||
- Actionable requirements
|
||||
- Code examples
|
||||
- File references
|
||||
|
||||
### 5. Save and Cross-Reference
|
||||
|
||||
- Save to `.cursor/rules/[rule-name].mdc`
|
||||
- Update related rules if needed
|
||||
- Update CLAUDE.md to reference new rule in Core Rules section
|
||||
- Suggest next steps
|
||||
|
||||
## Rule Creation Questions
|
||||
|
||||
### 📋 Rule Definition
|
||||
|
||||
**1. What is the primary purpose of this rule?**
|
||||
|
||||
Please describe what convention, pattern, or standard this rule should enforce.
|
||||
|
||||
**2. Which files should this rule apply to?**
|
||||
|
||||
a) **Specific file types** - `*.ts`, `*.tsx`, etc.
|
||||
b) **Directory patterns** - `src/components/**/*`, `app/**/*`
|
||||
c) **Framework files** - Route handlers, API endpoints, etc.
|
||||
d) **Configuration files** - `*.config.ts`, setup files
|
||||
e) **All files** - Universal convention
|
||||
|
||||
**3. Should this rule always apply or conditionally?**
|
||||
|
||||
a) **Always apply** - Enforced on every matching file
|
||||
b) **Conditional** - Only when certain patterns exist
|
||||
c) **Opt-in** - Developers choose when to apply
|
||||
|
||||
### 🔍 Pattern Examples
|
||||
|
||||
**4. Can you provide examples of GOOD patterns to follow?**
|
||||
|
||||
Share code snippets or describe the correct implementation.
|
||||
|
||||
**5. What are BAD patterns to avoid?**
|
||||
|
||||
Share anti-patterns or common mistakes this rule should prevent.
|
||||
|
||||
**6. Are there existing files that demonstrate this pattern well?**
|
||||
|
||||
List files that already follow this convention correctly.
|
||||
|
||||
### 🔗 Related Rules
|
||||
|
||||
**7. Does this rule relate to any existing conventions?**
|
||||
|
||||
a) **Extends existing rule** - Builds on another rule
|
||||
b) **Complements rule** - Works alongside another
|
||||
c) **Replaces rule** - Supersedes an outdated rule
|
||||
d) **Standalone** - Independent convention
|
||||
|
||||
## Rule Structure Template
|
||||
|
||||
````markdown
|
||||
---
|
||||
description: [Clear, one-line description of what the rule enforces]
|
||||
globs: [path/to/files/*.ext, other/path/**/*]
|
||||
alwaysApply: [true/false]
|
||||
---
|
||||
|
||||
# [Rule Title]
|
||||
|
||||
## Overview
|
||||
|
||||
[Brief explanation of why this rule exists and what problem it solves]
|
||||
|
||||
## Requirements
|
||||
|
||||
- **[Requirement Category]:**
|
||||
- [Specific requirement]
|
||||
- [Another requirement]
|
||||
- [Edge cases or exceptions]
|
||||
|
||||
## Examples
|
||||
|
||||
### ✅ DO: [Good Pattern Name]
|
||||
|
||||
```[language]
|
||||
// Example of correct implementation
|
||||
[code example]
|
||||
```
|
||||
````
|
||||
|
||||
**Why:** [Explanation of why this is the right approach]
|
||||
|
||||
### ❌ DON'T: [Anti-pattern Name]
|
||||
|
||||
```[language]
|
||||
// Example of what to avoid
|
||||
[code example]
|
||||
```
|
||||
|
||||
**Why:** [Explanation of why this should be avoided]
|
||||
|
||||
## File References
|
||||
|
||||
- Good examples: [component.tsx](mdc:src/components/example/component.tsx)
|
||||
- Pattern usage: [api-handler.ts](mdc:app/api/example/route.ts)
|
||||
|
||||
## Related Rules
|
||||
|
||||
- [other-rule.mdc](mdc:.cursor/rules/other-rule.mdc) - [How it relates]
|
||||
- [another-rule.mdc](mdc:.cursor/rules/another-rule.mdc) - [How it relates]
|
||||
|
||||
## Migration Guide
|
||||
|
||||
[If applicable, how to migrate existing code to follow this rule]
|
||||
|
||||
1. [Step 1]
|
||||
2. [Step 2]
|
||||
3. [Step 3]
|
||||
|
||||
````
|
||||
|
||||
## Execution Steps
|
||||
|
||||
### 1. Initial Analysis
|
||||
|
||||
```bash
|
||||
# Search for relevant patterns
|
||||
rg -t ts -t tsx "[pattern]" --glob "!node_modules"
|
||||
|
||||
# Find files that might need this rule
|
||||
find . -name "*.tsx" -path "*/components/*" | head -20
|
||||
````
|
||||
|
||||
**Think deeply about:** "What patterns in the codebase would benefit from standardization? What mistakes do developers commonly make that this rule could prevent?"
|
||||
|
||||
### 2. Pattern Discovery
|
||||
|
||||
- Use Grep to find existing patterns
|
||||
- Use Read to examine good examples
|
||||
- Identify variations that need standardization
|
||||
|
||||
### 3. Interactive Design
|
||||
|
||||
- Ask clarifying questions
|
||||
- Get specific examples
|
||||
- Understand edge cases
|
||||
|
||||
### 4. Rule Generation
|
||||
|
||||
- Follow the template structure
|
||||
- Include real code examples
|
||||
- Reference actual files
|
||||
- Connect to related rules
|
||||
|
||||
### 5. Save and Integrate
|
||||
|
||||
```bash
|
||||
# Create rule file
|
||||
# Save to .cursor/rules/[rule-name].mdc
|
||||
|
||||
# Show related rules
|
||||
ls -la .cursor/rules/*.mdc | grep -E "(related|similar)"
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
### DO:
|
||||
|
||||
- **Real Examples:** Use actual code from the project
|
||||
- **Clear Globs:** Specific file patterns, not overly broad
|
||||
- **Actionable:** Developers should know exactly what to do
|
||||
- **Justification:** Explain WHY not just WHAT
|
||||
- **Cross-Reference:** Link to related rules and examples
|
||||
|
||||
### DON'T:
|
||||
|
||||
- **Theoretical:** Avoid hypothetical examples
|
||||
- **Vague:** Don't use unclear descriptions
|
||||
- **Overly Broad:** Don't apply to all files unless necessary
|
||||
- **Redundant:** Don't duplicate existing rules
|
||||
- **Complex:** Keep rules focused on one concept
|
||||
|
||||
## Output
|
||||
|
||||
- **Format:** Markdown with `.mdc` extension
|
||||
- **Location:** `.cursor/rules/`
|
||||
- **Filename:** `[descriptive-name].mdc`
|
||||
|
||||
## Example Usage
|
||||
|
||||
```
|
||||
/project:rules:create component naming conventions
|
||||
|
||||
/project:rules:create API error handling patterns
|
||||
```
|
||||
|
||||
## Next Steps
|
||||
|
||||
After creating the rule:
|
||||
|
||||
1. Review existing code for compliance
|
||||
2. Update non-compliant code if needed
|
||||
3. Add to code review checklist
|
||||
4. Update CLAUDE.md Core Rules section to reference the new rule
|
||||
5. Share with team
|
||||
346
.claude/commands/planning/create-tech-stack.md
Normal file
346
.claude/commands/planning/create-tech-stack.md
Normal file
@ -0,0 +1,346 @@
|
||||
---
|
||||
allowed-tools: Read, Glob, Grep, Write, MultiEdit, TodoWrite, Bash
|
||||
description: Generate comprehensive technical stack documentation from codebase analysis
|
||||
---
|
||||
|
||||
# Generate Tech Stack Documentation
|
||||
|
||||
**User Request:** $ARGUMENTS
|
||||
|
||||
## Context
|
||||
|
||||
- Project root: !`pwd`
|
||||
- Package.json: @package.json
|
||||
- Node version: !`node --version 2>/dev/null || echo "Node.js not found"`
|
||||
- TypeScript config: @tsconfig.json
|
||||
- Database schema: !`ls -la prisma/schema.prisma 2>/dev/null || echo "No Prisma schema found"`
|
||||
- Existing docs: !`ls -la .taskmaster/docs/*.md 2>/dev/null || echo "No docs yet"`
|
||||
|
||||
## Goal
|
||||
|
||||
Create comprehensive Tech Stack Documentation based on deep codebase analysis. Document all technologies, frameworks, libraries, development tools, deployment strategies, and implementation patterns with specific versions and configurations.
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Automated Technical Discovery
|
||||
|
||||
- Parse package.json for all dependencies
|
||||
- Analyze configuration files (tsconfig, vite.config, next.config, etc.)
|
||||
- Detect database setup (Prisma, Drizzle, TypeORM, etc.)
|
||||
- Identify testing frameworks and tools
|
||||
- Scan for CI/CD configurations
|
||||
- Check deployment configurations
|
||||
|
||||
### 2. Deep Code Analysis
|
||||
|
||||
Examine codebase for:
|
||||
|
||||
- **Architecture Patterns:** Monorepo structure, module organization
|
||||
- **Framework Usage:** Next.js app router vs pages, API routes
|
||||
- **State Management:** Zustand, Redux, Context API patterns
|
||||
- **Styling Approach:** Tailwind, CSS modules, styled-components
|
||||
- **Type Safety:** TypeScript strictness, validation libraries
|
||||
- **API Design:** REST, GraphQL, tRPC implementation
|
||||
- **Authentication:** Auth libraries and session management
|
||||
- **Testing Strategy:** Unit, integration, E2E test patterns
|
||||
|
||||
### 3. Interactive Technical Q&A
|
||||
|
||||
Ask 4-6 deployment and infrastructure questions:
|
||||
|
||||
- Use numbered/lettered options
|
||||
- Focus on non-discoverable information
|
||||
- Gather hosting, monitoring, and workflow details
|
||||
|
||||
### 4. Generate Comprehensive Documentation
|
||||
|
||||
Create detailed tech stack document with:
|
||||
|
||||
- Specific version numbers
|
||||
- Configuration examples
|
||||
- Command references
|
||||
- Architecture diagrams (when applicable)
|
||||
|
||||
### 5. Save and Organize
|
||||
|
||||
- Create `.taskmaster/docs/` if needed
|
||||
- Save as `tech-stack.md`
|
||||
- Update CLAUDE.md commands section
|
||||
|
||||
## Technical Questions Template
|
||||
|
||||
### 🚀 Deployment & Infrastructure
|
||||
|
||||
**1. Where is your application currently deployed?**
|
||||
|
||||
a) **Vercel** - Next.js optimized hosting
|
||||
b) **AWS** - EC2, Lambda, or containerized
|
||||
c) **Railway/Render** - Modern PaaS providers
|
||||
d) **Self-hosted** - VPS or on-premise
|
||||
e) **Other** - Please specify
|
||||
f) **Not deployed yet** - Still in development
|
||||
|
||||
**2. How is your database hosted?**
|
||||
|
||||
a) **Managed service** (Supabase, PlanetScale, Neon, etc.)
|
||||
b) **Cloud provider** (AWS RDS, Google Cloud SQL, etc.)
|
||||
c) **Self-hosted** (Docker, VPS, etc.)
|
||||
d) **Local only** - No production database yet
|
||||
|
||||
### 📊 Monitoring & Operations
|
||||
|
||||
**3. What observability tools do you use?**
|
||||
|
||||
a) **Error tracking:** Sentry, Rollbar, Bugsnag
|
||||
b) **Analytics:** Vercel Analytics, Google Analytics, Plausible
|
||||
c) **Monitoring:** Datadog, New Relic, custom solution
|
||||
d) **Logging:** CloudWatch, LogTail, custom logs
|
||||
e) **None yet** - Planning to add later
|
||||
|
||||
### 👥 Development Workflow
|
||||
|
||||
**4. What's your Git workflow?**
|
||||
|
||||
a) **Feature branches** with PR reviews
|
||||
b) **Trunk-based** development
|
||||
c) **GitFlow** with release branches
|
||||
d) **Direct to main** (solo project)
|
||||
|
||||
**5. How do you manage environments?**
|
||||
|
||||
a) **Multiple deployments** (dev, staging, prod)
|
||||
b) **Preview deployments** for PRs
|
||||
c) **Single production** environment
|
||||
d) **Local development** only
|
||||
|
||||
### 🔐 Additional Services
|
||||
|
||||
**6. Which external services do you integrate with?**
|
||||
|
||||
- [ ] Payment processing (Stripe, PayPal)
|
||||
- [ ] Email service (SendGrid, Resend, AWS SES)
|
||||
- [ ] File storage (S3, Cloudinary, UploadThing)
|
||||
- [ ] Authentication (Auth0, Clerk, Supabase Auth)
|
||||
- [ ] Search (Algolia, Elasticsearch)
|
||||
- [ ] Other APIs (please specify)
|
||||
|
||||
## Document Structure
|
||||
|
||||
The generated document must follow this technical structure:
|
||||
|
||||
### **Overview**
|
||||
|
||||
- Brief description of the application's technical nature
|
||||
- Technology stack summary
|
||||
- Architecture approach (monolith, microservices, etc.)
|
||||
|
||||
### **Programming Language & Runtime**
|
||||
|
||||
- Primary programming language and version
|
||||
- Runtime environment and version
|
||||
- Type system and language features used
|
||||
|
||||
### **Frontend**
|
||||
|
||||
- UI Framework/Library and version
|
||||
- Styling approach and frameworks
|
||||
- Component libraries and design systems
|
||||
- State management solutions
|
||||
- Build tools and bundlers
|
||||
- Browser support and compatibility
|
||||
|
||||
### **Backend**
|
||||
|
||||
- Backend framework and architecture
|
||||
- API design (REST, GraphQL, tRPC, etc.)
|
||||
- Authentication and authorization
|
||||
- Middleware and security
|
||||
- File handling and uploads
|
||||
|
||||
### **Database & Storage**
|
||||
|
||||
- Database type and version
|
||||
- ORM/Query builder
|
||||
- Schema management and migrations
|
||||
- Caching solutions
|
||||
- File storage solutions
|
||||
- Data backup and recovery
|
||||
|
||||
### **Development Tools & Workflow**
|
||||
|
||||
- Package manager
|
||||
- Code formatting and linting
|
||||
- Type checking and compilation
|
||||
- Testing frameworks and strategies
|
||||
- Development server and hot reload
|
||||
- Version control workflow
|
||||
|
||||
### **Deployment & Infrastructure**
|
||||
|
||||
- Hosting platform and services
|
||||
- Build and deployment pipeline
|
||||
- Environment configuration
|
||||
- Domain and DNS management
|
||||
- SSL/TLS and security
|
||||
- Monitoring and logging
|
||||
|
||||
### **External Integrations**
|
||||
|
||||
- Third-party APIs and services
|
||||
- Payment processing
|
||||
- Email services
|
||||
- Analytics and tracking
|
||||
- Error monitoring
|
||||
- Performance monitoring
|
||||
|
||||
### **Quality Assurance & Testing**
|
||||
|
||||
- Testing strategy and frameworks
|
||||
- Code coverage tools
|
||||
- End-to-end testing
|
||||
- Performance testing
|
||||
- Security testing
|
||||
- Code review process
|
||||
|
||||
|
||||
### **Schemas & Data Models**
|
||||
|
||||
- Database schema (if applicable)
|
||||
- API schemas and validation
|
||||
- Type definitions and interfaces
|
||||
- Data relationships and constraints
|
||||
|
||||
## Target Audience
|
||||
|
||||
The document should serve:
|
||||
|
||||
- **Developers** joining the project who need technical onboarding
|
||||
- **DevOps engineers** setting up infrastructure and deployment
|
||||
- **Technical architects** evaluating or improving the tech stack
|
||||
- **Security teams** understanding the technical landscape
|
||||
- **Future maintainers** who need to understand technical decisions
|
||||
|
||||
The language should be technical, precise, and include specific version numbers and configuration details.
|
||||
|
||||
## Documentation Principles
|
||||
|
||||
### DO Include:
|
||||
|
||||
- **Exact Versions:** Lock file versions, not just ranges
|
||||
- **Configuration Examples:** Actual config snippets from the project
|
||||
- **Command Reference:** All npm scripts and their purposes
|
||||
- **Setup Instructions:** Step-by-step for new developers
|
||||
- **Architecture Decisions:** Why specific technologies were chosen
|
||||
- **Integration Details:** How services connect and communicate
|
||||
|
||||
### DON'T Include:
|
||||
|
||||
- **Generic Descriptions:** Avoid Wikipedia-style explanations
|
||||
- **Outdated Information:** Only document what's actually used
|
||||
- **Wishful Thinking:** Document current state, not future plans
|
||||
- **Sensitive Data:** No API keys, secrets, or credentials
|
||||
- **Redundant Info:** Link to official docs instead of copying
|
||||
|
||||
## Output
|
||||
|
||||
- **Format:** Markdown (`.md`)
|
||||
- **Location:** `.taskmaster/docs/`
|
||||
- **Filename:** `tech-stack.md`
|
||||
|
||||
## Execution Steps
|
||||
|
||||
### 1. Automated Analysis Phase
|
||||
|
||||
```bash
|
||||
# Extract key technical information
|
||||
- Read package.json and lock files
|
||||
- Scan for configuration files
|
||||
- Detect framework patterns
|
||||
- Identify database setup
|
||||
- Find test configurations
|
||||
```
|
||||
|
||||
### 2. Manual Discovery Phase
|
||||
|
||||
- Read key source files to understand architecture
|
||||
- Check for API route patterns
|
||||
- Analyze authentication implementation
|
||||
- Review deployment configurations
|
||||
|
||||
### 3. Interactive Q&A
|
||||
|
||||
- Present deployment and infrastructure questions
|
||||
- Use checkboxes for multi-select options
|
||||
- Wait for user responses
|
||||
|
||||
### 4. Document Generation
|
||||
|
||||
- Start with discovered information
|
||||
- Incorporate user responses
|
||||
- Add specific configuration examples
|
||||
- Include all npm scripts with descriptions
|
||||
|
||||
### 5. Save and Update
|
||||
|
||||
```bash
|
||||
# Create directory and save
|
||||
mkdir -p .taskmaster/docs
|
||||
# Save to .taskmaster/docs/tech-stack.md
|
||||
```
|
||||
|
||||
### 6. Update CLAUDE.md
|
||||
|
||||
Add discovered commands to the Commands section:
|
||||
|
||||
```markdown
|
||||
### Development
|
||||
|
||||
- `pnpm dev` - Start development server
|
||||
- `pnpm build` - Build for production
|
||||
- `pnpm typecheck` - Run TypeScript type checking
|
||||
|
||||
# ... other discovered commands
|
||||
```
|
||||
|
||||
### 7. Next Steps
|
||||
|
||||
- Suggest: "Would you like me to update CLAUDE.md with the discovered commands?"
|
||||
- Recommend: "Should I create an app design document to complement this technical documentation?"
|
||||
|
||||
## Example Usage
|
||||
|
||||
```bash
|
||||
# Basic usage
|
||||
/project:create-tech-stack
|
||||
|
||||
# With specific focus
|
||||
/project:create-tech-stack Focus on deployment and CI/CD setup
|
||||
```
|
||||
|
||||
## Sample Output Structure
|
||||
|
||||
```markdown
|
||||
# Tech Stack Documentation
|
||||
|
||||
## Overview
|
||||
|
||||
- **Framework:** Next.js 14.2.5 (App Router)
|
||||
- **Language:** TypeScript 5.5.3
|
||||
- **Database:** PostgreSQL with Prisma ORM
|
||||
- **Deployment:** Vercel with preview deployments
|
||||
|
||||
## Commands Reference
|
||||
|
||||
### Development
|
||||
|
||||
- `pnpm dev` - Start Next.js dev server on port 3000
|
||||
- `pnpm build` - Build production bundle
|
||||
- `pnpm typecheck` - Run tsc --noEmit
|
||||
|
||||
### Database
|
||||
|
||||
- `pnpm db:generate` - Generate Prisma client
|
||||
- `pnpm db:push` - Push schema changes to database
|
||||
|
||||
# ... continue with full documentation
|
||||
```
|
||||
181
.claude/commands/planning/parse-prd.md
Normal file
181
.claude/commands/planning/parse-prd.md
Normal file
@ -0,0 +1,181 @@
|
||||
---
|
||||
allowed-tools: TodoWrite, mcp__taskmaster-ai__parse_prd, mcp__taskmaster-ai__add_tag, mcp__taskmaster-ai__use_tag, mcp__taskmaster-ai__list_tags, mcp__taskmaster-ai__get_tasks
|
||||
description: Parse a PRD into Task Master tasks with optional tag creation
|
||||
---
|
||||
|
||||
# Parse PRD into Task Master Tasks
|
||||
|
||||
## Context
|
||||
|
||||
- **User Request:** $ARGUMENTS
|
||||
- Current directory: !`pwd`
|
||||
- Task Master state: !`cat .taskmaster/state.json 2>/dev/null || echo "No state file yet"`
|
||||
- Current tag: !`jq -r '.currentTag // "master"' .taskmaster/state.json 2>/dev/null || echo "master"`
|
||||
- Available tags: !`jq -r '.tags | keys | join(", ")' .taskmaster/tasks/tasks.json 2>/dev/null || echo "No tags yet"`
|
||||
- PRD files: !`ls -la .taskmaster/docs/prd*.md 2>/dev/null | tail -5 || echo "No PRD files found"`
|
||||
|
||||
## Goal
|
||||
|
||||
Parse a Product Requirements Document (PRD) into structured Task Master tasks. This command handles tag creation, context switching, and PRD parsing in a streamlined workflow.
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Determine PRD Location
|
||||
|
||||
**Think about which PRD file the user wants to parse.**
|
||||
|
||||
Check for:
|
||||
|
||||
- Explicit PRD path in
|
||||
- Default PRD location: `.taskmaster/docs/prd.txt` or `.taskmaster/docs/prd.md`
|
||||
- Tag-specific PRD: `.taskmaster/docs/prd-[tag-name].md`
|
||||
|
||||
### 2. Tag Context Decision
|
||||
|
||||
Determine if we need a new tag:
|
||||
|
||||
- If PRD is for a specific feature → Create new tag
|
||||
- If updating existing work → Use current tag
|
||||
- If starting fresh → Consider new tag
|
||||
|
||||
### 3. Execute Parse Workflow
|
||||
|
||||
Based on context:
|
||||
|
||||
1. Create new tag if needed
|
||||
2. Switch to appropriate tag
|
||||
3. Parse the PRD
|
||||
4. Generate tasks with proper numbering
|
||||
5. Suggest next steps
|
||||
|
||||
## Execution Steps
|
||||
|
||||
### Scenario 1: Parse with New Tag Creation
|
||||
|
||||
If the user wants to parse a feature-specific PRD:
|
||||
|
||||
```markdown
|
||||
1. **Create a new tag** for this feature:
|
||||
Using: add_tag with name and description
|
||||
|
||||
2. **Switch to the new tag**:
|
||||
Using: use_tag to set context
|
||||
|
||||
3. **Parse the PRD**:
|
||||
Using: parse_prd with the PRD path
|
||||
|
||||
4. **Confirm success**:
|
||||
Show task count and suggest next steps
|
||||
```
|
||||
|
||||
### Scenario 2: Parse in Current Context
|
||||
|
||||
If parsing into the current tag:
|
||||
|
||||
```markdown
|
||||
1. **Confirm current tag** is appropriate
|
||||
Show current tag context
|
||||
|
||||
2. **Parse the PRD directly**:
|
||||
Using: parse_prd with the PRD path
|
||||
|
||||
3. **Show results**:
|
||||
Display generated tasks summary
|
||||
```
|
||||
|
||||
### Scenario 3: Parse Default PRD
|
||||
|
||||
If no specific PRD mentioned:
|
||||
|
||||
```markdown
|
||||
1. **Check for default PRD**:
|
||||
Look for .taskmaster/docs/prd.txt or prd.md
|
||||
|
||||
2. **Confirm with user** if found
|
||||
3. **Parse the default PRD**:
|
||||
Using: parse_prd
|
||||
```
|
||||
|
||||
## Interactive Flow
|
||||
|
||||
Based on User Request, determine the appropriate flow:
|
||||
|
||||
### If arguments include a tag name:
|
||||
|
||||
1. Create the tag
|
||||
2. Switch to it
|
||||
3. Parse the corresponding PRD
|
||||
|
||||
### If arguments include a PRD path:
|
||||
|
||||
1. Ask if a new tag is needed
|
||||
2. Parse the specified PRD
|
||||
|
||||
### If no arguments:
|
||||
|
||||
1. Check current tag context
|
||||
2. Look for default PRD
|
||||
3. Proceed with parsing
|
||||
|
||||
## Best Practices
|
||||
|
||||
### DO:
|
||||
|
||||
- **Check tag context** before parsing
|
||||
- **Use descriptive tag names** for features
|
||||
- **Keep PRDs organized** by feature/tag
|
||||
- **Verify PRD exists** before parsing
|
||||
- **Show task summary** after parsing
|
||||
|
||||
### DON'T:
|
||||
|
||||
- **Parse into master tag** for feature work
|
||||
- **Overwrite existing tasks** without confirmation
|
||||
- **Mix unrelated features** in one tag
|
||||
- **Skip tag creation** for new features
|
||||
|
||||
## Example Usage
|
||||
|
||||
```bash
|
||||
# Parse default PRD in current context
|
||||
/project:parse
|
||||
|
||||
# Parse specific PRD with new tag
|
||||
/project:parse user-auth feature
|
||||
|
||||
# Parse existing PRD file
|
||||
/project:parse .taskmaster/docs/prd-payments.md
|
||||
```
|
||||
|
||||
## Natural Language Examples
|
||||
|
||||
Since MCP supports natural language:
|
||||
|
||||
```
|
||||
"Please parse my PRD for the user authentication feature"
|
||||
"Create tasks from the payments PRD and put them in a new tag"
|
||||
"Parse the default PRD into the current tag context"
|
||||
```
|
||||
|
||||
## Next Steps
|
||||
|
||||
After parsing, suggest:
|
||||
|
||||
1. **View generated tasks**: Use `/next` to see the first task
|
||||
2. **Analyze complexity**: Run complexity analysis if many tasks
|
||||
3. **Expand tasks**: Break down complex tasks into subtasks
|
||||
4. **Start implementation**: Begin with the highest priority task
|
||||
|
||||
## Task Tracking
|
||||
|
||||
Add parsed PRD to todo list for tracking:
|
||||
|
||||
```typescript
|
||||
{
|
||||
content: "Parse PRD: [filename]",
|
||||
status: "completed",
|
||||
priority: "high"
|
||||
}
|
||||
```
|
||||
|
||||
This helps track which PRDs have been processed and when.
|
||||
303
.claude/commands/planning/update-app-design.md
Normal file
303
.claude/commands/planning/update-app-design.md
Normal file
@ -0,0 +1,303 @@
|
||||
---
|
||||
allowed-tools: Read, Glob, Grep, Write, MultiEdit, TodoWrite, Bash
|
||||
description: Update existing app design document based on codebase changes and project evolution
|
||||
---
|
||||
|
||||
# Sync Application Design Document
|
||||
|
||||
**User Request:** $ARGUMENTS
|
||||
|
||||
## Context
|
||||
|
||||
- Project root: !`pwd`
|
||||
- Package.json: @package.json
|
||||
- Current design doc: @.taskmaster/docs/app-design-document.md
|
||||
- Last modified: !`stat -f "%Sm" .taskmaster/docs/app-design-document.md 2>/dev/null || echo "No existing document"`
|
||||
- Project status: @CLAUDE.md#project-status
|
||||
|
||||
## Goal
|
||||
|
||||
Update the existing Application Design Document to reflect current codebase state, new features, changed priorities, and project evolution. Maintain consistency with the original document while incorporating new information.
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Document Analysis
|
||||
|
||||
- Read and understand the existing app-design-document.md
|
||||
- Establish baseline understanding of documented features
|
||||
- Note the document's structure and tone
|
||||
- Identify areas that may need updates
|
||||
|
||||
### 2. Codebase Change Detection
|
||||
|
||||
**Think deeply about what has changed in the codebase since the document was last updated.**
|
||||
|
||||
Analyze for:
|
||||
|
||||
- **New Features:** Components, modules, or capabilities added
|
||||
- **Modified Flows:** Changes to user journeys or business logic
|
||||
- **Removed Features:** Deprecated or deleted functionality
|
||||
- **Architecture Evolution:** New patterns, services, or integrations
|
||||
- **Scale Changes:** Growth in complexity or user base
|
||||
- **Security Updates:** New authentication/authorization patterns
|
||||
|
||||
_Extended thinking helps identify subtle changes, understand how new features integrate with existing ones, and recognize patterns that indicate architectural evolution._
|
||||
|
||||
### 3. Interactive Update Session
|
||||
|
||||
**CRITICAL:** Ask project stage question FIRST to assess if priorities have changed:
|
||||
|
||||
- Use lettered/numbered options for easy response
|
||||
- Focus on what has changed and why
|
||||
- Gather context for accurate updates
|
||||
|
||||
### 4. Update Project Configuration
|
||||
|
||||
If project stage or priorities have changed:
|
||||
|
||||
- Update `CLAUDE.md` "Project Status" section
|
||||
- Adjust DO/DON'T lists for new priorities
|
||||
- Document any stage transitions
|
||||
|
||||
### 5. Sync Document
|
||||
|
||||
Update the document incrementally:
|
||||
|
||||
- Preserve accurate existing content
|
||||
- Add new sections only when necessary
|
||||
- Update outdated information
|
||||
- Maintain consistent tone and structure
|
||||
|
||||
### 6. Save Updated Document
|
||||
|
||||
- Backup suggestion if major changes
|
||||
- Overwrite existing app-design-document.md
|
||||
- Note what was updated
|
||||
|
||||
## Required Questions Template
|
||||
|
||||
### 🎯 CRITICAL: Project Evolution Assessment (Ask First!)
|
||||
|
||||
**1. Has your project stage evolved since the last update?**
|
||||
|
||||
a) **Same Stage** - Still in [current stage], just adding features
|
||||
b) **Stage Evolution** - Moved from [current] to next stage
|
||||
c) **Major Pivot** - Significant change in direction or purpose
|
||||
d) **Help Me Assess** - Let's review current state together
|
||||
|
||||
**2. Have your development priorities changed?**
|
||||
|
||||
Based on your current stage, are these still your priorities?
|
||||
|
||||
[Show current DO/DON'T lists from CLAUDE.md]
|
||||
|
||||
a) **Same Priorities** - These still reflect our focus
|
||||
b) **Adjusted Priorities** - Some changes needed (please specify)
|
||||
c) **New Focus Areas** - Different priorities based on learnings
|
||||
d) **Stage-Based Change** - Priorities changed due to stage evolution
|
||||
|
||||
### 📊 Change Identification Questions
|
||||
|
||||
**3. What major features have been added?**
|
||||
|
||||
Please describe any significant new capabilities, modules, or user-facing features added since the last update.
|
||||
|
||||
**4. Have any core user flows changed?**
|
||||
|
||||
a) **Authentication/Authorization** - Login, permissions, security
|
||||
b) **Main User Journey** - Primary application workflow
|
||||
c) **Data Management** - How users create/edit/delete data
|
||||
d) **Integration Points** - External service connections
|
||||
e) **None/Minor Only** - No significant flow changes
|
||||
|
||||
**5. What has been removed or deprecated?**
|
||||
|
||||
List any features, integrations, or capabilities that have been removed or are being phased out.
|
||||
|
||||
**6. Have you integrated new external services?**
|
||||
|
||||
a) **Payment Processing** - Stripe, PayPal, etc.
|
||||
b) **Communication** - Email, SMS, notifications
|
||||
c) **Analytics/Monitoring** - Tracking, logging services
|
||||
d) **AI/ML Services** - LLMs, image processing, etc.
|
||||
e) **Other** - Please specify
|
||||
f) **None** - No new integrations
|
||||
|
||||
### 🚀 Future Direction Questions
|
||||
|
||||
**7. How has user feedback influenced changes?**
|
||||
|
||||
Describe any significant pivots or adjustments made based on user feedback or usage patterns.
|
||||
|
||||
**8. What are your updated success metrics?**
|
||||
|
||||
Have your KPIs or success measurements changed? Current focus:
|
||||
|
||||
- User growth targets?
|
||||
- Revenue goals?
|
||||
- Engagement metrics?
|
||||
- Performance benchmarks?
|
||||
|
||||
**9. What's the next major milestone?**
|
||||
|
||||
a) **Feature Release** - Specific new capability
|
||||
b) **Scale Milestone** - User/revenue target
|
||||
c) **Technical Goal** - Performance, security, architecture
|
||||
d) **Business Goal** - Partnerships, funding, market expansion
|
||||
|
||||
## Update Strategy
|
||||
|
||||
### Incremental Updates
|
||||
|
||||
- **Preserve:** Keep accurate existing content
|
||||
- **Enhance:** Add new information to existing sections
|
||||
- **Replace:** Update outdated or incorrect information
|
||||
- **Remove:** Mark deprecated features appropriately
|
||||
|
||||
### Change Documentation
|
||||
|
||||
- **New Features:** Add to relevant feature categories
|
||||
- **Modified Flows:** Update user journey descriptions
|
||||
- **Architecture Changes:** Reflect in system architecture section
|
||||
- **Business Evolution:** Update goals and success metrics
|
||||
|
||||
### Consistency Maintenance
|
||||
|
||||
- Keep the same professional, accessible tone
|
||||
- Maintain technology-agnostic descriptions
|
||||
- Focus on WHAT not HOW
|
||||
- Preserve document structure
|
||||
|
||||
## Document Update Areas
|
||||
|
||||
### Always Review:
|
||||
|
||||
1. **Introduction**
|
||||
|
||||
- Update if purpose or audience has shifted
|
||||
- Reflect any pivot in value proposition
|
||||
|
||||
2. **Core Features**
|
||||
|
||||
- Add new feature categories if needed
|
||||
- Update existing features with enhancements
|
||||
- Mark removed features as deprecated
|
||||
|
||||
3. **User Experience**
|
||||
|
||||
- Update user journeys with new flows
|
||||
- Add new user personas if applicable
|
||||
- Reflect UI/UX improvements
|
||||
|
||||
4. **System Architecture**
|
||||
|
||||
- Add new integrations
|
||||
- Update data flow diagrams
|
||||
- Reflect new security patterns
|
||||
|
||||
5. **Business Logic**
|
||||
|
||||
- Update rules and workflows
|
||||
- Reflect new validation requirements
|
||||
- Document new business constraints
|
||||
|
||||
6. **Future Considerations**
|
||||
- Update roadmap based on progress
|
||||
- Add new planned features
|
||||
- Reflect lessons learned
|
||||
|
||||
## Execution Steps
|
||||
|
||||
### 1. Start with Analysis
|
||||
|
||||
```bash
|
||||
# Check when document was last updated
|
||||
stat -f "%Sm" .taskmaster/docs/app-design-document.md
|
||||
|
||||
# Review recent commits for feature changes
|
||||
git log --oneline --since="30 days ago" | head -20
|
||||
```
|
||||
|
||||
**Think deeply about:** "What has fundamentally changed in this application? How have new features altered the original vision? What patterns indicate architectural evolution?"
|
||||
|
||||
### 2. Interactive Q&A
|
||||
|
||||
- **MUST ASK PROJECT STAGE FIRST**
|
||||
- Present all questions clearly
|
||||
- Wait for complete responses
|
||||
|
||||
### 3. Update Project Status (if needed)
|
||||
|
||||
If stage or priorities changed, update both:
|
||||
|
||||
```markdown
|
||||
# In CLAUDE.md
|
||||
|
||||
## Project Status
|
||||
|
||||
**Current Stage**: [New Stage]
|
||||
|
||||
### DO Care About (Production-Ready Foundation)
|
||||
|
||||
[Updated priorities]
|
||||
|
||||
### DO NOT Care About (Skip for Velocity)
|
||||
|
||||
[Updated items to skip]
|
||||
```
|
||||
|
||||
### 4. Sync Document
|
||||
|
||||
- Make targeted updates
|
||||
- Preserve document quality
|
||||
- Add version note if helpful:
|
||||
|
||||
```markdown
|
||||
<!-- Last updated: [date] - Major changes: [summary] -->
|
||||
```
|
||||
|
||||
### 5. Save and Backup
|
||||
|
||||
```bash
|
||||
# Optional: Create backup
|
||||
cp .taskmaster/docs/app-design-document.md .taskmaster/docs/app-design-document.backup.md
|
||||
|
||||
# Save updated document
|
||||
# Overwrite .taskmaster/docs/app-design-document.md
|
||||
```
|
||||
|
||||
## Key Principles
|
||||
|
||||
### DO:
|
||||
|
||||
- **Preserve Quality:** Maintain document's professional tone
|
||||
- **Incremental Updates:** Don't rewrite unnecessarily
|
||||
- **Clear Changes:** Make updates obvious and well-integrated
|
||||
- **User Focus:** Keep emphasis on user value
|
||||
- **Stage Awareness:** Align with current project maturity
|
||||
|
||||
### DON'T:
|
||||
|
||||
- **Complete Rewrite:** Unless fundamentally pivoted
|
||||
- **Technical Details:** Maintain high-level focus
|
||||
- **Break Structure:** Keep established organization
|
||||
- **Lose History:** Preserve context of major decisions
|
||||
- **Skip Analysis:** Always understand current state first
|
||||
|
||||
## Output
|
||||
|
||||
- **Format:** Markdown (`.md`)
|
||||
- **Location:** `.taskmaster/docs/`
|
||||
- **Filename:** `app-design-document.md` (overwrites)
|
||||
- **Backup:** Suggest if major changes
|
||||
|
||||
## Final Checklist
|
||||
|
||||
1. ✅ Read existing document completely
|
||||
2. ✅ Analyze codebase changes thoroughly
|
||||
3. ✅ Ask project stage question FIRST
|
||||
4. ✅ Update CLAUDE.md if stage/priorities changed
|
||||
5. ✅ Make incremental, targeted updates
|
||||
6. ✅ Preserve document quality and tone
|
||||
7. ✅ Suggest backup for major changes
|
||||
8. ✅ Consider tech-stack.md updates if needed
|
||||
14
.claude/commands/planning/update-project-structure.md
Normal file
14
.claude/commands/planning/update-project-structure.md
Normal file
@ -0,0 +1,14 @@
|
||||
---
|
||||
allowed-tools: Bash
|
||||
description: Update project structure documentation by running tree script
|
||||
---
|
||||
|
||||
# Update Project Structure
|
||||
|
||||
Run the tree script to update project structure documentation:
|
||||
|
||||
```bash
|
||||
bash .claude/scripts/tree.sh
|
||||
```
|
||||
|
||||
Do not do anything else.
|
||||
313
.claude/commands/planning/update-rule.md
Normal file
313
.claude/commands/planning/update-rule.md
Normal file
@ -0,0 +1,313 @@
|
||||
---
|
||||
allowed-tools: Read, Glob, Grep, Write, MultiEdit, TodoWrite, Bash
|
||||
description: Update existing Cursor rules based on new patterns or codebase evolution
|
||||
---
|
||||
|
||||
# Update Cursor Rule
|
||||
|
||||
## Context
|
||||
|
||||
- **User Request:** $ARGUMENTS
|
||||
- Rules directory: !`ls -la .cursor/rules/*.mdc | wc -l | xargs -I {} echo "{} total rules"`
|
||||
- Rule guidelines: @.cursor/rules/cursor-rules.mdc
|
||||
|
||||
## Goal
|
||||
|
||||
Update an existing Cursor rule to reflect new patterns, codebase changes, or improved conventions. Maintain consistency with the rule structure while incorporating new learnings and examples.
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Rule Analysis
|
||||
|
||||
- Read the existing rule thoroughly
|
||||
- Understand current requirements
|
||||
- Note the file patterns (globs)
|
||||
- Review existing examples
|
||||
|
||||
### 2. Pattern Evolution Detection
|
||||
|
||||
**Think deeply about how code patterns have evolved since this rule was created.**
|
||||
|
||||
Analyze for:
|
||||
|
||||
- **New Patterns:** Better ways to implement the same concept
|
||||
- **Framework Updates:** Changes due to library/framework evolution
|
||||
- **Anti-patterns:** New problematic patterns discovered
|
||||
- **Edge Cases:** Scenarios not covered by current rule
|
||||
- **Related Changes:** Impact from other rule updates
|
||||
|
||||
### 3. Codebase Scanning
|
||||
|
||||
Search for:
|
||||
|
||||
- Current implementations of the pattern
|
||||
- Violations of the existing rule
|
||||
- New good examples to reference
|
||||
- Emerging patterns that should be included
|
||||
|
||||
### 4. Interactive Update Session
|
||||
|
||||
Ask about:
|
||||
|
||||
- Specific patterns that need updating
|
||||
- New edge cases discovered
|
||||
- Framework or library changes
|
||||
- Team feedback on the rule
|
||||
|
||||
### 5. Update Rule
|
||||
|
||||
Make targeted updates:
|
||||
|
||||
- Preserve valid existing content
|
||||
- Update examples with current code
|
||||
- Add new patterns or exceptions
|
||||
- Update file references
|
||||
- Revise related rules section
|
||||
|
||||
### 6. Save and Communicate
|
||||
|
||||
- Save updated rule
|
||||
- Note what changed
|
||||
- Update CLAUDE.md if rule significance changed
|
||||
- Suggest reviewing affected code
|
||||
|
||||
## Update Questions Template
|
||||
|
||||
### 🔍 Pattern Evolution
|
||||
|
||||
**1. What prompted this rule update?**
|
||||
|
||||
a) **New patterns emerged** - Better ways to do things
|
||||
b) **Framework changes** - Library updates require new approach
|
||||
c) **Problems discovered** - Current rule has issues
|
||||
d) **Team feedback** - Developers suggested improvements
|
||||
e) **Codebase evolution** - Patterns have naturally changed
|
||||
|
||||
**2. Are there new GOOD patterns to add?**
|
||||
|
||||
Please describe or provide examples of patterns that should be encouraged.
|
||||
|
||||
**3. Have you discovered new ANTI-patterns?**
|
||||
|
||||
What problematic patterns have emerged that the rule should discourage?
|
||||
|
||||
### 📁 Scope Changes
|
||||
|
||||
**4. Should the rule apply to different files now?**
|
||||
|
||||
Current globs: [show from existing rule]
|
||||
|
||||
a) **Same scope** - No change to file patterns
|
||||
b) **Expand scope** - Apply to more files
|
||||
c) **Narrow scope** - Apply to fewer files
|
||||
d) **Different patterns** - Change glob patterns entirely
|
||||
|
||||
**5. Should alwaysApply setting change?**
|
||||
|
||||
Currently: [show from existing rule]
|
||||
|
||||
a) **Keep current setting**
|
||||
b) **Change to always apply**
|
||||
c) **Change to conditional**
|
||||
|
||||
### 🔗 Related Updates
|
||||
|
||||
**6. Have related rules changed?**
|
||||
|
||||
Review if updates to other rules affect this one.
|
||||
|
||||
**7. Are there new related rules to reference?**
|
||||
|
||||
List any newly created rules that relate to this one.
|
||||
|
||||
## Update Strategy
|
||||
|
||||
### Incremental Updates
|
||||
|
||||
````markdown
|
||||
## Examples
|
||||
|
||||
### ✅ DO: [Good Pattern Name]
|
||||
|
||||
<!-- Existing example - still valid -->
|
||||
|
||||
```typescript
|
||||
// Original good example
|
||||
```
|
||||
````
|
||||
|
||||
<!-- NEW: Added based on recent patterns -->
|
||||
|
||||
```typescript
|
||||
// New pattern discovered in [file]
|
||||
```
|
||||
|
||||
### ❌ DON'T: [Anti-pattern Name]
|
||||
|
||||
<!-- UPDATED: Better example -->
|
||||
|
||||
```typescript
|
||||
// More relevant anti-pattern
|
||||
```
|
||||
|
||||
````
|
||||
|
||||
### Version Notes
|
||||
|
||||
When framework/library updates affect rules:
|
||||
|
||||
```markdown
|
||||
## Framework Compatibility
|
||||
|
||||
**React 18+**: Use the new pattern
|
||||
**React 17**: Legacy pattern still acceptable
|
||||
|
||||
<!-- Show migration path -->
|
||||
````
|
||||
|
||||
### Edge Case Documentation
|
||||
|
||||
```markdown
|
||||
## Edge Cases
|
||||
|
||||
**NEW:** [Scenario discovered since last update]
|
||||
|
||||
- How to handle: [Approach]
|
||||
- Example: [Code snippet]
|
||||
```
|
||||
|
||||
## Execution Steps
|
||||
|
||||
### 1. Start with Analysis
|
||||
|
||||
```bash
|
||||
# Find current implementations
|
||||
rg -t ts -t tsx "[pattern from rule]" --glob "!node_modules"
|
||||
|
||||
# Check for violations
|
||||
# Search for anti-patterns mentioned in rule
|
||||
|
||||
# Find new examples
|
||||
# Look for files modified recently that might have new patterns
|
||||
```
|
||||
|
||||
**Think deeply about:** "How has our understanding of this pattern evolved? What have we learned from using this rule? Are there better ways to achieve the same goal?"
|
||||
|
||||
### 2. Current State Review
|
||||
|
||||
- Read existing rule completely
|
||||
- Check all file references still exist
|
||||
- Verify examples are still current
|
||||
- Test if globs match intended files
|
||||
|
||||
### 3. Interactive Q&A
|
||||
|
||||
- Present current rule state
|
||||
- Ask about specific changes needed
|
||||
- Gather new examples
|
||||
|
||||
### 4. Update Rule
|
||||
|
||||
Follow incremental approach:
|
||||
|
||||
- Mark sections that are updated
|
||||
- Preserve good existing content
|
||||
- Add new examples from current code
|
||||
- Update stale file references
|
||||
|
||||
### 5. Save and Document
|
||||
|
||||
```markdown
|
||||
<!-- At top of rule file -->
|
||||
<!-- Last updated: [date] - [summary of changes] -->
|
||||
```
|
||||
|
||||
## Key Principles
|
||||
|
||||
### DO:
|
||||
|
||||
- **Preserve Value:** Keep good existing examples
|
||||
- **Real Updates:** Use actual current code
|
||||
- **Clear Changes:** Note what's new or updated
|
||||
- **Maintain Structure:** Follow established format
|
||||
- **Test Globs:** Verify patterns still match correctly
|
||||
|
||||
### DON'T:
|
||||
|
||||
- **Complete Rewrite:** Unless fundamentally wrong
|
||||
- **Break References:** Ensure linked files exist
|
||||
- **Lose History:** Keep record of why changes were made
|
||||
- **Theoretical Updates:** Use real examples
|
||||
- **Overcomplicate:** Keep rule focused
|
||||
|
||||
## Common Update Scenarios
|
||||
|
||||
### Framework Version Updates
|
||||
|
||||
```markdown
|
||||
## Requirements
|
||||
|
||||
- **React 18+:**
|
||||
- Use `useId()` for unique IDs
|
||||
- Prefer `startTransition` for non-urgent updates
|
||||
- **React 17 (legacy):**
|
||||
- Continue using previous patterns
|
||||
- Plan migration to new patterns
|
||||
```
|
||||
|
||||
### New Tool Adoption
|
||||
|
||||
```markdown
|
||||
## Tools
|
||||
|
||||
**Previous:** ESLint + Prettier
|
||||
**Current:** Biome (replaced both)
|
||||
|
||||
<!-- Update all configuration examples -->
|
||||
```
|
||||
|
||||
### Pattern Evolution
|
||||
|
||||
````markdown
|
||||
## Examples
|
||||
|
||||
### ✅ DO: Modern Async Pattern
|
||||
|
||||
```typescript
|
||||
// NEW: Using async/await with proper error boundaries
|
||||
const MyComponent = () => {
|
||||
const { data, error } = useSWR("/api/data", fetcher);
|
||||
|
||||
if (error) return <ErrorBoundary error={error} />;
|
||||
if (!data) return <Skeleton />;
|
||||
|
||||
return <DataDisplay data={data} />;
|
||||
};
|
||||
```
|
||||
````
|
||||
|
||||
<!-- Replaced: useEffect + setState pattern -->
|
||||
|
||||
```
|
||||
|
||||
## Output
|
||||
|
||||
- **Format:** Markdown with `.mdc` extension
|
||||
- **Location:** `.cursor/rules/`
|
||||
- **Filename:** Same as existing rule
|
||||
- **Backup:** Consider keeping version history
|
||||
|
||||
## Final Checklist
|
||||
|
||||
1. ✅ Read existing rule completely
|
||||
2. ✅ Search for current pattern usage
|
||||
3. ✅ Find new good examples
|
||||
4. ✅ Identify new anti-patterns
|
||||
5. ✅ Update with real code examples
|
||||
6. ✅ Verify all file references exist
|
||||
7. ✅ Test glob patterns still work
|
||||
8. ✅ Update related rules section
|
||||
9. ✅ Document what changed
|
||||
10. ✅ Update CLAUDE.md if needed
|
||||
11. ✅ Consider impact on existing code
|
||||
```
|
||||
327
.claude/commands/planning/update-tech-stack.md
Normal file
327
.claude/commands/planning/update-tech-stack.md
Normal file
@ -0,0 +1,327 @@
|
||||
---
|
||||
allowed-tools: Read, Glob, Grep, Write, MultiEdit, TodoWrite, Bash
|
||||
description: Update tech stack documentation based on dependency changes and technical evolution
|
||||
---
|
||||
|
||||
# Update Tech Stack Documentation
|
||||
|
||||
**User Request:** $ARGUMENTS
|
||||
|
||||
## Context
|
||||
|
||||
- Project root: !`pwd`
|
||||
- Package.json: @package.json
|
||||
- Current tech doc: @.taskmaster/docs/tech-stack.md
|
||||
- **Project Structure:** !`bash .claude/scripts/tree.sh`
|
||||
- Last modified: !`stat -f "%Sm" .taskmaster/docs/tech-stack.md 2>/dev/null || echo "No existing document"`
|
||||
- Recent package changes: !`git diff HEAD~10 HEAD -- package.json 2>/dev/null | grep -E "^[+-]" | head -20 || echo "No recent changes"`
|
||||
|
||||
## Goal
|
||||
|
||||
Update the existing Tech Stack Documentation to reflect current technical state, dependency changes, new tools adoption, and infrastructure evolution. Maintain technical accuracy while documenting all changes.
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Document Analysis
|
||||
|
||||
- Read existing tech-stack.md thoroughly
|
||||
- Note documented versions and configurations
|
||||
- Understand current technical baseline
|
||||
- Identify sections that may need updates
|
||||
|
||||
### 2. Technical Change Detection
|
||||
|
||||
**Think deeply about technical evolution in the codebase.**
|
||||
|
||||
Analyze for:
|
||||
|
||||
- **Dependency Changes:** New packages, version updates, removals
|
||||
- **Framework Evolution:** Major version upgrades, breaking changes
|
||||
- **Tool Adoption:** New dev tools, linters, formatters, testing frameworks
|
||||
- **Infrastructure Shifts:** Deployment, hosting, monitoring changes
|
||||
- **Database Evolution:** Schema changes, new ORMs, migrations
|
||||
- **Integration Updates:** New APIs, services, authentication providers
|
||||
|
||||
_Extended thinking helps identify cascading dependency updates, understand version compatibility issues, and recognize architectural implications of technical changes._
|
||||
|
||||
### 3. Automated Comparison
|
||||
|
||||
```bash
|
||||
# Compare current vs documented dependencies
|
||||
# Check for version mismatches
|
||||
# Identify new configuration files
|
||||
# Detect new tool configurations
|
||||
```
|
||||
|
||||
### 4. Interactive Technical Q&A
|
||||
|
||||
Ask targeted questions about:
|
||||
|
||||
- Non-discoverable infrastructure changes
|
||||
- Deployment and hosting updates
|
||||
- New external service integrations
|
||||
- Workflow and process changes
|
||||
|
||||
### 5. Update Documentation
|
||||
|
||||
Update incrementally:
|
||||
|
||||
- Preserve accurate technical information
|
||||
- Update version numbers precisely
|
||||
- Add new sections for major additions
|
||||
- Mark deprecated technologies
|
||||
|
||||
### 6. Save and Verify
|
||||
|
||||
- Suggest backup for major changes
|
||||
- Update CLAUDE.md commands if needed
|
||||
- Verify all versions are accurate
|
||||
|
||||
## Technical Questions Template
|
||||
|
||||
### 🔄 Version Updates & Dependencies
|
||||
|
||||
**1. Which major dependencies have been updated?**
|
||||
|
||||
Review your recent dependency changes:
|
||||
|
||||
a) **Framework upgrades** (Next.js, React, etc.) with breaking changes
|
||||
b) **Tool updates** (TypeScript, ESLint, etc.) requiring config changes
|
||||
c) **New dependencies** added for features or development
|
||||
d) **Removed packages** that are no longer needed
|
||||
e) **All of the above** - Major technical overhaul
|
||||
|
||||
**2. Have you changed your package manager or Node version?**
|
||||
|
||||
a) **Same setup** - No changes to tooling
|
||||
b) **Node upgrade** - Updated Node.js version
|
||||
c) **Package manager switch** - Changed from npm/yarn/pnpm
|
||||
d) **Monorepo adoption** - Moved to workspace setup
|
||||
|
||||
### 🏗️ Infrastructure Evolution
|
||||
|
||||
**3. Have your deployment or hosting arrangements changed?**
|
||||
|
||||
Current deployment is documented as: [show from existing doc]
|
||||
|
||||
a) **Same platform** - Just configuration updates
|
||||
b) **Platform migration** - Moved to different provider
|
||||
c) **Architecture change** - Serverless, containers, etc.
|
||||
d) **Multi-region** - Expanded geographic deployment
|
||||
|
||||
**4. Database or storage changes?**
|
||||
|
||||
a) **Version upgrade** - Same DB, newer version
|
||||
b) **Migration** - Switched database systems
|
||||
c) **New caching** - Added Redis, Memcached, etc.
|
||||
d) **Storage addition** - New file storage, CDN
|
||||
e) **No changes** - Same setup as before
|
||||
|
||||
### 🛠️ Development Workflow Updates
|
||||
|
||||
**5. New development tools or practices?**
|
||||
|
||||
Select all that apply:
|
||||
|
||||
- [ ] New testing framework or strategy
|
||||
- [ ] Added code quality tools (linters, formatters)
|
||||
- [ ] CI/CD pipeline changes
|
||||
- [ ] Docker/containerization adoption
|
||||
- [ ] New build tools or bundlers
|
||||
- [ ] Performance monitoring tools
|
||||
|
||||
**6. External service integrations?**
|
||||
|
||||
Have you added or changed:
|
||||
|
||||
a) **Payment processing** - New or updated provider
|
||||
b) **Authentication** - Different auth service
|
||||
c) **Email/SMS** - Communication service changes
|
||||
d) **Monitoring** - New error tracking or analytics
|
||||
e) **APIs** - Additional third-party integrations
|
||||
f) **None** - Same external services
|
||||
|
||||
### 🔐 Security & Compliance
|
||||
|
||||
**7. Security tool adoption?**
|
||||
|
||||
- [ ] Vulnerability scanning (Snyk, etc.)
|
||||
- [ ] Secret management changes
|
||||
- [ ] New authentication methods
|
||||
- [ ] Compliance tools (GDPR, etc.)
|
||||
- [ ] Security headers/policies
|
||||
- [ ] None of the above
|
||||
|
||||
## Update Strategy
|
||||
|
||||
### Version Precision
|
||||
|
||||
```typescript
|
||||
// ❌ Outdated
|
||||
"next": "^13.0.0"
|
||||
|
||||
// ✅ Current and precise
|
||||
"next": "14.2.5"
|
||||
```
|
||||
|
||||
### Configuration Updates
|
||||
|
||||
- Update all config examples to match current files
|
||||
- Include new configuration options
|
||||
- Remove deprecated settings
|
||||
- Add migration notes for breaking changes
|
||||
|
||||
### New Technology Sections
|
||||
|
||||
When adding major new tools:
|
||||
|
||||
```markdown
|
||||
### [New Tool Category]
|
||||
|
||||
**Tool:** [Name] [Version]
|
||||
**Purpose:** [Why it was adopted]
|
||||
**Configuration:** [Key settings]
|
||||
**Integration:** [How it connects with other tools]
|
||||
```
|
||||
|
||||
## Document Update Areas
|
||||
|
||||
### Always Check:
|
||||
|
||||
1. **package.json changes**
|
||||
|
||||
```bash
|
||||
# Compare all dependencies
|
||||
# Note version changes
|
||||
# Identify new packages
|
||||
```
|
||||
|
||||
2. **Configuration files**
|
||||
|
||||
- tsconfig.json updates
|
||||
- New .config files
|
||||
- Build tool configurations
|
||||
- Linting rule changes
|
||||
|
||||
3. **Development scripts**
|
||||
|
||||
- New npm/pnpm scripts
|
||||
- Changed command purposes
|
||||
- Removed scripts
|
||||
|
||||
4. **Infrastructure files**
|
||||
- Dockerfile changes
|
||||
- CI/CD workflows
|
||||
- Deployment configs
|
||||
- Environment examples
|
||||
|
||||
### Conditional Updates:
|
||||
|
||||
- **Architecture:** Only if fundamental changes
|
||||
- **Conventions:** Only if standards changed
|
||||
|
||||
## Execution Steps
|
||||
|
||||
### 1. Start with Analysis
|
||||
|
||||
```bash
|
||||
# Check current dependencies vs documented
|
||||
diff <(jq -r '.dependencies | keys[]' package.json | sort) \
|
||||
<(grep -E '^\*\*.*:' .taskmaster/docs/tech-stack.md | cut -d: -f1 | sed 's/\*//g' | sort)
|
||||
|
||||
# Review recent dependency commits
|
||||
git log --oneline --grep="dep" --since="30 days ago"
|
||||
|
||||
# Check for new config files
|
||||
find . -name "*.config.*" -newer .taskmaster/docs/tech-stack.md 2>/dev/null
|
||||
```
|
||||
|
||||
**Think deeply about:** "What technical decisions drove these changes? How do version updates affect the overall architecture? What new capabilities do these tools enable?"
|
||||
|
||||
### 2. Interactive Q&A
|
||||
|
||||
- Present technical questions clearly
|
||||
- Include current state from documentation
|
||||
- Wait for detailed responses
|
||||
|
||||
### 3. Update Documentation
|
||||
|
||||
Follow incremental approach:
|
||||
|
||||
```markdown
|
||||
<!-- Version update example -->
|
||||
|
||||
**Before:** React 18.2.0
|
||||
**After:** React 18.3.1 - Includes new compiler optimizations
|
||||
|
||||
<!-- New tool example -->
|
||||
|
||||
### Code Quality Tools
|
||||
|
||||
**New Addition:**
|
||||
|
||||
- **Biome:** 1.8.3 - Replaced ESLint and Prettier
|
||||
- Faster performance (10x)
|
||||
- Single configuration file
|
||||
- Built-in formatting
|
||||
```
|
||||
|
||||
### 4. Commands Update
|
||||
|
||||
Update CLAUDE.md if new scripts discovered:
|
||||
|
||||
```markdown
|
||||
### Development
|
||||
|
||||
- `pnpm dev` - Start development server
|
||||
- `pnpm check` - NEW: Run Biome linting and formatting
|
||||
- `pnpm test:e2e` - NEW: Run Playwright tests
|
||||
```
|
||||
|
||||
### 5. Save and Backup
|
||||
|
||||
```bash
|
||||
# Optional backup
|
||||
cp .taskmaster/docs/tech-stack.md .taskmaster/docs/tech-stack.backup.md
|
||||
|
||||
# Save updated document
|
||||
# Overwrite .taskmaster/docs/tech-stack.md
|
||||
```
|
||||
|
||||
## Key Principles
|
||||
|
||||
### DO:
|
||||
|
||||
- **Exact Versions:** Use precise version numbers from lock files
|
||||
- **Config Accuracy:** Match actual configuration files
|
||||
- **Change Rationale:** Explain why tools were adopted/changed
|
||||
- **Migration Notes:** Document breaking changes and updates
|
||||
- **Performance Impact:** Note improvements or concerns
|
||||
|
||||
### DON'T:
|
||||
|
||||
- **Generic Updates:** Avoid vague version ranges
|
||||
- **Assumption:** Verify every technical detail
|
||||
- **Old Information:** Remove outdated configurations
|
||||
- **Wishful Documentation:** Only document what exists
|
||||
- **Sensitive Data:** Never include secrets or keys
|
||||
|
||||
## Output
|
||||
|
||||
- **Format:** Markdown (`.md`)
|
||||
- **Location:** `.taskmaster/docs/`
|
||||
- **Filename:** `tech-stack.md` (overwrites)
|
||||
- **Backup:** Suggest for major changes
|
||||
|
||||
## Final Checklist
|
||||
|
||||
1. ✅ Read existing tech-stack.md completely
|
||||
2. ✅ Analyze all dependency changes
|
||||
3. ✅ Check configuration file updates
|
||||
4. ✅ Review infrastructure changes
|
||||
5. ✅ Ask targeted technical questions
|
||||
6. ✅ Update with exact versions
|
||||
7. ✅ Include configuration examples
|
||||
8. ✅ Update CLAUDE.md commands
|
||||
9. ✅ Suggest backup if major changes
|
||||
10. ✅ Verify technical accuracy
|
||||
33
.claude/commands/research/architecture.md
Normal file
33
.claude/commands/research/architecture.md
Normal file
@ -0,0 +1,33 @@
|
||||
---
|
||||
allowed-tools: mcp__taskmaster-ai__research, Write, TodoWrite
|
||||
description: Research architectural patterns and best practices
|
||||
---
|
||||
|
||||
# Research Architecture
|
||||
|
||||
**User Request:** $ARGUMENTS
|
||||
|
||||
## Goal
|
||||
|
||||
Research current architectural patterns, system design best practices, and scaling strategies.
|
||||
|
||||
## What You Can Say
|
||||
|
||||
```
|
||||
"Research microservices vs modular monolith for SaaS"
|
||||
"Best practices for event-driven architecture 2024"
|
||||
"How to scale WebSocket connections to 100k users"
|
||||
"Database sharding strategies for multi-tenant apps"
|
||||
"Research CQRS and Event Sourcing patterns"
|
||||
```
|
||||
|
||||
## How It Works
|
||||
|
||||
I'll research architectural topics and:
|
||||
|
||||
1. **Get latest patterns** and industry best practices
|
||||
2. **Include project context** if relevant
|
||||
3. **Provide actionable recommendations**
|
||||
4. **Save findings** if requested
|
||||
|
||||
Great for making informed architectural decisions before implementation.
|
||||
34
.claude/commands/research/security.md
Normal file
34
.claude/commands/research/security.md
Normal file
@ -0,0 +1,34 @@
|
||||
---
|
||||
allowed-tools: mcp__taskmaster-ai__research, mcp__taskmaster-ai__update_task
|
||||
description: Research security best practices and vulnerabilities
|
||||
---
|
||||
|
||||
# Research Security
|
||||
|
||||
**User Request:** $ARGUMENTS
|
||||
|
||||
## Goal
|
||||
|
||||
Research security best practices, vulnerabilities, and compliance requirements.
|
||||
|
||||
## What You Can Say
|
||||
|
||||
```
|
||||
"Latest OWASP top 10 for web apps"
|
||||
"JWT security best practices 2024"
|
||||
"How to implement secure file uploads"
|
||||
"PCI compliance for SaaS applications"
|
||||
"Research CSP headers configuration"
|
||||
"OAuth 2.0 vs SAML for enterprise"
|
||||
```
|
||||
|
||||
## How It Works
|
||||
|
||||
I'll research security topics and:
|
||||
|
||||
1. **Find current vulnerabilities** and mitigations
|
||||
2. **Get compliance requirements** if applicable
|
||||
3. **Provide secure implementation** patterns
|
||||
4. **Update relevant tasks** with security considerations
|
||||
|
||||
Critical for security-sensitive features.
|
||||
32
.claude/commands/research/task.md
Normal file
32
.claude/commands/research/task.md
Normal file
@ -0,0 +1,32 @@
|
||||
---
|
||||
allowed-tools: mcp__taskmaster-ai__research, mcp__taskmaster-ai__update_task, mcp__taskmaster-ai__update_subtask
|
||||
description: Research best practices and update tasks
|
||||
---
|
||||
|
||||
# Research for Tasks
|
||||
|
||||
- **User Request:** $ARGUMENTS
|
||||
|
||||
## Goal
|
||||
|
||||
Research current best practices, or solutions to help with task implementation.
|
||||
|
||||
## What You Can Say
|
||||
|
||||
```
|
||||
"Research JWT security best practices for task 5"
|
||||
"What's the best way to handle file uploads in Next.js?"
|
||||
"Research MongoDB vs PostgreSQL for our use case"
|
||||
"Find React Query v5 migration guide"
|
||||
```
|
||||
|
||||
## How It Works
|
||||
|
||||
I'll research what you asked about (User Request) and:
|
||||
|
||||
1. **Get current information** beyond my knowledge cutoff
|
||||
2. **Include relevant context** from your project if needed
|
||||
3. **Show you the findings**
|
||||
4. **Update tasks** if you mentioned specific ones
|
||||
|
||||
Just tell me what you need to know and optionally which task it's for.
|
||||
31
.claude/commands/research/tech.md
Normal file
31
.claude/commands/research/tech.md
Normal file
@ -0,0 +1,31 @@
|
||||
---
|
||||
allowed-tools: mcp__taskmaster-ai__research
|
||||
description: Research technologies, frameworks, and tools
|
||||
---
|
||||
|
||||
# Research Technology
|
||||
|
||||
**User Request:** $ARGUMENTS
|
||||
|
||||
## Goal
|
||||
|
||||
Research technologies, frameworks, libraries, and tools to make informed decisions.
|
||||
|
||||
## What You Can Say
|
||||
|
||||
```
|
||||
"Compare Next.js vs Remix for our project"
|
||||
"Research state management solutions for React 2024"
|
||||
"Best Node.js ORMs for PostgreSQL"
|
||||
"Evaluate Bun vs Node.js performance"
|
||||
"Research authentication libraries for Next.js"
|
||||
```
|
||||
|
||||
## How It Works
|
||||
|
||||
I'll research the technology topics you specify and provide:
|
||||
|
||||
1. **Current landscape** and popular options
|
||||
2. **Pros/cons** for your use case
|
||||
3. **Community adoption** and support
|
||||
4. **Performance comparisons** if relevant
|
||||
32
.claude/commands/snippets/create-snippet.md
Normal file
32
.claude/commands/snippets/create-snippet.md
Normal file
@ -0,0 +1,32 @@
|
||||
Title: Create Snippet Prompt
|
||||
Description: Generates a snippet template based on provided example code. Template contains instructions and example code. Provide more examples for coverage if needed. Don't include obvious steps you already know like imports.
|
||||
Body:
|
||||
|
||||
### Instructions
|
||||
|
||||
Title: ${1:Create ${2:Component}}
|
||||
Description: Generates a template for ${3:a ${2}}
|
||||
Rules:
|
||||
|
||||
- ${4:Add relevant rules here}
|
||||
- Keep rules concise and specific to the snippet
|
||||
- Include any critical requirements or conventions
|
||||
- Add validation rules if applicable
|
||||
|
||||
Body:
|
||||
|
||||
${5:$TM_SELECTED_TEXT}
|
||||
|
||||
### Example
|
||||
|
||||
Title: ${1}
|
||||
Description: ${3}
|
||||
Rules:
|
||||
|
||||
- ${4}
|
||||
- Example rule 2
|
||||
- Example rule 3
|
||||
|
||||
Body:
|
||||
|
||||
${5}
|
||||
59
.claude/commands/task/add-interactive.md
Normal file
59
.claude/commands/task/add-interactive.md
Normal file
@ -0,0 +1,59 @@
|
||||
---
|
||||
allowed-tools: mcp__taskmaster-ai__add_task, TodoWrite
|
||||
description: Add tasks interactively with clarifying questions
|
||||
---
|
||||
|
||||
# Add Tasks Interactively
|
||||
|
||||
## Context
|
||||
|
||||
- **User Request:** $ARGUMENTS
|
||||
- **Current Tag:** !`jq -r '.currentTag // "master"' .taskmaster/state.json 2>/dev/null || echo "master"`
|
||||
|
||||
## Goal
|
||||
|
||||
Create well-defined tasks by asking clarifying questions about the feature requirements.
|
||||
|
||||
## Process
|
||||
|
||||
1. **Analyze Feature Request:** Think deeply about what tasks might be needed.
|
||||
|
||||
2. **Ask Clarifying Questions:**
|
||||
|
||||
- Ask 4-6 targeted questions based on the feature
|
||||
- Provide lettered/numbered options for easy response
|
||||
- Focus on understanding scope and breakdown
|
||||
|
||||
3. **Generate Tasks:**
|
||||
- Create tasks based on answers
|
||||
- Add to current tag context
|
||||
|
||||
## Clarifying Questions Framework
|
||||
|
||||
Adapt questions based on the specific feature request provided above. Consider these areas:
|
||||
|
||||
- **Scope:** "How big is this feature?"
|
||||
- **Components:** "What are the main parts that need to be built?"
|
||||
- **Dependencies:** "Does this depend on any existing tasks or features?"
|
||||
- **Priority:** "How urgent is this feature?"
|
||||
- **Testing:** "What kind of testing will this need?"
|
||||
- **Phases:** "Should this be built all at once or in phases?"
|
||||
|
||||
## Final Instructions
|
||||
|
||||
1. **Think deeply** about the feature request
|
||||
2. **Ask clarifying questions** with lettered/numbered options
|
||||
3. **Generate tasks** based on the answers
|
||||
4. **Add tasks** to the current tag context
|
||||
|
||||
## Example Usage
|
||||
|
||||
```
|
||||
/add-interactive user notification system
|
||||
```
|
||||
|
||||
This will:
|
||||
|
||||
1. Ask about notification types and delivery methods
|
||||
2. Understand scope and dependencies
|
||||
3. Create appropriate tasks based on answers
|
||||
65
.claude/commands/task/add.md
Normal file
65
.claude/commands/task/add.md
Normal file
@ -0,0 +1,65 @@
|
||||
---
|
||||
allowed-tools: mcp__taskmaster-ai__add_task, TodoWrite
|
||||
description: Add one or more tasks to the current tag
|
||||
---
|
||||
|
||||
# Add Tasks
|
||||
|
||||
- **User Request:** $ARGUMENTS
|
||||
|
||||
## Goal
|
||||
|
||||
Add new tasks to your current tag context. Can handle single tasks or multiple tasks at once.
|
||||
|
||||
## What You Can Say
|
||||
|
||||
### Single Task
|
||||
|
||||
```
|
||||
/add implement user login with email and password
|
||||
/add create API endpoint for user profile
|
||||
```
|
||||
|
||||
### Multiple Tasks
|
||||
|
||||
```
|
||||
/add
|
||||
1. Setup database schema
|
||||
2. Create user authentication
|
||||
3. Add email verification
|
||||
4. Implement password reset
|
||||
```
|
||||
|
||||
### With Details
|
||||
|
||||
```
|
||||
/add high priority: implement payment processing with Stripe
|
||||
/add depends on 5: add payment confirmation emails
|
||||
```
|
||||
|
||||
## How It Works
|
||||
|
||||
Based on your input (User Request), I'll:
|
||||
|
||||
1. **Parse your request** - Single task or numbered list
|
||||
2. **Create tasks** in the current tag context
|
||||
3. **Set dependencies** if you mention "depends on X"
|
||||
4. **Set priority** if you mention high/medium/low
|
||||
5. **Confirm** what was added
|
||||
|
||||
## Examples
|
||||
|
||||
### Quick Add
|
||||
|
||||
- `/add fix the login bug` → Creates task "fix the login bug"
|
||||
|
||||
### Batch Add
|
||||
|
||||
- `/add 1. Setup 2. Test 3. Deploy` → Creates 3 tasks
|
||||
|
||||
### With Context
|
||||
|
||||
- `/add urgent: fix security vulnerability in auth` → High priority task
|
||||
- `/add after task 3: add unit tests` → Sets dependency
|
||||
|
||||
The command is smart enough to understand your intent from natural language.
|
||||
21
.claude/commands/task/done.md
Normal file
21
.claude/commands/task/done.md
Normal file
@ -0,0 +1,21 @@
|
||||
---
|
||||
allowed-tools: mcp__taskmaster-ai__set_task_status, mcp__taskmaster-ai__next_task, TodoWrite
|
||||
description: Mark task as complete and optionally get next task
|
||||
---
|
||||
|
||||
# Task Done
|
||||
|
||||
**User Request:** $ARGUMENTS
|
||||
|
||||
## Goal
|
||||
|
||||
Mark task(s) as complete. By default, also shows the next task.
|
||||
|
||||
## What You Can Say
|
||||
|
||||
```
|
||||
/done 3 # Mark task 3 as done, show next
|
||||
/done 3 stop # Mark done, don't show next
|
||||
/done 5,7,9 # Mark multiple tasks done
|
||||
/done # Mark current task done (if tracking)
|
||||
```
|
||||
21
.claude/commands/task/expand.md
Normal file
21
.claude/commands/task/expand.md
Normal file
@ -0,0 +1,21 @@
|
||||
---
|
||||
allowed-tools: mcp__taskmaster-ai__expand_task, mcp__taskmaster-ai__expand_all
|
||||
description: Break down tasks into subtasks
|
||||
---
|
||||
|
||||
# Expand Tasks
|
||||
|
||||
**User Request:** $ARGUMENTS
|
||||
|
||||
## Goal
|
||||
|
||||
Break complex tasks into manageable subtasks.
|
||||
|
||||
## What You Can Say
|
||||
|
||||
```
|
||||
/expand 5 # Break down task 5
|
||||
/expand 5 security focus # With specific context
|
||||
/expand all # Expand all pending tasks
|
||||
/expand 5 research # Use research for better breakdown
|
||||
```
|
||||
124
.claude/commands/task/generate.md
Normal file
124
.claude/commands/task/generate.md
Normal file
@ -0,0 +1,124 @@
|
||||
Generate individual task files from tasks.json.
|
||||
|
||||
## Task File Generation
|
||||
|
||||
Creates separate markdown files for each task, perfect for AI agents or documentation.
|
||||
|
||||
## Execution
|
||||
|
||||
```bash
|
||||
task-master generate
|
||||
```
|
||||
|
||||
## What It Creates
|
||||
|
||||
For each task, generates a file like `task_001.txt`:
|
||||
|
||||
```
|
||||
Task ID: 1
|
||||
Title: Implement user authentication
|
||||
Status: pending
|
||||
Priority: high
|
||||
Dependencies: []
|
||||
Created: 2024-01-15
|
||||
Complexity: 7
|
||||
|
||||
## Description
|
||||
Create a secure user authentication system with login, logout, and session management.
|
||||
|
||||
## Details
|
||||
- Use JWT tokens for session management
|
||||
- Implement secure password hashing
|
||||
- Add remember me functionality
|
||||
- Include password reset flow
|
||||
|
||||
## Test Strategy
|
||||
- Unit tests for auth functions
|
||||
- Integration tests for login flow
|
||||
- Security testing for vulnerabilities
|
||||
- Performance tests for concurrent logins
|
||||
|
||||
## Subtasks
|
||||
1.1 Setup authentication framework (pending)
|
||||
1.2 Create login endpoints (pending)
|
||||
1.3 Implement session management (pending)
|
||||
1.4 Add password reset (pending)
|
||||
```
|
||||
|
||||
## File Organization
|
||||
|
||||
Creates structure:
|
||||
|
||||
```
|
||||
.taskmaster/
|
||||
└── tasks/
|
||||
├── task_001.txt
|
||||
├── task_002.txt
|
||||
├── task_003.txt
|
||||
└── ...
|
||||
```
|
||||
|
||||
## Smart Features
|
||||
|
||||
1. **Consistent Formatting**
|
||||
|
||||
- Standardized structure
|
||||
- Clear sections
|
||||
- AI-readable format
|
||||
- Markdown compatible
|
||||
1. **Contextual Information**
|
||||
|
||||
- Full task details
|
||||
- Related task references
|
||||
- Progress indicators
|
||||
- Implementation notes
|
||||
1. **Incremental Updates**
|
||||
|
||||
- Only regenerate changed tasks
|
||||
- Preserve custom additions
|
||||
- Track generation timestamp
|
||||
- Version control friendly
|
||||
|
||||
## Use Cases
|
||||
|
||||
- **AI Context**: Provide task context to AI assistants
|
||||
- **Documentation**: Standalone task documentation
|
||||
- **Archival**: Task history preservation
|
||||
- **Sharing**: Send specific tasks to team members
|
||||
- **Review**: Easier task review process
|
||||
|
||||
## Generation Options
|
||||
|
||||
Based on arguments:
|
||||
|
||||
- Filter by status
|
||||
- Include/exclude completed
|
||||
- Custom templates
|
||||
- Different formats
|
||||
|
||||
## Post-Generation
|
||||
|
||||
```
|
||||
Task File Generation Complete
|
||||
━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||||
Generated: 45 task files
|
||||
Location: .taskmaster/tasks/
|
||||
Total size: 156 KB
|
||||
|
||||
New files: 5
|
||||
Updated files: 12
|
||||
Unchanged: 28
|
||||
|
||||
Ready for:
|
||||
- AI agent consumption
|
||||
- Version control
|
||||
- Team distribution
|
||||
```
|
||||
|
||||
## Integration Benefits
|
||||
|
||||
- Git-trackable task history
|
||||
- Easy task sharing
|
||||
- AI tool compatibility
|
||||
- Offline task access
|
||||
- Backup redundancy
|
||||
21
.claude/commands/task/list.md
Normal file
21
.claude/commands/task/list.md
Normal file
@ -0,0 +1,21 @@
|
||||
---
|
||||
allowed-tools: mcp__taskmaster-ai__get_tasks
|
||||
description: List all tasks in current tag
|
||||
---
|
||||
|
||||
# List Tasks
|
||||
|
||||
**User Request:** $ARGUMENTS
|
||||
|
||||
## Goal
|
||||
|
||||
Show all tasks with their status, priority, and progress.
|
||||
|
||||
## What You Can Say
|
||||
|
||||
```
|
||||
/list # All tasks
|
||||
/list pending # Only pending tasks
|
||||
/list done # Completed tasks
|
||||
/list blocked # Blocked tasks
|
||||
```
|
||||
21
.claude/commands/task/move.md
Normal file
21
.claude/commands/task/move.md
Normal file
@ -0,0 +1,21 @@
|
||||
---
|
||||
allowed-tools: mcp__taskmaster-ai__move_task
|
||||
description: Reorganize task structure
|
||||
---
|
||||
|
||||
# Move Tasks
|
||||
|
||||
**User Request:** $ARGUMENTS
|
||||
|
||||
## Goal
|
||||
|
||||
Move tasks to different positions or parents.
|
||||
|
||||
## What You Can Say
|
||||
|
||||
```
|
||||
/move 5.2 to 7.3 # Move subtask to different parent
|
||||
/move 5 to 25 # Move to new position
|
||||
/move 10,11,12 to 16,17,18 # Move multiple tasks
|
||||
/move 5.2 to 7 # Subtask becomes standalone
|
||||
```
|
||||
18
.claude/commands/task/next.md
Normal file
18
.claude/commands/task/next.md
Normal file
@ -0,0 +1,18 @@
|
||||
---
|
||||
allowed-tools: mcp__taskmaster-ai__next_task, mcp__taskmaster-ai__get_task, TodoWrite, Read, Write, MultiEdit, Bash, Grep, Glob
|
||||
description: Get next task and start implementing it immediately
|
||||
---
|
||||
|
||||
# Next Task & Implement
|
||||
|
||||
**User Request:** $ARGUMENTS
|
||||
|
||||
## Goal
|
||||
|
||||
Find the next task and start implementing it right away (unless you say otherwise).
|
||||
|
||||
## How It Works
|
||||
|
||||
1. **Find next task** based on priorities and dependencies
|
||||
2. **Show task details** briefly
|
||||
3. **Start implementation** immediately
|
||||
32
.claude/commands/task/research.md
Normal file
32
.claude/commands/task/research.md
Normal file
@ -0,0 +1,32 @@
|
||||
---
|
||||
allowed-tools: mcp__taskmaster-ai__research, mcp__taskmaster-ai__update_task, mcp__taskmaster-ai__update_subtask
|
||||
description: Research best practices and update tasks
|
||||
---
|
||||
|
||||
# Research for Tasks
|
||||
|
||||
- **User Request:** $ARGUMENTS
|
||||
|
||||
## Goal
|
||||
|
||||
Research current best practices, or solutions to help with task implementation.
|
||||
|
||||
## What You Can Say
|
||||
|
||||
```
|
||||
"Research JWT security best practices for task 5"
|
||||
"What's the best way to handle file uploads in Next.js?"
|
||||
"Research MongoDB vs PostgreSQL for our use case"
|
||||
"Find React Query v5 migration guide"
|
||||
```
|
||||
|
||||
## How It Works
|
||||
|
||||
I'll research what you asked about (User Request) and:
|
||||
|
||||
1. **Get current information** beyond my knowledge cutoff
|
||||
2. **Include relevant context** from your project if needed
|
||||
3. **Show you the findings**
|
||||
4. **Update tasks** if you mentioned specific ones
|
||||
|
||||
Just tell me what you need to know and optionally which task it's for.
|
||||
20
.claude/commands/task/show.md
Normal file
20
.claude/commands/task/show.md
Normal file
@ -0,0 +1,20 @@
|
||||
---
|
||||
allowed-tools: mcp__taskmaster-ai__get_task
|
||||
description: Show specific task details
|
||||
---
|
||||
|
||||
# Show Task
|
||||
|
||||
**User Request:** $ARGUMENTS
|
||||
|
||||
## Goal
|
||||
|
||||
Display detailed information about specific task(s).
|
||||
|
||||
## What You Can Say
|
||||
|
||||
```
|
||||
/show 5 # Show task 5
|
||||
/show 5,7,9 # Show multiple tasks
|
||||
/show 5.2 # Show subtask
|
||||
```
|
||||
77
.claude/commands/task/spec.md
Normal file
77
.claude/commands/task/spec.md
Normal file
@ -0,0 +1,77 @@
|
||||
# End-to-End Feature Implementation Guide
|
||||
|
||||
## Context
|
||||
|
||||
- When implementing new end-to-end features
|
||||
- When planning feature development workflow
|
||||
- When ensuring consistent architecture
|
||||
|
||||
## Requirements
|
||||
|
||||
- Follow the implementation steps in order
|
||||
- Use the appropriate standards for each step
|
||||
- Ensure consistency across all implementation layers
|
||||
- Test each phase before moving to the next
|
||||
|
||||
## Implementation Steps
|
||||
|
||||
1. **Schema Definition** → Use rule @.cursor/rules/2101-schema-prisma.mdc
|
||||
|
||||
- Define Prisma schema with standard fields
|
||||
- Add proper relations and indexes
|
||||
- Use correct field types and constraints
|
||||
- Follow naming conventions
|
||||
|
||||
2. **Router Implementation** → Use rule @.cursor/rules/2102-router.mdc
|
||||
|
||||
- Create protected tRPC router
|
||||
- Add input validation with Zod
|
||||
- Implement cursor-based pagination
|
||||
- Handle security and responses
|
||||
|
||||
3. **React Query Integration** → Use rule @.cursor/rules/2103-trpc-react-query.mdc
|
||||
|
||||
- Set up queries with queryOptions
|
||||
- Handle loading states
|
||||
- Implement optimistic updates
|
||||
- Manage cache invalidation
|
||||
|
||||
4. **CRUD Implementation** → Use rule @.cursor/rules/2105-crud.mdc
|
||||
|
||||
- Follow phased implementation approach
|
||||
- Start with Create & Read operations
|
||||
- Add Update & Delete operations
|
||||
- Implement advanced features last
|
||||
|
||||
5. **Authentication** → Use rule @.cursor/rules/2106-auth.mdc
|
||||
- Use protectedProcedure for routes
|
||||
- Add session checks in components
|
||||
- Implement auth guards
|
||||
- Handle unauthorized states
|
||||
|
||||
## Examples
|
||||
|
||||
<example>
|
||||
```typescript
|
||||
// Implementation follows all steps in order
|
||||
// 1. Schema defined in prisma/schema.prisma
|
||||
// 2. Router implemented in src/server/api/routers/item.ts
|
||||
// 3. React Query integration in src/components/ItemList.tsx
|
||||
// 4. CRUD operations implemented in phases
|
||||
// 5. Authentication checks in all appropriate places
|
||||
```
|
||||
Complete feature implementation following all steps in order
|
||||
</example>
|
||||
|
||||
<example type="invalid">
|
||||
```typescript
|
||||
// Implementation skips steps or does them out of order
|
||||
// Missing schema definition
|
||||
// Incomplete router implementation
|
||||
// Using old tRPC patterns instead of React Query
|
||||
// Missing error handling
|
||||
// Implementing all CRUD operations at once
|
||||
// Missing authentication checks
|
||||
```
|
||||
Incomplete or out-of-order implementation missing critical steps
|
||||
</example>
|
||||
59
.claude/commands/task/update-task-interactive.md
Normal file
59
.claude/commands/task/update-task-interactive.md
Normal file
@ -0,0 +1,59 @@
|
||||
---
|
||||
allowed-tools: mcp__taskmaster-ai__update, mcp__taskmaster-ai__update_task, mcp__taskmaster-ai__update_subtask, mcp__taskmaster-ai__get_tasks
|
||||
description: Update tasks interactively with clarifying questions
|
||||
---
|
||||
|
||||
# Update Tasks Interactively
|
||||
|
||||
## Context
|
||||
|
||||
- **User Request:** $ARGUMENTS
|
||||
- **Current Tag:** !`jq -r '.currentTag // "master"' .taskmaster/state.json 2>/dev/null || echo "master"`
|
||||
|
||||
## Goal
|
||||
|
||||
Update tasks based on implementation changes by asking clarifying questions to ensure accurate updates.
|
||||
|
||||
## Process
|
||||
|
||||
1. **Analyze Change:** Think deeply about the implications of the change.
|
||||
|
||||
2. **Ask Clarifying Questions:**
|
||||
|
||||
- Ask 4-6 targeted questions about the change
|
||||
- Provide lettered/numbered options for easy response
|
||||
- Focus on understanding impact and scope
|
||||
|
||||
3. **Update Tasks:**
|
||||
- Update affected tasks based on answers
|
||||
- Show what was changed
|
||||
|
||||
## Clarifying Questions Framework
|
||||
|
||||
Adapt questions based on the change described above. Consider these areas:
|
||||
|
||||
- **Scope:** "Which tasks are affected by this change?"
|
||||
- **Reason:** "Why was this change made?"
|
||||
- **Impact:** "How does this affect the implementation approach?"
|
||||
- **Dependencies:** "Does this change affect task dependencies?"
|
||||
- **Testing:** "How should test strategies be updated?"
|
||||
- **Documentation:** "What additional context should be added?"
|
||||
|
||||
## Final Instructions
|
||||
|
||||
1. **Think deeply** about the change and its implications
|
||||
2. **Ask clarifying questions** with lettered/numbered options
|
||||
3. **Update tasks** based on the answers
|
||||
4. **Confirm** what was updated
|
||||
|
||||
## Example Usage
|
||||
|
||||
```
|
||||
/project:task:update-interactive switching to microservices architecture
|
||||
```
|
||||
|
||||
This will:
|
||||
|
||||
1. Ask about which components are affected
|
||||
2. Understand the migration approach
|
||||
3. Update relevant tasks with new architecture details
|
||||
30
.claude/commands/task/update-task.md
Normal file
30
.claude/commands/task/update-task.md
Normal file
@ -0,0 +1,30 @@
|
||||
---
|
||||
allowed-tools: mcp__taskmaster-ai__update, mcp__taskmaster-ai__update_task, mcp__taskmaster-ai__update_subtask, mcp__taskmaster-ai__get_tasks
|
||||
description: Update tasks based on implementation changes
|
||||
---
|
||||
|
||||
# Update Tasks
|
||||
|
||||
**User Request:** $ARGUMENTS
|
||||
|
||||
## Goal
|
||||
|
||||
Update tasks when implementation changes from the original plan. Just tell me what changed and I'll update the relevant tasks.
|
||||
|
||||
## What You Can Say
|
||||
|
||||
```
|
||||
"We're using MongoDB instead of PostgreSQL"
|
||||
"Update task 5 to use OAuth instead of JWT"
|
||||
"All tasks from 10 onwards should use the new API structure"
|
||||
"Task 7.2 needs a note about the Redis caching we added"
|
||||
```
|
||||
|
||||
## How It Works
|
||||
|
||||
Based on what you tell me (User Request), I'll:
|
||||
|
||||
1. **Understand the change** from your description
|
||||
2. **Find affected tasks** automatically or use the ones you specify
|
||||
3. **Update them** with the new approach
|
||||
4. **Confirm** what was updated
|
||||
Reference in New Issue
Block a user