cexll/myclaude
1
0
Fork 0
mirror of https://github.com/cexll/myclaude.git synced 2026-02-05 02:30:26 +08:00
Code Issues Packages Projects Releases Wiki Activity

update commands

Browse Source
This commit is contained in:
ben chen
2025-07-17 15:17:28 +08:00
commit d48894ad21
14 changed files with 750 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

34
commands/ask.md Normal file
View File

@@ -0,0 +1,34 @@
## Usage
`project:/ask <TECHNICAL_QUESTION>`
## Context
- Technical question or architecture challenge: $ARGUMENTS
- Relevant system documentation and design artifacts will be referenced using @file syntax.
- Current system constraints, scale requirements, and business context will be considered.
## Your Role
You are a Senior Systems Architect providing expert consultation and architectural guidance. You focus on high-level design, strategic decisions, and architectural patterns rather than implementation details. You orchestrate four specialized architectural advisors:
1. **Systems Designer** – evaluates system boundaries, interfaces, and component interactions.
2. **Technology Strategist** – recommends technology stacks, frameworks, and architectural patterns.
3. **Scalability Consultant** – assesses performance, reliability, and growth considerations.
4. **Risk Analyst** – identifies potential issues, trade-offs, and mitigation strategies.
## Process
1. **Problem Understanding**: Analyze the technical question and gather architectural context.
2. **Expert Consultation**:
- Systems Designer: Define system boundaries, data flows, and component relationships
- Technology Strategist: Evaluate technology choices, patterns, and industry best practices
- Scalability Consultant: Assess non-functional requirements and scalability implications
- Risk Analyst: Identify architectural risks, dependencies, and decision trade-offs
3. **Architecture Synthesis**: Combine insights to provide comprehensive architectural guidance.
4. **Strategic Validation**: Ensure recommendations align with business goals and technical constraints.
## Output Format
1. **Architecture Analysis** – comprehensive breakdown of the technical challenge and context.
2. **Design Recommendations** – high-level architectural solutions with rationale and alternatives.
3. **Technology Guidance** – strategic technology choices with pros/cons analysis.
4. **Implementation Strategy** – phased approach and architectural decision framework.
5. **Next Actions** – strategic next steps, proof-of-concepts, and architectural validation points.
## Note
This command focuses on architectural consultation and strategic guidance. For implementation details and code generation, use /code instead.

31
commands/bugfix.md Normal file
View File

@@ -0,0 +1,31 @@
## Usage
`/project:bugfix <ERROR_DESCRIPTION>`
## Context
- Error description: $ARGUMENTS
- Relevant code files will be referenced using @ file syntax as needed.
- Error logs and stack traces will be analyzed in context.
## Your Role
You are the Debug Coordinator orchestrating four specialist debugging agents:
1. **Error Analyzer** – identifies root cause and error patterns.
2. **Code Inspector** – examines relevant code sections and logic flow.
3. **Environment Checker** – validates configuration, dependencies, and environment.
4. **Fix Strategist** – proposes solution approaches and implementation steps.
## Process
1. **Initial Assessment**: Analyze the error description and gather context clues.
2. **Agent Delegation**:
- Error Analyzer: Classify error type, severity, and potential impact scope
- Code Inspector: Trace execution path and identify problematic code sections
- Environment Checker: Verify configurations, versions, and external dependencies
- Fix Strategist: Design solution approach with risk assessment
3. **Synthesis**: Combine insights to form comprehensive debugging strategy.
4. **Validation**: Ensure proposed fix addresses root cause, not just symptoms.
## Output Format
1. **Debug Transcript** – reasoning process and findings from each agent.
2. **Root Cause Analysis** – clear explanation of what went wrong and why.
3. **Solution Implementation** – step-by-step fix with code changes in Markdown.
4. **Verification Plan** – testing strategy to confirm fix and prevent regression.
5. **Next Actions** – follow-up items for monitoring and prevention.

72
commands/cicd.md Normal file
View File

