Initial commit
This commit is contained in:
11
.claude-plugin/plugin.json
Normal file
11
.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,11 @@
|
||||
{
|
||||
"name": "dotai",
|
||||
"description": "Complete development toolkit - documentation, PRDs, design docs, debugging, PR workflows, and planning",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "zbeyens"
|
||||
},
|
||||
"commands": [
|
||||
"./commands"
|
||||
]
|
||||
}
|
||||
3
README.md
Normal file
3
README.md
Normal file
@@ -0,0 +1,3 @@
|
||||
# dotai
|
||||
|
||||
Complete development toolkit - documentation, PRDs, design docs, debugging, PR workflows, and planning
|
||||
322
commands/create-app-design.md
Normal file
322
commands/create-app-design.md
Normal file
@@ -0,0 +1,322 @@
|
||||
---
|
||||
allowed-tools: Read, Glob, Grep, Write, MultiEdit, TodoWrite
|
||||
description: Generate comprehensive app design document with project stage assessment
|
||||
---
|
||||
|
||||
# Generate Application Design Document
|
||||
|
||||
**User Request:** $ARGUMENTS
|
||||
|
||||
## Context
|
||||
|
||||
- Project root: !`pwd`
|
||||
- Package.json: @package.json
|
||||
- Existing design docs: !`ls -la .claude/rules/ 2>/dev/null || echo "No .claude/rules directory yet"`
|
||||
|
||||
## Goal
|
||||
|
||||
Create a comprehensive Application Design Document based on deep codebase analysis and user input. The document provides a high-level overview of the application's architecture, core features, user experience, and business logic while remaining technology-agnostic and focused on the "what" rather than the "how".
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Initial Analysis
|
||||
|
||||
- Analyze project structure and existing codebase
|
||||
- Review package.json for project name and dependencies
|
||||
- Check for existing documentation in .claude/rules/
|
||||
- Identify key application features and patterns
|
||||
- **Think deeply** about the application's purpose and architecture
|
||||
|
||||
### 2. Codebase Deep Dive
|
||||
|
||||
**Think harder about the application's architecture and business logic.**
|
||||
|
||||
Analyze the codebase to understand:
|
||||
|
||||
- **Application Structure:** Main modules, features, and components
|
||||
- **User Flows:** Authentication, navigation, key user journeys
|
||||
- **Data Models:** Conceptual relationships and entities
|
||||
- **Business Logic:** Core rules, workflows, and processes
|
||||
- **Integrations:** External services and APIs
|
||||
- **Security Patterns:** Authentication and authorization approaches
|
||||
|
||||
_Extended thinking helps identify non-obvious patterns, understand complex business rules from code, and make strategic decisions about what aspects are most important to document._
|
||||
|
||||
### 3. Interactive Q&A Session
|
||||
|
||||
**CRITICAL:** Ask project stage question FIRST, then 4-7 additional questions:
|
||||
|
||||
- Use lettered/numbered options for easy response
|
||||
- Focus on business goals and user needs
|
||||
- Gather context for proper documentation
|
||||
|
||||
### 4. Update Project Configuration
|
||||
|
||||
Based on project stage response:
|
||||
|
||||
- Update `.claude/rules/3-project-status.mdc` with current stage
|
||||
- Set appropriate DO/DON'T priorities for the stage
|
||||
- Document stage-specific development guidelines in the Cursor rule
|
||||
|
||||
### 5. Generate Document
|
||||
|
||||
Create comprehensive app design document following the standard structure
|
||||
|
||||
### 6. Save and Organize
|
||||
|
||||
- Create `.claude/rules/` directory if needed
|
||||
- Save as `1-app-design-document.mdc`
|
||||
- Suggest next steps (tech stack doc, PRD, etc.)
|
||||
|
||||
## Required Questions Template
|
||||
|
||||
### 🎯 CRITICAL: Project Stage Assessment (Ask First!)
|
||||
|
||||
**1. What stage is your application currently in?**
|
||||
|
||||
a) **Pre-MVP** - Building initial version, not deployed to production yet
|
||||
b) **MVP** - Basic version deployed and live with early users
|
||||
c) **Production** - Mature application with established user base
|
||||
d) **Enterprise** - Large scale deployment, multiple teams involved
|
||||
|
||||
**2. Based on your selected stage, here are the development priorities:**
|
||||
|
||||
- **Pre-MVP Priorities:**
|
||||
|
||||
- ✅ DO: Core functionality, security basics, input validation, working features
|
||||
- ❌ DON'T: Unit tests, performance optimization, accessibility polish, perfect code
|
||||
- 🚀 Focus: Ship fast with security, iterate based on feedback
|
||||
|
||||
- **MVP Priorities:**
|
||||
|
||||
- ✅ DO: Critical path testing, basic monitoring, user feedback loops
|
||||
- ❌ DON'T: Comprehensive test coverage, advanced patterns, premature optimization
|
||||
- 🚀 Focus: Stability for early users, rapid iteration
|
||||
|
||||
- **Production Priorities:**
|
||||
|
||||
- ✅ DO: Testing, monitoring, performance, accessibility, documentation
|
||||
- ❌ DON'T: Skip security reviews, ignore technical debt
|
||||
- 🚀 Focus: Reliability, scalability, user experience
|
||||
|
||||
- **Enterprise Priorities:**
|
||||
- ✅ DO: Comprehensive testing, security audits, team coordination, compliance
|
||||
- ❌ DON'T: Skip documentation, ignore code standards
|
||||
- 🚀 Focus: Team efficiency, maintainability, compliance
|
||||
|
||||
### 📋 Context-Specific Questions (Ask 4-7 based on analysis)
|
||||
|
||||
**3. Application Purpose & Users**
|
||||
|
||||
- What is the primary problem your application solves?
|
||||
- Who are your target users and what are their main goals?
|
||||
|
||||
**4. Unique Value Proposition**
|
||||
|
||||
- What makes your application unique compared to existing solutions?
|
||||
- What's your competitive advantage?
|
||||
|
||||
**5. User Roles & Permissions**
|
||||
|
||||
- What different types of users interact with your system?
|
||||
- Examples: end users, admins, moderators, content creators, viewers
|
||||
|
||||
**6. Core User Journeys**
|
||||
|
||||
- What are the 2-3 most critical user flows?
|
||||
- Example: Sign up → Create content → Share → Get feedback
|
||||
|
||||
**7. Business Model & Growth**
|
||||
|
||||
- How does this application generate value?
|
||||
- Options: SaaS subscription, marketplace, freemium, advertising, one-time purchase
|
||||
|
||||
**8. Integration Ecosystem**
|
||||
|
||||
- What external services must you integrate with?
|
||||
- Examples: payment processors, email services, analytics, social platforms
|
||||
|
||||
**9. Scale & Performance Goals**
|
||||
|
||||
- What scale are you planning for in the next 12 months?
|
||||
- Users: dozens, hundreds, thousands, millions?
|
||||
- Geographic: local, national, global?
|
||||
|
||||
**10. Success Metrics**
|
||||
|
||||
- How will you measure if your application is successful?
|
||||
- Examples: user retention, revenue, engagement, conversion rates
|
||||
|
||||
## Document Structure
|
||||
|
||||
The generated document must follow this high-level structure:
|
||||
|
||||
### **Introduction**
|
||||
|
||||
- Application overview and purpose
|
||||
- Target audience and user base
|
||||
- Core value proposition
|
||||
- Business context and goals
|
||||
|
||||
### **Core Features**
|
||||
|
||||
- **Feature Category 1:** (e.g., User Management)
|
||||
- Purpose and user benefit
|
||||
- Key functionalities
|
||||
- User experience considerations
|
||||
- **Feature Category 2:** (e.g., Content Creation)
|
||||
- Purpose and user benefit
|
||||
- Key functionalities
|
||||
- User experience considerations
|
||||
- **[Additional feature categories as needed]**
|
||||
|
||||
### **User Experience**
|
||||
|
||||
- User personas and roles
|
||||
- Key user journeys and flows
|
||||
- Interface design principles
|
||||
- Accessibility and usability considerations
|
||||
|
||||
### **System Architecture**
|
||||
|
||||
- High-level system components
|
||||
- Data flow and relationships
|
||||
- Integration points and external services
|
||||
- Security and privacy approach
|
||||
|
||||
### **Business Logic**
|
||||
|
||||
- Core business rules and processes
|
||||
- Data models and relationships (conceptual)
|
||||
- Workflow and state management
|
||||
- Validation and business constraints
|
||||
|
||||
### **Future Considerations**
|
||||
|
||||
- Planned enhancements and features
|
||||
- Scalability considerations
|
||||
- Potential integrations
|
||||
- Long-term vision and roadmap
|
||||
|
||||
## Target Audience
|
||||
|
||||
The document should be accessible to:
|
||||
|
||||
- **Business stakeholders** who need to understand the application's purpose and capabilities
|
||||
- **Product managers** planning features and roadmaps
|
||||
- **Designers** creating user interfaces and experiences
|
||||
- **New developers** joining the project who need a high-level understanding
|
||||
- **Technical leaders** making architectural decisions
|
||||
|
||||
The language should be clear, business-focused, and avoid technical implementation details.
|
||||
|
||||
## Writing Principles
|
||||
|
||||
### DO:
|
||||
|
||||
- **Business Focus:** Describe WHAT the application does, not HOW
|
||||
- **User Value:** Emphasize benefits and outcomes for users
|
||||
- **Clear Language:** Write for non-technical stakeholders
|
||||
- **Visual Thinking:** Use diagrams and flows where helpful
|
||||
- **Future Ready:** Consider growth and evolution paths
|
||||
|
||||
### DON'T:
|
||||
|
||||
- **Technical Details:** No code snippets or implementation specifics
|
||||
- **Technology Stack:** Save for 2-tech-stack.mdc document
|
||||
- **Database Schemas:** Keep data models conceptual
|
||||
- **API Specifications:** Focus on capabilities, not endpoints
|
||||
- **Performance Metrics:** Describe goals, not technical benchmarks
|
||||
|
||||
## Output
|
||||
|
||||
- **Format:** Markdown (`.mdc`)
|
||||
- **Location:** `.claude/rules/`
|
||||
- **Filename:** `1-app-design-document.mdc`
|
||||
|
||||
## Execution Steps
|
||||
|
||||
### 1. Start with Analysis
|
||||
|
||||
- Use Read, Glob, and Grep to explore the codebase
|
||||
- Identify key features and patterns
|
||||
- Look for existing documentation
|
||||
- **Use extended thinking:** "Think deeply about this codebase's architecture, business purpose, and how different components work together to serve users"
|
||||
|
||||
### 2. Interactive Q&A
|
||||
|
||||
- **MUST ASK PROJECT STAGE FIRST**
|
||||
- Present questions with numbered/lettered options
|
||||
- Wait for user responses before proceeding
|
||||
|
||||
### 3. Update Project Status in Cursor Rule
|
||||
|
||||
Update `.claude/rules/3-project-status.mdc` with the project stage information:
|
||||
|
||||
```markdown
|
||||
---
|
||||
description: Project status and stage-specific development guidelines
|
||||
globs:
|
||||
alwaysApply: true
|
||||
---
|
||||
|
||||
# Project Status Guidelines
|
||||
|
||||
## Current Project Stage: [Stage Name]
|
||||
|
||||
**Stage**: [Pre-MVP | MVP | Production | Enterprise]
|
||||
|
||||
### DO Care About (Current Stage Priorities)
|
||||
|
||||
[Stage-specific DO priorities from template below]
|
||||
|
||||
### DO NOT Care About (Skip for Velocity)
|
||||
|
||||
[Stage-specific DON'T priorities from template below]
|
||||
|
||||
### Development Approach
|
||||
|
||||
[Stage-specific development focus]
|
||||
|
||||
## Stage-Based Development Guidelines
|
||||
|
||||
[Keep existing stage categories and guidelines from the original file]
|
||||
```
|
||||
|
||||
**Stage-Specific Content:**
|
||||
|
||||
- **Pre-MVP**:
|
||||
|
||||
- ✅ DO: Core functionality, security basics, input validation, working features
|
||||
- ❌ DON'T: Unit tests, performance optimization, accessibility polish, perfect code
|
||||
- 🚀 Focus: Ship fast with security, iterate based on feedback
|
||||
|
||||
- **MVP**:
|
||||
|
||||
- ✅ DO: Critical path testing, basic monitoring, user feedback loops
|
||||
- ❌ DON'T: Comprehensive test coverage, advanced patterns, premature optimization
|
||||
- 🚀 Focus: Stability for early users, rapid iteration
|
||||
|
||||
- **Production**:
|
||||
|
||||
- ✅ DO: Testing, monitoring, performance, accessibility, documentation
|
||||
- ❌ DON'T: Skip security reviews, ignore technical debt
|
||||
- 🚀 Focus: Reliability, scalability, user experience
|
||||
|
||||
- **Enterprise**:
|
||||
- ✅ DO: Comprehensive testing, security audits, team coordination, compliance
|
||||
- ❌ DON'T: Skip documentation, ignore code standards
|
||||
- 🚀 Focus: Team efficiency, maintainability, compliance
|
||||
|
||||
### 4. Generate Document
|
||||
|
||||
- Follow the standard structure
|
||||
- Tailor content to project stage
|
||||
- Keep language accessible
|
||||
|
||||
### 5. Save and Next Steps
|
||||
|
||||
- Create directories: `mkdir -p .claude/docs .claude/rules`
|
||||
- Save design document: `.claude/rules/1-app-design-document.mdc`
|
||||
- Update Claude rule: `.claude/rules/3-project-status.mdc`
|
||||
- Suggest: "Would you like me to create a technical stack document next?"
|
||||
32
commands/create-snippet.md
Normal file
32
commands/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}
|
||||
329
commands/create-tech-stack.md
Normal file
329
commands/create-tech-stack.md
Normal file
@@ -0,0 +1,329 @@
|
||||
---
|
||||
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 .claude/rules/*.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 `.claude/rules/` if needed
|
||||
- Save as `2-tech-stack.mdc`
|
||||
|
||||
## 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 (`.mdc`)
|
||||
- **Location:** `.claude/rules/`
|
||||
- **Filename:** `2-tech-stack.mdc`
|
||||
|
||||
## 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 .claude/docs
|
||||
# Save to .claude/rules/2-tech-stack.mdc
|
||||
```
|
||||
|
||||
### 6. Next Steps
|
||||
|
||||
- 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
|
||||
```
|
||||
1
commands/fix.md
Normal file
1
commands/fix.md
Normal file
@@ -0,0 +1 @@
|
||||
Read and fix the errors you can see in the Bash output.
|
||||
22
commands/install-all.md
Normal file
22
commands/install-all.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
description: Install all dotai registry items in one command
|
||||
allowed-tools: Bash
|
||||
---
|
||||
|
||||
# Install All
|
||||
|
||||
Install all dotai registry items (dotai, flashback, prompt) in one command:
|
||||
|
||||
```bash
|
||||
npx shadcn@latest add https://raw.githubusercontent.com/udecode/dotai/main/registry/all.json
|
||||
```
|
||||
|
||||
After installation, add ruler postinstall to your `package.json` to auto-generate agent instructions:
|
||||
|
||||
```json
|
||||
{
|
||||
"scripts": {
|
||||
"postinstall": "npx skiller@latest apply"
|
||||
}
|
||||
}
|
||||
```
|
||||
12
commands/install.md
Normal file
12
commands/install.md
Normal file
@@ -0,0 +1,12 @@
|
||||
---
|
||||
description: Install dotai prerequisites and project setup files
|
||||
allowed-tools: Bash
|
||||
---
|
||||
|
||||
# Install dotai Prerequisites
|
||||
|
||||
Initialize your project with dotai setup files using shadcn CLI:
|
||||
|
||||
```bash
|
||||
npx shadcn@latest add https://raw.githubusercontent.com/udecode/dotai/main/registry/dotai.json
|
||||
```
|
||||
5
commands/opus.md
Normal file
5
commands/opus.md
Normal file
@@ -0,0 +1,5 @@
|
||||
---
|
||||
model: claude-opus-4-1-20250805
|
||||
---
|
||||
|
||||
$ARGUMENTS
|
||||
302
commands/update-app-design.md
Normal file
302
commands/update-app-design.md
Normal file
@@ -0,0 +1,302 @@
|
||||
---
|
||||
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: @.claude/rules/1-app-design-document.mdc
|
||||
- Last modified: !`stat -f "%Sm" .claude/rules/1-app-design-document.mdc 2>/dev/null || echo "No existing document"`
|
||||
|
||||
## 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 1-app-design-document.mdc
|
||||
- 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/rules/3-project-status.mdc`
|
||||
- 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 1-app-design-document.mdc
|
||||
- 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/rules/3-project-status.mdc`]
|
||||
|
||||
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" .claude/rules/1-app-design-document.mdc
|
||||
|
||||
# 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/rules/3-project-status.mdc`
|
||||
|
||||
## 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 .claude/rules/1-app-design-document.mdc .claude/rules/1-app-design-document.backup.mdc
|
||||
|
||||
# Save updated document
|
||||
# Overwrite .claude/rules/1-app-design-document.mdc
|
||||
```
|
||||
|
||||
## 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 (`.mdc`)
|
||||
- **Location:** `.claude/rules/`
|
||||
- **Filename:** `1-app-design-document.mdc` (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/rules/3-project-status.mdc` if stage/priorities changed
|
||||
5. ✅ Make incremental, targeted updates
|
||||
6. ✅ Preserve document quality and tone
|
||||
7. ✅ Suggest backup for major changes
|
||||
8. ✅ Consider 2-tech-stack.mdc updates if needed
|
||||
10
commands/update-project-structure.md
Normal file
10
commands/update-project-structure.md
Normal file
@@ -0,0 +1,10 @@
|
||||
---
|
||||
allowed-tools: Bash
|
||||
description: Update project structure documentation by running tree script
|
||||
---
|
||||
|
||||
This command is generating the project structure documentation:
|
||||
|
||||
!`bash ~/.claude/plugins/marketplaces/dotai/.claude-plugin/plugins/dotai/scripts/tree.sh`
|
||||
|
||||
Do not do anything else.
|
||||
312
commands/update-tech-stack.md
Normal file
312
commands/update-tech-stack.md
Normal file
@@ -0,0 +1,312 @@
|
||||
---
|
||||
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: @.claude/rules/2-tech-stack.mdc
|
||||
- Last modified: !`stat -f "%Sm" .claude/rules/2-tech-stack.mdc 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 2-tech-stack.mdc 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
|
||||
- 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 '^\*\*.*:' .claude/rules/2-tech-stack.mdc | 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 .claude/rules/2-tech-stack.mdc 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. Save and Backup
|
||||
|
||||
```bash
|
||||
# Optional backup
|
||||
cp .claude/rules/2-tech-stack.mdc .claude/rules/2-tech-stack.backup.md
|
||||
|
||||
# Save updated document
|
||||
# Overwrite .claude/rules/2-tech-stack.mdc
|
||||
```
|
||||
|
||||
## 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 (`.mdc`)
|
||||
- **Location:** `.claude/rules/`
|
||||
- **Filename:** `2-tech-stack.mdc` (overwrites)
|
||||
- **Backup:** Suggest for major changes
|
||||
|
||||
## Final Checklist
|
||||
|
||||
1. ✅ Read existing 2-tech-stack.mdc 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. ✅ Suggest backup if major changes
|
||||
9. ✅ Verify technical accuracy
|
||||
81
plugin.lock.json
Normal file
81
plugin.lock.json
Normal file
@@ -0,0 +1,81 @@
|
||||
{
|
||||
"$schema": "internal://schemas/plugin.lock.v1.json",
|
||||
"pluginId": "gh:udecode/dotai:.claude-plugin/plugins/dotai",
|
||||
"normalized": {
|
||||
"repo": null,
|
||||
"ref": "refs/tags/v20251128.0",
|
||||
"commit": "90cb14ff327a92ee065fe86e14f374e4d3a084d0",
|
||||
"treeHash": "b403a7bc61ec928992bb1ea4cb21fe068a8547511d3672d280f508d28b5d2d50",
|
||||
"generatedAt": "2025-11-28T10:28:48.101558Z",
|
||||
"toolVersion": "publish_plugins.py@0.2.0"
|
||||
},
|
||||
"origin": {
|
||||
"remote": "git@github.com:zhongweili/42plugin-data.git",
|
||||
"branch": "master",
|
||||
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
|
||||
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
|
||||
},
|
||||
"manifest": {
|
||||
"name": "dotai",
|
||||
"description": "Complete development toolkit - documentation, PRDs, design docs, debugging, PR workflows, and planning",
|
||||
"version": "1.0.0"
|
||||
},
|
||||
"content": {
|
||||
"files": [
|
||||
{
|
||||
"path": "README.md",
|
||||
"sha256": "edfe676744400de7453996232c967fbbf64cb950a9f7fb809d1777ffceb2e5e7"
|
||||
},
|
||||
{
|
||||
"path": ".claude-plugin/plugin.json",
|
||||
"sha256": "897bcd2d324808e4f4f44d5d7a7d59167eb1893b8147de4eab2031c534df8d61"
|
||||
},
|
||||
{
|
||||
"path": "commands/opus.md",
|
||||
"sha256": "2a6d97d99876727b28f363bc67a4cdb9c032b692eed81fc97def916c7464ecec"
|
||||
},
|
||||
{
|
||||
"path": "commands/update-tech-stack.md",
|
||||
"sha256": "1ae09d64617d8da4069f7db263f29abec337dc27b6ddadaed683f890ccfdd867"
|
||||
},
|
||||
{
|
||||
"path": "commands/fix.md",
|
||||
"sha256": "701be076640f55a2de880b490010fc1a9bc68b53486b05e6b523307ca788c39d"
|
||||
},
|
||||
{
|
||||
"path": "commands/install-all.md",
|
||||
"sha256": "ba24f97a8182a163dd680d070cb7c167c14f9d4b43e80ed45d4aa5c924adb5e0"
|
||||
},
|
||||
{
|
||||
"path": "commands/update-app-design.md",
|
||||
"sha256": "3c32806168a660c1d1ed63d866495cd15c24518821d6eb0afd15c088c51a09dc"
|
||||
},
|
||||
{
|
||||
"path": "commands/install.md",
|
||||
"sha256": "4f273380046b1ce4126208aeb59b3c3beba924933c16400179ebeb2ceb70016b"
|
||||
},
|
||||
{
|
||||
"path": "commands/update-project-structure.md",
|
||||
"sha256": "a51538c89e05b72e4c07cd87ed5fb909228e10fa064d466d002956f14f1b7621"
|
||||
},
|
||||
{
|
||||
"path": "commands/create-app-design.md",
|
||||
"sha256": "74dbcdfc58fd29dfa18176b87f7ccb2b2d8f3b6c9f27f05f2bab9431689b8b29"
|
||||
},
|
||||
{
|
||||
"path": "commands/create-snippet.md",
|
||||
"sha256": "2a21aff7edd2cad6957a8386a9bbd6d7187047461ac6bedbff58c1efafb8a6ea"
|
||||
},
|
||||
{
|
||||
"path": "commands/create-tech-stack.md",
|
||||
"sha256": "78182da899ee8b6c661662dcd36eba65aa8bba53ca74fbdedfbd3fe0d1b7bcb8"
|
||||
}
|
||||
],
|
||||
"dirSha256": "b403a7bc61ec928992bb1ea4cb21fe068a8547511d3672d280f508d28b5d2d50"
|
||||
},
|
||||
"security": {
|
||||
"scannedAt": null,
|
||||
"scannerVersion": null,
|
||||
"flags": []
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user