Paul.Kim/tpl-agentic-dev-base
Template
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: 기본 파일 구조, .gitignore, CLAUDE.md, README.md, 및 작업 관리 시스템을 위한 설정 파일 추가

Browse Source
This commit is contained in:
Paul.Kim
2025-07-13 20:18:27 +09:00
parent 7348efd65b
commit abb1ee7e71
50 changed files with 5161 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

282
.claude/commands/docs/create-app-design.md Normal file
View 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/docs/create-doc.md Normal file
View 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/docs/create-prd-interactive.md Normal file
View 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`

114
.claude/commands/docs/create-prd.md Normal file
View File

@ -0,0 +1,114 @@
---
allowed-tools: Bash, Read, Write, Glob, Grep, Task, TodoWrite, mcp__taskmaster-ai__parse_prd
description: Generate a PRD directly without questions for simple, well-defined features
---
# Generate a Quick 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
- **Project Structure:** !`bash .claude/scripts/tree.sh`
- **Tech Stack:** @.taskmaster/docs/tech-stack.md
- **PRD Template:** @.taskmaster/templates/example_prd.md
## Goal
To quickly create a Product Requirements Document (PRD) without asking clarifying questions. Best suited for simple, well-defined features where requirements are clear.
## Process
1. **Analyze Feature Request:**
- Think deeply about the user's feature request
- Make reasonable assumptions based on common patterns
- Review existing codebase for context
2. **Codebase Analysis:**
- Search for relevant existing code patterns
- Review components that might be affected
- Identify potential integration points
- Consider architectural impacts
3. **Generate PRD Immediately:**
- Follow the example PRD structure exactly
- Include all required sections from the template
- Make reasonable assumptions for unclear requirements
- Document assumptions clearly in the PRD
4. **Save and Next Steps:**
- Save as `prd-[feature-name].md` in `.taskmaster/docs/`
- Suggest running Task Master parse command
## 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. CRITICAL: 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
## Assumptions Section
When using quick mode, include an "Assumptions" section at the beginning of the PRD documenting:
- Key assumptions made about requirements
- Default choices for ambiguous features
- Suggested areas that may need refinement
## Final Instructions
1. **Think deeply** about the feature request and make intelligent assumptions
2. **Do NOT ask questions** - proceed directly to PRD generation
3. **Document assumptions** clearly in the PRD
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-quick user profile page with avatar upload
```
This will:
1. Analyze the codebase for existing user/profile patterns
2. Make assumptions about profile fields and avatar requirements
3. Generate a comprehensive PRD immediately
4. Save it as `prd-user-profile-page.md`
5. Document all assumptions made
## When to Use Quick Mode
✅ **Good for:**
- Simple CRUD features
- Standard UI components
- Well-defined integrations
- Features with clear precedent in codebase
❌ **Avoid for:**
- Complex architectural changes
- Features with many unknowns
- Security-critical features
- Features affecting multiple systems
For complex features, use `/project:prd` for the full interactive process.

260
.claude/commands/docs/create-rule.md Normal file
View 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/docs/create-tech-stack.md Normal file
View 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/docs/parse-prd.md Normal file
View 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/docs/update-app-design.md Normal file
View 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/docs/update-project-structure.md Normal file
View 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/docs/update-rule.md Normal file
View 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/docs/update-tech-stack.md Normal file
View 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