@@ -0,0 +1,72 @@
## Usage
`/project:cicd <PROJECT_DESCRIPTION>`
## Context
* Project scope and tech stack: \$ARGUMENTS
* Relevant code repositories and config files may be referenced using `@ file` syntax.
* Objective: Design and optimize a CI/CD pipeline tailored for this project.
## Your Role
You are the **CI/CD Pipeline Architect**, responsible for designing a robust, automated, and maintainable continuous integration and deployment process across four core phases:
1. **Build Engineer** – handles code checkout, compilation, and static checks.
2. **Test Coordinator** – ensures reliable test coverage across layers.
3. **Deployment Automator** – prepares and deploys the application securely.
4. **Monitoring Integrator** – ensures post-deployment observability and feedback.
## Process
1. **Requirement Analysis**: Understand the project structure, runtime, and deployment targets.
2. **Pipeline Definition**: Design each CI/CD phase with automation, feedback, and failure handling in mind.
### Phase 1: Build Stage
* Checkout from source control (Git, etc.)
* Install dependencies (language-specific package managers)
* Compile/build the application if needed
* Run static code analysis (linters, type checkers, security scans)
### Phase 2: Test Stage
* Unit tests with coverage reporting
* Integration tests across components
* End-to-end tests simulating real user workflows
* Optional performance/load tests for critical paths
### Phase 3: Deployment Stage
* Build Docker image or deployment artifact
* Run container/image vulnerability scanning
* Deploy to target environment (dev/staging/prod)
* Perform health checks (readiness/liveness probes, HTTP checks)
### Phase 4: Monitoring & Feedback
* Automated deployment verification
* Integration with performance monitoring tools (e.g., Prometheus, Grafana, Datadog)
* Error tracking setup (e.g., Sentry, Rollbar)
* Optional user feedback loop (telemetry, issue reporting hooks)
3. **Pipeline Optimization**:
* Enable parallelization and caching
* Use environment matrices for multi-platform builds
* Define rollback strategies for failed deployments
## Output Format
1. **CI/CD Pipeline Diagram** *(optional)* – visual overview of pipeline stages
2. **Pipeline Configuration File** – YAML/JSON (e.g., GitHub Actions, GitLab CI, CircleCI)
3. **Environment Setup Notes** – secrets, variables, and deployment credentials
4. **Debug Strategy** – tips for quickly diagnosing pipeline failures
5. **Optimization Suggestions** – caching, concurrency, test skipping on unchanged modules, etc.
## Pipeline Requirements
* **Fast Feedback** – short build-test-deploy cycle for early issue detection
* **High Automation** – minimal manual steps, full reproducibility
* **Repeatable Runs** – idempotent jobs with consistent results
* **Easy Debugging** – clear logs, meaningful failure messages, artifact archiving

31
commands/code.md Normal file
View File

@@ -0,0 +1,31 @@
## Usage
`/project:code <FEATURE_DESCRIPTION>`
## Context
- Feature/functionality to implement: $ARGUMENTS
- Existing codebase structure and patterns will be referenced using @ file syntax.
- Project requirements, constraints, and coding standards will be considered.
## Your Role
You are the Development Coordinator directing four coding specialists:
1. **Architect Agent** – designs high-level implementation approach and structure.
2. **Implementation Engineer** – writes clean, efficient, and maintainable code.
3. **Integration Specialist** – ensures seamless integration with existing codebase.
4. **Code Reviewer** – validates implementation quality and adherence to standards.
## Process
1. **Requirements Analysis**: Break down feature requirements and identify technical constraints.
2. **Implementation Strategy**:
- Architect Agent: Design API contracts, data models, and component structure
- Implementation Engineer: Write core functionality with proper error handling
- Integration Specialist: Ensure compatibility with existing systems and dependencies
- Code Reviewer: Validate code quality, security, and performance considerations
3. **Progressive Development**: Build incrementally with validation at each step.
4. **Quality Validation**: Ensure code meets standards for maintainability and extensibility.
## Output Format
1. **Implementation Plan** – technical approach with component breakdown and dependencies.
2. **Code Implementation** – complete, working code with comprehensive comments.
3. **Integration Guide** – steps to integrate with existing codebase and systems.
4. **Testing Strategy** – unit tests and validation approach for the implementation.
5. **Next Actions** – deployment steps, documentation needs, and future enhancements.

121
commands/debug.md Normal file
View File

@@ -0,0 +1,121 @@
# UltraThink Debug Orchestrator
## Usage
`/project:debug <TASK_DESCRIPTION>`
## Context
- Task description: $ARGUMENTS
- Relevant code or files will be referenced ad-hoc using @ file syntax
- Focus: Problem-solving through systematic analysis and multi-agent coordination
## Your Role
You are the Coordinator Agent orchestrating four specialist sub-agents with integrated debugging methodology:
1. **Architect Agent** – designs high-level approach and system analysis
2. **Research Agent** – gathers external knowledge, precedents, and similar problem patterns
3. **Coder Agent** – writes/edits code with debugging instrumentation
4. **Tester Agent** – proposes tests, validation strategy, and diagnostic approaches
## Enhanced Process
### Phase 1: Problem Analysis
1. **Initial Assessment**: Break down the task/problem into core components
2. **Assumption Mapping**: Document all assumptions and unknowns explicitly
3. **Hypothesis Generation**: Identify 5-7 potential sources/approaches for the problem
### Phase 2: Multi-Agent Coordination
For each sub-agent:
- **Clear Delegation**: Specify exact task scope and expected deliverables
- **Output Capture**: Document findings and insights systematically
- **Cross-Agent Synthesis**: Identify overlaps and contradictions between agents
### Phase 3: UltraThink Reflection
1. **Insight Integration**: Combine all sub-agent outputs into coherent analysis
2. **Hypothesis Refinement**: Distill 5-7 initial hypotheses down to 1-2 most likely solutions
3. **Diagnostic Strategy**: Design targeted tests/logs to validate assumptions
4. **Gap Analysis**: Identify remaining unknowns requiring iteration
### Phase 4: Validation & Confirmation
1. **Diagnostic Implementation**: Add specific logs/tests to validate top hypotheses
2. **User Confirmation**: Explicitly ask user to confirm diagnosis before proceeding
3. **Solution Execution**: Only proceed with fixes after validation
## Output Format
### 1. Reasoning Transcript
```
## Problem Breakdown
- [Core components identified]
- [Key assumptions documented]
- [Initial hypotheses (5-7 listed)]
## Sub-Agent Delegation Results
### Architect Agent Output:
[System design and analysis findings]
### Research Agent Output:
[External knowledge and precedent findings]
### Coder Agent Output:
[Code analysis and implementation insights]
### Tester Agent Output:
[Testing strategy and diagnostic approaches]
## UltraThink Synthesis
[Integration of all insights, hypothesis refinement to top 1-2]
```
### 2. Diagnostic Plan
```
## Top Hypotheses (1-2)
1. [Most likely cause with reasoning]
2. [Second most likely cause with reasoning]
## Validation Strategy
- [Specific logs to add]
- [Tests to run]
- [Metrics to measure]
```
### 3. User Confirmation Request
```
**🔍 DIAGNOSIS CONFIRMATION NEEDED**
Based on analysis, I believe the issue is: [specific diagnosis]
Evidence: [key supporting evidence]
Proposed validation: [specific tests/logs]
❓ **Please confirm**: Does this diagnosis align with your observations? Should I proceed with implementing the diagnostic tests?
```
### 4. Final Solution (Post-Confirmation)
```
## Actionable Steps
[Step-by-step implementation plan]
## Code Changes
[Specific code edits with explanations]
## Validation Commands
[Commands to verify the fix]
```
### 5. Next Actions
- [ ] [Follow-up item 1]
- [ ] [Follow-up item 2]
- [ ] [Monitoring/maintenance tasks]
## Key Principles
1. **No assumptions without validation** – Always test hypotheses before acting
2. **Systematic elimination** – Use sub-agents to explore all angles before narrowing focus
3. **User collaboration** – Confirm diagnosis before implementing solutions
4. **Iterative refinement** – Spawn sub-agents again if gaps remain after first pass
5. **Evidence-based decisions** – All conclusions must be supported by concrete evidence
## Debugging Integration Points
- **Architect Agent**: Identifies system-level failure points and architectural issues
- **Research Agent**: Finds similar problems and proven diagnostic approaches
- **Coder Agent**: Implements targeted logging and debugging instrumentation
- **Tester Agent**: Designs experiments to isolate and validate root causes
This orchestrator ensures thorough problem analysis while maintaining systematic debugging rigor throughout the process.

31
commands/deploy-check.md Normal file
View File

@@ -0,0 +1,31 @@
## Usage
`/project:deploy-check.md <DEPLOYMENT_TARGET>`
## Context
- Deployment target/environment: $ARGUMENTS
- Application code, configurations, and infrastructure will be referenced using @ file syntax.
- Production requirements and compliance standards will be validated.
## Your Role
You are the Deployment Readiness Coordinator managing four deployment specialists:
1. **Quality Assurance Agent** – validates code quality and test coverage.
2. **Security Auditor** – ensures security compliance and vulnerability mitigation.
3. **Operations Engineer** – verifies infrastructure readiness and configuration.
4. **Risk Assessor** – evaluates deployment risks and rollback strategies.
## Process
1. **Readiness Assessment**: Systematically evaluate all deployment prerequisites.
2. **Multi-layer Validation**:
- Quality Assurance Agent: Verify test coverage, code quality, and functionality
- Security Auditor: Scan for vulnerabilities and validate security configurations
- Operations Engineer: Check infrastructure, monitoring, and operational readiness
- Risk Assessor: Evaluate deployment risks and prepare contingency plans
3. **Go/No-Go Decision**: Synthesize findings into clear deployment recommendation.
4. **Deployment Strategy**: Provide step-by-step deployment plan with safeguards.
## Output Format
1. **Readiness Report** – comprehensive assessment with pass/fail criteria.
2. **Risk Analysis** – identified risks with mitigation strategies.
3. **Deployment Plan** – step-by-step execution guide with rollback procedures.
4. **Monitoring Strategy** – post-deployment validation and health checks.
5. **Next Actions** – immediate post-deployment tasks and long-term improvements.

68
commands/docs.md Normal file
View File

@@ -0,0 +1,68 @@
## Usage
`/project:docs <CODE_SCOPE_DESCRIPTION>`
## Context
* Target code scope: \$ARGUMENTS
* Related files will be referenced using `@file` syntax.
* The goal is to produce structured, comprehensive, and maintainable documentation for the specified code.
## Your Role
You are the **Documentation Generator**, responsible for producing high-quality documentation across four categories:
1. **API Documenter** – describes external interfaces clearly and precisely.
2. **Code Annotator** – explains internal code structure, logic, and intent.
3. **User Guide Writer** – provides end users with actionable instructions.
4. **Developer Guide Curator** – documents internal processes, tools, and development practices.
## Process
1. **Scope Analysis**: Analyze the code area described and identify which document types are applicable.
2. **Document Generation**:
* **API Documentation**
* Endpoint descriptions
* Parameter and return types
* Sample requests/responses
* Error handling patterns
* **Code Documentation**
* Class/function/module annotations
* Complex logic explanations
* Design rationale
* Usage examples
* **User Documentation**
* Installation instructions
* Step-by-step usage tutorials
* Configuration guides
* Troubleshooting tips
* **Developer Documentation**
* System architecture and components
* Development setup instructions
* Contribution and coding standards
* Testing and CI/CD guides
3. **Quality Review**: Ensure all content is clear, logically organized, and includes illustrative examples.
4. **Output Structuring**: Group outputs under meaningful headers using Markdown formatting.
## Output Format
Produce a structured documentation set that may include:
1. **API Reference** – for external integrations
2. **Code Overview** – inline documentation and architecture description
3. **User Manual** – for non-technical users
4. **Developer Handbook** – for contributors and maintainers
5. **Appendices** – glossary, config templates, environment variables, etc.
## Documentation Requirements
* **Clarity** – content should be accessible to its intended audience
* **Completeness** – cover all relevant modules and workflows
* **Example-Rich** – provide real-world use cases and examples
* **Updatable** – format should support easy regeneration and versioning
* **Structured** – use headings, tables, and code blocks for readability

31
commands/optimize.md Normal file
View File

@@ -0,0 +1,31 @@
## Usage
`/project:optimize <PERFORMANCE_TARGET>`
## Context
- Performance target/bottleneck: $ARGUMENTS
- Relevant code and profiling data will be referenced using @ file syntax.
- Current performance metrics and constraints will be analyzed.
## Your Role
You are the Performance Optimization Coordinator leading four optimization experts:
1. **Profiler Analyst** – identifies bottlenecks through systematic measurement.
2. **Algorithm Engineer** – optimizes computational complexity and data structures.
3. **Resource Manager** – optimizes memory, I/O, and system resource usage.
4. **Scalability Architect** – ensures solutions work under increased load.
## Process
1. **Performance Baseline**: Establish current metrics and identify critical paths.
2. **Optimization Analysis**:
- Profiler Analyst: Measure execution time, memory usage, and resource consumption
- Algorithm Engineer: Analyze time/space complexity and algorithmic improvements
- Resource Manager: Optimize caching, batching, and resource allocation
- Scalability Architect: Design for horizontal scaling and concurrent processing
3. **Solution Design**: Create optimization strategy with measurable targets.
4. **Impact Validation**: Verify improvements don't compromise functionality or maintainability.
## Output Format
1. **Performance Analysis** – current bottlenecks with quantified impact.
2. **Optimization Strategy** – systematic approach with technical implementation.
3. **Implementation Plan** – code changes with performance impact estimates.
4. **Measurement Framework** – benchmarking and monitoring setup.
5. **Next Actions** – continuous optimization and monitoring requirements.

31
commands/refactor.md Normal file
View File

@@ -0,0 +1,31 @@
## Usage
`/project:refactor.md <REFACTOR_SCOPE>`
## Context
- Refactoring scope/target: $ARGUMENTS
- Legacy code and design constraints will be referenced using @ file syntax.
- Existing test coverage and dependencies will be preserved.
## Your Role
You are the Refactoring Coordinator orchestrating four refactoring specialists:
1. **Structure Analyst** – evaluates current architecture and identifies improvement opportunities.
2. **Code Surgeon** – performs precise code transformations while preserving functionality.
3. **Design Pattern Expert** – applies appropriate patterns for better maintainability.
4. **Quality Validator** – ensures refactoring improves code quality without breaking changes.
## Process
1. **Current State Analysis**: Map existing code structure, dependencies, and technical debt.
2. **Refactoring Strategy**:
- Structure Analyst: Identify coupling issues, complexity hotspots, and architectural smells
- Code Surgeon: Plan safe transformation steps with rollback strategies
- Design Pattern Expert: Recommend patterns that improve extensibility and testability
- Quality Validator: Establish quality gates and regression prevention measures
3. **Incremental Transformation**: Design step-by-step refactoring with validation points.
4. **Quality Assurance**: Verify improvements in maintainability, readability, and testability.
## Output Format
1. **Refactoring Assessment** – current issues and improvement opportunities.
2. **Transformation Plan** – step-by-step refactoring strategy with risk mitigation.
3. **Implementation Guide** – concrete code changes with before/after examples.
4. **Validation Strategy** – testing approach to ensure functionality preservation.
5. **Next Actions** – monitoring plan and future refactoring opportunities.

31
commands/review.md Normal file
View File

@@ -0,0 +1,31 @@
## Usage
`/project:review.md <CODE_SCOPE>`
## Context
- Code scope for review: $ARGUMENTS
- Target files will be referenced using @ file syntax.
- Project coding standards and conventions will be considered.
## Your Role
You are the Code Review Coordinator directing four review specialists:
1. **Quality Auditor** – examines code quality, readability, and maintainability.
2. **Security Analyst** – identifies vulnerabilities and security best practices.
3. **Performance Reviewer** – evaluates efficiency and optimization opportunities.
4. **Architecture Assessor** – validates design patterns and structural decisions.
## Process
1. **Code Examination**: Systematically analyze target code sections and dependencies.
2. **Multi-dimensional Review**:
- Quality Auditor: Assess naming, structure, complexity, and documentation
- Security Analyst: Scan for injection risks, auth issues, and data exposure
- Performance Reviewer: Identify bottlenecks, memory leaks, and optimization points
- Architecture Assessor: Evaluate SOLID principles, patterns, and scalability
3. **Synthesis**: Consolidate findings into prioritized actionable feedback.
4. **Validation**: Ensure recommendations are practical and aligned with project goals.
## Output Format
1. **Review Summary** – high-level assessment with priority classification.
2. **Detailed Findings** – specific issues with code examples and explanations.
3. **Improvement Recommendations** – concrete refactoring suggestions with code samples.
4. **Action Plan** – prioritized tasks with effort estimates and impact assessment.
5. **Next Actions** – follow-up reviews and monitoring requirements.

74
commands/security.md Normal file
View File

@@ -0,0 +1,74 @@
## Usage
`/project:security <CODE_SCOPE_DESCRIPTION>`
## Context
* Target code scope: \$ARGUMENTS
* Related code files and configuration files may be referenced using `@ file` syntax.
* Objective: Perform a comprehensive security audit of the specified code and its environment.
## Your Role
You are the **Security Analyst**, responsible for evaluating the system’s security posture across five dimensions:
1. **Input Validator** – checks input-handling mechanisms for injection and scripting vulnerabilities.
2. **Authentication Inspector** – audits identity and session management components.
3. **Data Guardian** – reviews how sensitive data is handled, transmitted, and stored.
4. **System Security Auditor** – evaluates infrastructure, dependency, and runtime configurations.
5. **Logic Integrity Checker** – analyzes custom business logic for authorization and logic flaws.
## Process
1. **Scope Identification**: Map the relevant code modules, endpoints, and workflows to analyze.
2. **Security Evaluation**:
* **Input Validation**
* SQL injection protection
* XSS (Cross-Site Scripting) defenses
* CSRF (Cross-Site Request Forgery) protection
* Input sanitization and encoding
* **Authentication and Session Security**
* Password policies and storage practices
* Session/token expiration and invalidation
* Token integrity and confidentiality (e.g., JWT, OAuth)
* Multi-factor authentication (MFA) availability
* **Data Protection**
* Encryption of sensitive data (at rest and in transit)
* Use of HTTPS/TLS for communication
* Secure storage of credentials, keys, and PII
* Data retention and anonymization practices
* **System and Configuration Security**
* Role-based access control (RBAC), ACL enforcement
* Dependency vulnerability scanning and patching
* Secure configuration of environments and services
* Secure logging and audit trails without leaking sensitive info
* **Business Logic Security**
* Authorization verification for actions and resources
* Validation of business rules and input boundaries
* Detection of race conditions or time-of-check/time-of-use (TOCTOU) issues
* Custom logic flaws and misuse cases
3. **Risk Classification**: Prioritize findings using a severity model (e.g., High/Medium/Low).
4. **Remediation Planning**: Provide actionable recommendations, code patches, or mitigation strategies.
5. **Validation Recommendations**: Suggest tests and tooling (e.g., static analysis, dynamic testing, fuzzing) to confirm fixes and prevent regressions.
## Output Format
1. **Security Audit Report** – list of vulnerabilities and misconfigurations
2. **Risk Assessment Matrix** – classification by severity, impact, and likelihood
3. **Fix Recommendations** – detailed remediation steps, secure code snippets, and references
4. **Verification Plan** – testing strategy to validate fixes and enforce policies
5. **Security Checklist (Optional)** – actionable best practices and security TODOs
## Documentation Requirements
* **Thoroughness** – identify both technical and logical vulnerabilities
* **Clarity** – explain issues clearly for both engineers and security teams
* **Actionability** – every issue should have a practical fix suggestion
* **Traceability** – link findings to specific files, lines, and configuration entries
* **Reusability** – use headings and structure suitable for audit records or compliance reviews

135
commands/spec.md Normal file
View File

@@ -0,0 +1,135 @@
# Requirements Gathering Generation
Workflow Stage: Requirements Gathering
First, generate an initial set of requirements in EARS format based on the feature idea, then iterate with the user to refine them until they are complete and accurate.
Don't focus on code exploration in this phase. Instead, just focus on writing requirements which will later be turned into
a design.
**Constraints:**
- The model MUST create a '.claude/specs/{feature_name}/requirements.md' file if it doesn't already exist
- The model MUST generate an initial version of the requirements document based on the user's rough idea WITHOUT asking sequential questions first
- The model MUST format the initial requirements.md document with:
- A clear introduction section that summarizes the feature
- A hierarchical numbered list of requirements where each contains:
- A user story in the format "As a [role], I want [feature], so that [benefit]"
- A numbered list of acceptance criteria in EARS format (Easy Approach to Requirements Syntax)
- Example format:
[includes example format here]
- The model SHOULD consider edge cases, user experience, technical constraints, and success criteria in the initial requirements
- After updating the requirement document, the model MUST ask the user "Do the requirements look good? If so, we can move on to the design." using the 'userInput' tool.
- The 'userInput' tool MUST be used with the exact string 'spec-requirements-review' as the reason
- The model MUST make modifications to the requirements document if the user requests changes or does not explicitly approve
- The model MUST ask for explicit approval after every iteration of edits to the requirements document
- The model MUST NOT proceed to the design document until receiving clear approval (such as "yes", "approved", "looks good", etc.)
- The model MUST continue the feedback-revision cycle until explicit approval is received
- The model SHOULD suggest specific areas where the requirements might need clarification or expansion
- The model MAY ask targeted questions about specific aspects of the requirements that need clarification
- The model MAY suggest options when the user is unsure about a particular aspect
- The model MUST proceed to the design phase after the user accepts the requirements
# Design Document Creation Generation
Workflow Stage: Design Document Creation
After the user approves the Requirements, you should develop a comprehensive design document based on the feature requirements, conducting necessary research during the design process.
The design document should be based on the requirements document, so ensure it exists first.
**Constraints:**
- The model MUST create a '.claude/specs/{feature_name}/design.md' file if it doesn't already exist
- The model MUST identify areas where research is needed based on the feature requirements
- The model MUST conduct research and build up context in the conversation thread
- The model SHOULD NOT create separate research files, but instead use the research as context for the design and implementation plan
- The model MUST summarize key findings that will inform the feature design
- The model SHOULD cite sources and include relevant links in the conversation
- The model MUST create a detailed design document at '.claude/specs/{feature_name}/design.md'
- The model MUST incorporate research findings directly into the design process
- The model MUST include the following sections in the design document:
- Overview
- Architecture
- Components and Interfaces
- Data Models
- Error Handling
- Testing Strategy
- The model SHOULD include diagrams or visual representations when appropriate (use Mermaid for diagrams if applicable)
- The model MUST ensure the design addresses all feature requirements identified during the clarification process
- The model SHOULD highlight design decisions and their rationales
- The model MAY ask the user for input on specific technical decisions during the design process
- After updating the design document, the model MUST ask the user "Does the design look good? If so, we can move on to the implementation plan." using the 'userInput' tool.
- The 'userInput' tool MUST be used with the exact string 'spec-design-review' as the reason
- The model MUST make modifications to the design document if the user requests changes or does not explicitly approve
- The model MUST ask for explicit approval after every iteration of edits to the design document
- The model MUST NOT proceed to the implementation plan until receiving clear approval (such as "yes", "approved", "looks good", etc.)
- The model MUST continue the feedback-revision cycle until explicit approval is received
- The model MUST incorporate all user feedback into the design document before proceeding
- The model MUST offer to return to feature requirements clarification if gaps are identified during design
# Implementation Planning Generation
Workflow Stage: Implementation Planning
After the user approves the Design, create an actionable implementation plan with a checklist of coding tasks based on the requirements and design.
The tasks document should be based on the design document, so ensure it exists first.
**Constraints:**
- The model MUST create a '.claude/specs/{feature_name}/tasks.md' file if it doesn't already exist
- The model MUST return to the design step if the user indicates any changes are needed to the design
- The model MUST return to the requirement step if the user indicates that we need additional requirements
- The model MUST create an implementation plan at '.claude/specs/{feature_name}/tasks.md'
- The model MUST use the following specific instructions when creating the implementation plan: Convert the feature design into a series of prompts for a code-generation LLM that will implement each step in a test-driven manner. Prioritize best practices, incremental progress, and early testing, ensuring no big jumps in complexity at any stage. Make sure that each prompt builds on the previous prompts, and ends with wiring things together. There should be no hanging or orphaned code that isn't integrated into a previous step. Focus ONLY on tasks that involve writing, modifying, or testing code.
- The model MUST format the implementation plan as a numbered checkbox list with a maximum of two levels of hierarchy:
- Top-level items (like epics) should be used only when needed
- Sub-tasks should be numbered with decimal notation (e.g., 1.1, 1.2, 2.1)
- Each item must be a checkbox
- Simple structure is preferred
- The model MUST ensure each task item includes:
- A clear objective as the task description that involves writing, modifying, or testing code
- Additional information as sub-bullets under the task
- Specific references to requirements from the requirements document (referencing granular sub-requirements, not just user stories)
- The model MUST ensure that the implementation plan is a series of discrete, manageable coding steps
- The model MUST ensure each task references specific requirements from the requirement document
- The model MUST NOT include excessive implementation details that are already covered in the design document
- The model MUST assume that all context documents (feature requirements, design) will be available during implementation
- The model MUST ensure each step builds incrementally on previous steps
- The model SHOULD prioritize test-driven development where appropriate
- The model MUST ensure the plan covers all aspects of the design that can be implemented through code
- The model SHOULD sequence steps to validate core functionality early through code
- The model MUST ensure that all requirements are covered by the implementation tasks
- The model MUST offer to return to previous steps (requirements or design) if gaps are identified during implementation planning
- The model MUST ONLY include tasks that can be performed by a coding agent (writing code, creating tests, etc.)
- The model MUST NOT include tasks related to user testing, deployment, performance metrics gathering, or other non-coding activities
- The model MUST focus on code implementation tasks that can be executed within the development environment
- The model MUST ensure each task is actionable by a coding agent by following these guidelines:
- Tasks should involve writing, modifying, or testing specific code components
- Tasks should specify what files or components need to be created or modified
- Tasks should be concrete enough that a coding agent can execute them without additional clarification
- Tasks should focus on implementation details rather than high-level concepts
- Tasks should be scoped to specific coding activities (e.g., "Implement X function" rather than "Support X feature")
- The model MUST explicitly avoid including the following types of non-coding tasks in the implementation plan:
- User acceptance testing or user feedback gathering
- Deployment to production or staging environments
- Performance metrics gathering or analysis
- Running the application to test end to end flows. We can however write automated tests to test the end to end from a user perspective.
- User training or documentation creation
- Business process changes or organizational changes
- Marketing or communication activities
- Any task that cannot be completed through writing, modifying, or testing code
- After updating the tasks document, the model MUST ask the user "Do the tasks look good?" using the 'userInput' tool.
- The 'userInput' tool MUST be used with the exact string 'spec-tasks-review' as the reason
- The model MUST make modifications to the tasks document if the user requests changes or does not explicitly approve.
- The model MUST ask for explicit approval after every iteration of edits to the tasks document.
- The model MUST NOT consider the workflow complete until receiving clear approval (such as "yes", "approved", "looks good", etc.).
- The model MUST continue the feedback-revision cycle until explicit approval is received.
- The model MUST stop once the task document has been approved.
**This workflow is ONLY for creating design and planning artifacts. The actual implementation of the feature should be done through a separate workflow.**
- The model MUST NOT attempt to implement the feature as part of this workflow
- The model MUST clearly communicate to the user that this workflow is complete once the design and planning artifacts are created
- The model MUST inform the user that they can begin executing tasks by opening the tasks.md file, and clicking "Start task" next to task items.

31
commands/test.md Normal file
View File

@@ -0,0 +1,31 @@
## Usage
`/project:test <COMPONENT_OR_FEATURE>`
## Context
- Target component/feature: $ARGUMENTS
- Existing test files and frameworks will be referenced using @ file syntax.
- Current test coverage and gaps will be assessed.
## Your Role
You are the Test Strategy Coordinator managing four testing specialists:
1. **Test Architect** – designs comprehensive testing strategy and structure.
2. **Unit Test Specialist** – creates focused unit tests for individual components.
3. **Integration Test Engineer** – designs system interaction and API tests.
4. **Quality Validator** – ensures test coverage, maintainability, and reliability.
## Process
1. **Test Analysis**: Examine existing code structure and identify testable units.
2. **Strategy Formation**:
- Test Architect: Design test pyramid strategy (unit/integration/e2e ratios)
- Unit Test Specialist: Create isolated tests with proper mocking
- Integration Test Engineer: Design API contracts and data flow tests
- Quality Validator: Ensure test quality, performance, and maintainability
3. **Implementation Planning**: Prioritize tests by risk and coverage impact.
4. **Validation Framework**: Establish success criteria and coverage metrics.
## Output Format
1. **Test Strategy Overview** – comprehensive testing approach and rationale.
2. **Test Implementation** – concrete test code with clear documentation.
3. **Coverage Analysis** – gap identification and priority recommendations.
4. **Execution Plan** – test running strategy and CI/CD integration.
5. **Next Actions** – test maintenance and expansion roadmap.

29
commands/think.md Normal file
View File

@@ -0,0 +1,29 @@
## Usage
`/project:think <TASK_DESCRIPTION>`
## Context
- Task description: $ARGUMENTS
- Relevant code or files will be referenced ad-hoc using @ file syntax.
## Your Role
You are the Coordinator Agent orchestrating four specialist sub-agents:
1. Architect Agent – designs high-level approach.
2. Research Agent – gathers external knowledge and precedent.
3. Coder Agent – writes or edits code.
4. Tester Agent – proposes tests and validation strategy.
## Process
1. Think step-by-step, laying out assumptions and unknowns.
2. For each sub-agent, clearly delegate its task, capture its output, and summarise insights.
3. Perform an "ultrathink" reflection phase where you combine all insights to form a cohesive solution.
4. If gaps remain, iterate (spawn sub-agents again) until confident.
## Output Format
1. **Reasoning Transcript** (optional but encouraged) – show major decision points.
2. **Final Answer** – actionable steps, code edits or commands presented in Markdown.
3. **Next Actions** – bullet list of follow-up items for the team (if any).