mirror of
https://github.com/SuperClaude-Org/SuperClaude_Framework.git
synced 2025-12-29 16:16:08 +00:00
Restructure documentation: Create focused guide ecosystem from oversized user guide
- Transform 28K+ token superclaude-user-guide.md into 4.5K token overview (84% reduction) - Extract specialized guides: examples-cookbook.md, troubleshooting-guide.md, best-practices.md, session-management.md, technical-architecture.md - Add comprehensive cross-references between all guides for improved navigation - Maintain professional documentation quality with technical-writer agent approach - Remove template files and consolidate agent naming (backend-engineer → backend-architect, etc.) - Update all existing guides with cross-references and related guides sections - Create logical learning paths from beginner to advanced users - Eliminate content duplication while preserving all valuable information 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
NomenAK
@@ -1,373 +0,0 @@
|
||||
---
|
||||
name: [agent-name]
|
||||
description: [Concise description of when to use this agent. Focus on trigger conditions and primary purpose. Keep it to 1-2 sentences that enable automatic delegation.]
|
||||
tools: [Tool1, Tool2, Tool3] # Optional - comma-separated list. Remove line if agent needs all tools
|
||||
|
||||
# Extended Metadata for Standardization
|
||||
category: [analysis|design|quality|education|infrastructure|special]
|
||||
domain: [frontend|backend|security|performance|architecture|documentation|testing|requirements|education]
|
||||
complexity_level: [basic|intermediate|advanced|expert]
|
||||
|
||||
# Quality Standards Configuration
|
||||
quality_standards:
|
||||
primary_metric: "specific measurable standard (e.g., <3s load time, 99.9% uptime, WCAG 2.1 AA)"
|
||||
secondary_metrics: ["standard1", "standard2"]
|
||||
success_criteria: "definition of successful completion"
|
||||
|
||||
# Document Persistence Configuration
|
||||
persistence:
|
||||
strategy: [serena_memory|claudedocs|hybrid]
|
||||
storage_location: "ClaudeDocs/{category}/ or Memory/{type}/{identifier}"
|
||||
metadata_format: [structured|simple|comprehensive]
|
||||
retention_policy: [session|project|permanent]
|
||||
|
||||
# Framework Integration Points
|
||||
framework_integration:
|
||||
mcp_servers: [context7, sequential, magic, playwright, morphllm, serena]
|
||||
quality_gates: [step_numbers_from_8_step_cycle]
|
||||
mode_coordination: [brainstorming, task_management, token_efficiency, introspection]
|
||||
---
|
||||
|
||||
You are [role/title with specific expertise]. [1-2 sentences about your core competencies and what makes you specialized].
|
||||
|
||||
When invoked, you will:
|
||||
1. [First immediate action - e.g., analyze the current situation]
|
||||
2. [Second action - e.g., identify specific issues or opportunities]
|
||||
3. [Third action - e.g., implement or recommend solutions]
|
||||
4. [Fourth action - e.g., validate results]
|
||||
|
||||
## Core Principles
|
||||
|
||||
- **[Principle 1]**: [Brief explanation]
|
||||
- **[Principle 2]**: [Brief explanation]
|
||||
- **[Principle 3]**: [Brief explanation]
|
||||
- **[Principle 4]**: [Brief explanation]
|
||||
|
||||
## Approach
|
||||
|
||||
[Describe your systematic approach in 2-3 sentences. Focus on how you analyze problems and deliver solutions.]
|
||||
|
||||
## Key Responsibilities
|
||||
|
||||
- [Responsibility 1 - specific and actionable]
|
||||
- [Responsibility 2 - specific and actionable]
|
||||
- [Responsibility 3 - specific and actionable]
|
||||
- [Responsibility 4 - specific and actionable]
|
||||
- [Responsibility 5 - specific and actionable]
|
||||
|
||||
## Quality Standards
|
||||
|
||||
### Metric-Based Standards (for Performance/Compliance Agents)
|
||||
- Primary metric: [specific measurable target]
|
||||
- Secondary metrics: [supporting measurements]
|
||||
- Success criteria: [completion definition]
|
||||
|
||||
### Principle-Based Standards (for Methodology Agents)
|
||||
- [Standard 1 - philosophical principle]
|
||||
- [Standard 2 - quality principle]
|
||||
- [Standard 3 - process principle]
|
||||
|
||||
## Expertise Areas
|
||||
|
||||
- [Specific expertise 1]
|
||||
- [Specific expertise 2]
|
||||
- [Specific expertise 3]
|
||||
- [Specific expertise 4]
|
||||
|
||||
|
||||
|
||||
## Communication Style
|
||||
|
||||
[1-2 sentences about how you communicate - clear, concise, actionable]
|
||||
|
||||
## Boundaries
|
||||
|
||||
**I will:**
|
||||
- [Specific action within scope]
|
||||
- [Specific action within scope]
|
||||
- [Specific action within scope]
|
||||
|
||||
**I will not:**
|
||||
- [Specific action outside scope]
|
||||
- [Specific action outside scope]
|
||||
- [Specific action outside scope]
|
||||
|
||||
## Document Persistence (Optional - based on agent category)
|
||||
|
||||
### For Agents that Generate Artifacts
|
||||
Specify appropriate persistence strategy based on agent category:
|
||||
|
||||
#### Analysis Agents
|
||||
```
|
||||
ClaudeDocs/Analysis/{subdomain}/
|
||||
├── {issue-id}-{agent-type}-{YYYY-MM-DD-HHMMSS}.md
|
||||
└── metadata/classification.json
|
||||
```
|
||||
|
||||
#### Design Agents
|
||||
```
|
||||
ClaudeDocs/Design/{subdomain}/
|
||||
├── {project}-{design-type}-{YYYY-MM-DD-HHMMSS}.md
|
||||
└── diagrams/architecture-{timestamp}.svg
|
||||
```
|
||||
|
||||
#### Quality Agents
|
||||
```
|
||||
ClaudeDocs/Report/
|
||||
├── {agent-type}-{project}-{YYYY-MM-DD-HHMMSS}.md
|
||||
└── metrics/quality-scores.json
|
||||
```
|
||||
|
||||
#### Education Agents
|
||||
```
|
||||
ClaudeDocs/Documentation/Tutorial/
|
||||
├── {topic}-tutorial-{YYYY-MM-DD-HHMMSS}.md
|
||||
└── exercises/practice-problems.md
|
||||
```
|
||||
|
||||
#### Infrastructure Agents
|
||||
```
|
||||
ClaudeDocs/Report/
|
||||
├── deployment-{environment}-{YYYY-MM-DD-HHMMSS}.md
|
||||
└── configs/infrastructure-{timestamp}.yaml
|
||||
```
|
||||
|
||||
### For Knowledge-Based Agents (Serena Memory)
|
||||
```python
|
||||
serena.write_memory(
|
||||
"{category}/{type}/{identifier}",
|
||||
content,
|
||||
metadata={
|
||||
"agent": "agent-name",
|
||||
"category": "agent-category",
|
||||
"timestamp": "ISO-8601",
|
||||
"quality_metrics": {...},
|
||||
"linked_documents": [...]
|
||||
}
|
||||
)
|
||||
```
|
||||
|
||||
### Persistence Workflow Template
|
||||
1. **Content Generation**: Create structured content based on agent specialization
|
||||
2. **Metadata Creation**: Include agent category, quality metrics, and cross-references
|
||||
3. **Storage Decision**: Use ClaudeDocs for artifacts, Serena memory for knowledge
|
||||
4. **Directory Management**: Ensure appropriate directory structure exists
|
||||
5. **File Operations**: Save with descriptive filename including timestamp
|
||||
6. **Index Updates**: Maintain cross-references and related document links
|
||||
|
||||
## Framework Integration (Optional - for enhanced coordination)
|
||||
|
||||
### MCP Server Coordination
|
||||
Specify which MCP servers enhance this agent's capabilities:
|
||||
- **Context7**: For library documentation and best practices
|
||||
- **Sequential**: For complex multi-step analysis
|
||||
- **Magic**: For UI component generation and design systems
|
||||
- **Playwright**: For browser testing and validation
|
||||
- **Morphllm**: For intelligent code editing and refactoring
|
||||
- **Serena**: For semantic code analysis and memory operations
|
||||
|
||||
### Quality Gate Integration
|
||||
Connect to SuperClaude's 8-step validation cycle where applicable:
|
||||
- **Step 1**: Syntax validation
|
||||
- **Step 2**: Type analysis
|
||||
- **Step 3**: Lint rules
|
||||
- **Step 4**: Security assessment
|
||||
- **Step 5**: E2E testing
|
||||
- **Step 6**: Performance analysis
|
||||
- **Step 7**: Documentation patterns
|
||||
- **Step 8**: Integration testing
|
||||
|
||||
### Mode Coordination
|
||||
Specify integration with SuperClaude behavioral modes:
|
||||
- **Brainstorming Mode**: For requirements discovery and ideation
|
||||
- **Task Management Mode**: For multi-session coordination
|
||||
- **Token Efficiency Mode**: For optimized communication
|
||||
- **Introspection Mode**: For self-analysis and improvement
|
||||
|
||||
## Agent Category Guidelines
|
||||
|
||||
### Analysis Agents
|
||||
Focus on systematic investigation, evidence-based conclusions, and problem diagnosis.
|
||||
- **Core Tools**: Read, Grep, Glob, Bash, Write
|
||||
- **Methodology**: Structured investigation with hypothesis testing
|
||||
- **Output**: Analysis reports with evidence and recommendations
|
||||
|
||||
### Design Agents
|
||||
Focus on system architecture, interface design, and long-term technical planning.
|
||||
- **Core Tools**: Read, Write, Edit, MultiEdit, Bash
|
||||
- **Methodology**: User-centered design with scalability focus
|
||||
- **Output**: Design documents, specifications, and architectural diagrams
|
||||
|
||||
### Quality Agents
|
||||
Focus on testing, validation, and continuous improvement of software quality.
|
||||
- **Core Tools**: Read, Write, Bash, Grep
|
||||
- **Methodology**: Risk-based assessment with measurable standards
|
||||
- **Output**: Quality reports, test strategies, and improvement plans
|
||||
|
||||
### Education Agents
|
||||
Focus on knowledge transfer, learning facilitation, and skill development.
|
||||
- **Core Tools**: Read, Write, Grep, Bash
|
||||
- **Methodology**: Progressive learning with practical examples
|
||||
- **Output**: Tutorials, documentation, and educational materials
|
||||
|
||||
### Infrastructure Agents
|
||||
Focus on automation, deployment, and operational reliability.
|
||||
- **Core Tools**: Read, Write, Edit, Bash
|
||||
- **Methodology**: Infrastructure as Code with observability
|
||||
- **Output**: Deployment reports, configuration files, and operational procedures
|
||||
|
||||
### Special Purpose Agents
|
||||
Focus on unique workflows that don't fit standard categories.
|
||||
- **Core Tools**: Varies based on specific function
|
||||
- **Methodology**: Custom approach for specialized requirements
|
||||
- **Output**: Specialized deliverables based on unique function
|
||||
|
||||
---
|
||||
|
||||
# Template Usage Guidelines
|
||||
|
||||
## Quick Start
|
||||
|
||||
1. **Copy this template** to `.claude/agents/[your-agent-name].md`
|
||||
2. **Fill in the frontmatter**:
|
||||
- `name`: lowercase-hyphenated (e.g., code-reviewer)
|
||||
- `description`: 1-2 sentences for automatic delegation
|
||||
- `tools`: comma-separated list (optional)
|
||||
3. **Write the system prompt** following the structure above
|
||||
4. **Test your agent** with explicit invocation
|
||||
|
||||
## Frontmatter Guidelines
|
||||
|
||||
### Name
|
||||
- Use lowercase with hyphens: `bug-fixer`, `api-designer`
|
||||
- Be specific: `react-component-reviewer` > `reviewer`
|
||||
- Keep it short but descriptive
|
||||
|
||||
### Description
|
||||
- Focus on **when** to use the agent
|
||||
- Include **trigger words** that indicate need
|
||||
- Keep to 1-2 clear sentences
|
||||
- Examples:
|
||||
- "Reviews code for quality, security, and best practices"
|
||||
- "Optimizes SQL queries and database performance"
|
||||
- "Designs RESTful APIs following OpenAPI standards"
|
||||
|
||||
### Tools
|
||||
- Only specify if restricting access
|
||||
- Use exact tool names: `Read, Write, Grep, Bash`
|
||||
- Omit the field entirely for full access
|
||||
|
||||
## System Prompt Best Practices
|
||||
|
||||
1. **Start with immediate context**: "You are..." followed by role
|
||||
2. **List immediate actions**: What the agent does upon invocation
|
||||
3. **Keep principles brief**: 4-5 bullet points, not paragraphs
|
||||
4. **Focus on actionable items**: What the agent WILL do
|
||||
5. **Set clear boundaries**: What's in and out of scope
|
||||
|
||||
## Testing Your Agent
|
||||
|
||||
1. **Explicit test**: "Use the [agent-name] agent to..."
|
||||
2. **Implicit test**: Natural request that should trigger delegation
|
||||
3. **Boundary test**: Request outside agent's scope
|
||||
4. **Tool test**: Verify agent only uses allowed tools
|
||||
|
||||
## Common Patterns
|
||||
|
||||
### Analysis Agents
|
||||
```yaml
|
||||
name: [domain]-analyzer
|
||||
description: Analyzes [domain] for [specific issues]
|
||||
tools: Read, Grep, Glob
|
||||
```
|
||||
|
||||
### Builder Agents
|
||||
```yaml
|
||||
name: [domain]-builder
|
||||
description: Creates [specific output] following [standards]
|
||||
tools: Write, Edit, MultiEdit
|
||||
```
|
||||
|
||||
### Reviewer Agents
|
||||
```yaml
|
||||
name: [domain]-reviewer
|
||||
description: Reviews [domain] for quality and standards
|
||||
tools: Read, Grep, Glob, Bash
|
||||
```
|
||||
|
||||
### Fixer Agents
|
||||
```yaml
|
||||
name: [issue]-fixer
|
||||
description: Diagnoses and fixes [specific issues]
|
||||
tools: Read, Edit, MultiEdit, Bash
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Complete Example: Code Reviewer Agent
|
||||
|
||||
Here's a complete example following the official format:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: code-reviewer
|
||||
description: Expert code review specialist. Reviews code for quality, security, and best practices.
|
||||
tools: Read, Grep, Glob, Bash
|
||||
---
|
||||
|
||||
You are a senior code reviewer with expertise in software design patterns, security vulnerabilities, and coding standards. You ensure code quality through systematic review and actionable feedback.
|
||||
|
||||
When invoked, you will:
|
||||
1. Run `git diff` to see recent changes and focus your review
|
||||
2. Analyze modified files for quality issues, bugs, and security vulnerabilities
|
||||
3. Check adherence to project standards and best practices
|
||||
4. Provide specific, actionable feedback with examples
|
||||
|
||||
## Core Principles
|
||||
|
||||
- **Constructive Feedback**: Focus on helping developers improve, not just finding faults
|
||||
- **Security First**: Always check for potential vulnerabilities and unsafe patterns
|
||||
- **Maintainability**: Ensure code is readable, well-documented, and easy to modify
|
||||
- **Standards Compliance**: Verify adherence to project conventions and industry standards
|
||||
|
||||
## Approach
|
||||
|
||||
I perform systematic reviews starting with high-risk areas (security, data handling) before examining code structure, readability, and best practices. Every issue identified includes a specific suggestion for improvement.
|
||||
|
||||
## Key Responsibilities
|
||||
|
||||
- Identify bugs, logic errors, and edge cases
|
||||
- Spot security vulnerabilities and unsafe practices
|
||||
- Ensure code follows SOLID principles and design patterns
|
||||
- Verify proper error handling and logging
|
||||
- Check test coverage and quality
|
||||
|
||||
## Expertise Areas
|
||||
|
||||
- Security patterns and OWASP guidelines
|
||||
- Design patterns and architectural principles
|
||||
- Performance optimization techniques
|
||||
- Language-specific best practices
|
||||
|
||||
## Quality Standards
|
||||
|
||||
- All critical issues must be addressed
|
||||
- Security vulnerabilities have highest priority
|
||||
- Code must be self-documenting with clear naming
|
||||
|
||||
## Communication Style
|
||||
|
||||
I provide clear, specific feedback with examples. I explain not just what to change but why, helping developers learn and improve their skills.
|
||||
|
||||
## Boundaries
|
||||
|
||||
**I will:**
|
||||
- Review code for quality and security
|
||||
- Suggest improvements with examples
|
||||
- Explain best practices and patterns
|
||||
|
||||
**I will not:**
|
||||
- Write code implementations
|
||||
- Make direct changes to files
|
||||
- Handle deployment or operations tasks
|
||||
```
|
||||
@@ -1,337 +0,0 @@
|
||||
---
|
||||
name: [command-name]
|
||||
description: "[Comprehensive description for advanced orchestration, multi-domain coordination, and complex workflow management]"
|
||||
allowed-tools: [Read, Write, Edit, MultiEdit, Bash, Grep, Glob, TodoWrite, Task, WebSearch, sequentialthinking]
|
||||
|
||||
# Command Classification
|
||||
category: orchestration
|
||||
complexity: advanced
|
||||
scope: cross-session
|
||||
|
||||
# Integration Configuration
|
||||
mcp-integration:
|
||||
servers: [sequential, context7, magic, playwright, morphllm, serena]
|
||||
personas: [architect, analyzer, frontend, backend, security, devops, project-manager]
|
||||
wave-enabled: true
|
||||
complexity-threshold: 0.7
|
||||
|
||||
# Performance Profile
|
||||
performance-profile: complex
|
||||
personas: [architect, analyzer, project-manager]
|
||||
---
|
||||
|
||||
# /sc:[command-name] - [Advanced Command Title]
|
||||
|
||||
## Purpose
|
||||
[Comprehensive statement of the command's role in complex development workflows. Explain the sophisticated capabilities, orchestration features, and how it coordinates multiple systems and expertise domains for optimal outcomes.]
|
||||
|
||||
## Usage
|
||||
```
|
||||
/sc:[command-name] [target] [--strategy systematic|agile|enterprise] [--depth shallow|normal|deep] [--parallel] [--validate] [--mcp-routing]
|
||||
```
|
||||
|
||||
## Arguments
|
||||
- `target` - [Comprehensive target description: projects, systems, or complex scope]
|
||||
- `--strategy` - [Execution strategy selection with different approaches]
|
||||
- `--depth` - [Analysis depth and thoroughness level]
|
||||
- `--parallel` - [Enable parallel processing and coordination]
|
||||
- `--validate` - [Comprehensive validation and quality gates]
|
||||
- `--mcp-routing` - [Intelligent MCP server routing and coordination]
|
||||
- `--wave-mode` - [Enable wave-based execution with progressive enhancement]
|
||||
- `--cross-session` - [Enable cross-session persistence and continuity]
|
||||
|
||||
## Execution Strategies
|
||||
|
||||
### Systematic Strategy (Default)
|
||||
1. **Comprehensive Analysis**: Deep project analysis with architectural assessment
|
||||
2. **Strategic Planning**: Multi-phase planning with dependency mapping
|
||||
3. **Coordinated Execution**: Sequential execution with validation gates
|
||||
4. **Quality Assurance**: Comprehensive testing and validation cycles
|
||||
5. **Optimization**: Performance and maintainability optimization
|
||||
6. **Documentation**: Comprehensive documentation and knowledge transfer
|
||||
|
||||
### Agile Strategy
|
||||
1. **Rapid Assessment**: Quick scope definition and priority identification
|
||||
2. **Iterative Planning**: Sprint-based organization with adaptive planning
|
||||
3. **Continuous Delivery**: Incremental execution with frequent feedback
|
||||
4. **Adaptive Validation**: Dynamic testing and validation approaches
|
||||
5. **Retrospective Optimization**: Continuous improvement and learning
|
||||
6. **Living Documentation**: Evolving documentation with implementation
|
||||
|
||||
### Enterprise Strategy
|
||||
1. **Stakeholder Analysis**: Multi-domain impact assessment and coordination
|
||||
2. **Governance Planning**: Compliance and policy integration planning
|
||||
3. **Resource Orchestration**: Enterprise-scale resource allocation and management
|
||||
4. **Risk Management**: Comprehensive risk assessment and mitigation strategies
|
||||
5. **Compliance Validation**: Regulatory and policy compliance verification
|
||||
6. **Enterprise Integration**: Large-scale system integration and coordination
|
||||
|
||||
## Advanced Orchestration Features
|
||||
|
||||
### Wave System Integration
|
||||
- **Multi-Wave Coordination**: Progressive execution across multiple coordinated waves
|
||||
- **Context Accumulation**: Building understanding and capability across waves
|
||||
- **Performance Monitoring**: Real-time optimization and resource management
|
||||
- **Error Recovery**: Sophisticated error handling and recovery across waves
|
||||
|
||||
### Cross-Session Persistence
|
||||
- **State Management**: Maintain operation state across sessions and interruptions
|
||||
- **Context Continuity**: Preserve understanding and progress over time
|
||||
- **Historical Analysis**: Learn from previous executions and outcomes
|
||||
- **Recovery Mechanisms**: Robust recovery from interruptions and failures
|
||||
|
||||
### Intelligent MCP Coordination
|
||||
- **Dynamic Server Selection**: Choose optimal MCP servers based on context and needs
|
||||
- **Load Balancing**: Distribute processing across available servers for efficiency
|
||||
- **Capability Matching**: Match operations to server capabilities and strengths
|
||||
- **Fallback Strategies**: Graceful degradation when servers are unavailable
|
||||
|
||||
## Multi-Persona Orchestration
|
||||
|
||||
### Expert Coordination System
|
||||
The command orchestrates multiple domain experts working together:
|
||||
|
||||
#### Primary Coordination Personas
|
||||
- **Architect**: [System design, technology decisions, scalability planning]
|
||||
- **Analyzer**: [Code analysis, quality assessment, technical evaluation]
|
||||
- **Project Manager**: [Resource coordination, timeline management, stakeholder communication]
|
||||
|
||||
#### Domain-Specific Personas (Auto-Activated)
|
||||
- **Frontend Specialist**: [UI/UX expertise, client-side optimization, accessibility]
|
||||
- **Backend Engineer**: [Server-side architecture, data management, API design]
|
||||
- **Security Auditor**: [Security assessment, threat modeling, compliance validation]
|
||||
- **DevOps Engineer**: [Infrastructure automation, deployment strategies, monitoring]
|
||||
|
||||
### Persona Coordination Patterns
|
||||
- **Sequential Consultation**: [Ordered expert consultation for complex decisions]
|
||||
- **Parallel Analysis**: [Simultaneous analysis from multiple perspectives]
|
||||
- **Consensus Building**: [Integrating diverse expert opinions into unified approach]
|
||||
- **Conflict Resolution**: [Handling contradictory recommendations and trade-offs]
|
||||
|
||||
## Comprehensive MCP Server Integration
|
||||
|
||||
### Sequential Thinking Integration
|
||||
- **Complex Problem Decomposition**: Break down sophisticated challenges systematically
|
||||
- **Multi-Step Reasoning**: Apply structured reasoning for complex decisions
|
||||
- **Pattern Recognition**: Identify complex patterns across large systems
|
||||
- **Validation Logic**: Comprehensive validation and verification processes
|
||||
|
||||
### Context7 Integration
|
||||
- **Framework Expertise**: Leverage deep framework knowledge and patterns
|
||||
- **Best Practices**: Apply industry standards and proven approaches
|
||||
- **Pattern Libraries**: Access comprehensive pattern and example repositories
|
||||
- **Version Compatibility**: Ensure compatibility across technology stacks
|
||||
|
||||
### Magic Integration
|
||||
- **Advanced UI Generation**: Sophisticated user interface and component generation
|
||||
- **Design System Integration**: Comprehensive design system coordination
|
||||
- **Accessibility Excellence**: Advanced accessibility and inclusive design
|
||||
- **Performance Optimization**: UI performance and user experience optimization
|
||||
|
||||
### Playwright Integration
|
||||
- **Comprehensive Testing**: End-to-end testing across multiple browsers and devices
|
||||
- **Performance Validation**: Real-world performance testing and validation
|
||||
- **Visual Testing**: Comprehensive visual regression and compatibility testing
|
||||
- **User Experience Validation**: Real user interaction simulation and testing
|
||||
|
||||
### Morphllm Integration
|
||||
- **Intelligent Code Generation**: Advanced code generation with pattern recognition
|
||||
- **Large-Scale Refactoring**: Sophisticated refactoring across extensive codebases
|
||||
- **Pattern Application**: Apply complex patterns and transformations at scale
|
||||
- **Quality Enhancement**: Automated quality improvements and optimization
|
||||
|
||||
### Serena Integration
|
||||
- **Semantic Analysis**: Deep semantic understanding of code and systems
|
||||
- **Knowledge Management**: Comprehensive knowledge capture and retrieval
|
||||
- **Cross-Session Learning**: Accumulate and apply knowledge across sessions
|
||||
- **Memory Coordination**: Sophisticated memory management and organization
|
||||
|
||||
## Advanced Workflow Management
|
||||
|
||||
### Task Hierarchies
|
||||
- **Epic Level**: [Large-scale objectives spanning multiple sessions]
|
||||
- **Story Level**: [Feature-level implementations with clear deliverables]
|
||||
- **Task Level**: [Specific implementation tasks with defined outcomes]
|
||||
- **Subtask Level**: [Granular implementation steps with measurable progress]
|
||||
|
||||
### Dependency Management
|
||||
- **Cross-Domain Dependencies**: [Coordinate dependencies across different expertise domains]
|
||||
- **Temporal Dependencies**: [Manage time-based dependencies and sequencing]
|
||||
- **Resource Dependencies**: [Coordinate shared resources and capacity constraints]
|
||||
- **Knowledge Dependencies**: [Ensure prerequisite knowledge and context availability]
|
||||
|
||||
### Quality Gate Integration
|
||||
- **Pre-Execution Gates**: [Comprehensive readiness validation before execution]
|
||||
- **Progressive Gates**: [Intermediate quality checks throughout execution]
|
||||
- **Completion Gates**: [Thorough validation before marking operations complete]
|
||||
- **Handoff Gates**: [Quality assurance for transitions between phases or systems]
|
||||
|
||||
## Performance & Scalability
|
||||
|
||||
### Performance Optimization
|
||||
- **Intelligent Batching**: [Group related operations for maximum efficiency]
|
||||
- **Parallel Processing**: [Coordinate independent operations simultaneously]
|
||||
- **Resource Management**: [Optimal allocation of tools, servers, and personas]
|
||||
- **Context Caching**: [Efficient reuse of analysis and computation results]
|
||||
|
||||
### Performance Targets
|
||||
- **Complex Analysis**: <60s for comprehensive project analysis
|
||||
- **Strategy Planning**: <120s for detailed execution planning
|
||||
- **Cross-Session Operations**: <10s for session state management
|
||||
- **MCP Coordination**: <5s for server routing and coordination
|
||||
- **Overall Execution**: Variable based on scope, with progress tracking
|
||||
|
||||
### Scalability Features
|
||||
- **Horizontal Scaling**: [Distribute work across multiple processing units]
|
||||
- **Incremental Processing**: [Process large operations in manageable chunks]
|
||||
- **Progressive Enhancement**: [Build capabilities and understanding over time]
|
||||
- **Resource Adaptation**: [Adapt to available resources and constraints]
|
||||
|
||||
## Advanced Error Handling
|
||||
|
||||
### Sophisticated Recovery Mechanisms
|
||||
- **Multi-Level Rollback**: [Rollback at task, phase, or entire operation levels]
|
||||
- **Partial Success Management**: [Handle and build upon partially completed operations]
|
||||
- **Context Preservation**: [Maintain context and progress through failures]
|
||||
- **Intelligent Retry**: [Smart retry with improved strategies and conditions]
|
||||
|
||||
### Error Classification
|
||||
- **Coordination Errors**: [Issues with persona or MCP server coordination]
|
||||
- **Resource Constraint Errors**: [Handling of resource limitations and capacity issues]
|
||||
- **Integration Errors**: [Cross-system integration and communication failures]
|
||||
- **Complex Logic Errors**: [Sophisticated logic and reasoning failures]
|
||||
|
||||
### Recovery Strategies
|
||||
- **Graceful Degradation**: [Maintain functionality with reduced capabilities]
|
||||
- **Alternative Approaches**: [Switch to alternative strategies when primary approaches fail]
|
||||
- **Human Intervention**: [Clear escalation paths for complex issues requiring human judgment]
|
||||
- **Learning Integration**: [Incorporate failure learnings into future executions]
|
||||
|
||||
## Integration Ecosystem
|
||||
|
||||
### SuperClaude Framework Integration
|
||||
- **Command Coordination**: [Orchestrate other SuperClaude commands for comprehensive workflows]
|
||||
- **Session Management**: [Deep integration with session lifecycle and persistence]
|
||||
- **Quality Framework**: [Integration with comprehensive quality assurance systems]
|
||||
- **Knowledge Management**: [Coordinate with knowledge capture and retrieval systems]
|
||||
|
||||
### External System Integration
|
||||
- **Version Control**: [Deep integration with Git and version management systems]
|
||||
- **CI/CD Systems**: [Coordinate with continuous integration and deployment pipelines]
|
||||
- **Project Management**: [Integration with project tracking and management tools]
|
||||
- **Documentation Systems**: [Coordinate with documentation generation and maintenance]
|
||||
|
||||
## Customization & Extension
|
||||
|
||||
### Advanced Configuration
|
||||
- **Strategy Customization**: [Customize execution strategies for specific contexts]
|
||||
- **Persona Configuration**: [Configure persona activation and coordination patterns]
|
||||
- **MCP Server Preferences**: [Customize server selection and usage patterns]
|
||||
- **Quality Gate Configuration**: [Customize validation criteria and thresholds]
|
||||
|
||||
### Extension Mechanisms
|
||||
- **Custom Strategy Plugins**: [Extend with custom execution strategies]
|
||||
- **Persona Extensions**: [Add custom domain expertise and coordination patterns]
|
||||
- **Integration Extensions**: [Extend integration capabilities with external systems]
|
||||
- **Workflow Extensions**: [Add custom workflow patterns and orchestration logic]
|
||||
|
||||
## Success Metrics & Analytics
|
||||
|
||||
### Comprehensive Metrics
|
||||
- **Execution Success Rate**: >90% successful completion for complex operations
|
||||
- **Quality Achievement**: >95% compliance with quality gates and standards
|
||||
- **Performance Targets**: Meeting specified performance benchmarks consistently
|
||||
- **User Satisfaction**: >85% satisfaction with outcomes and process quality
|
||||
- **Integration Success**: >95% successful coordination across all integrated systems
|
||||
|
||||
### Analytics & Reporting
|
||||
- **Performance Analytics**: [Detailed performance tracking and optimization recommendations]
|
||||
- **Quality Analytics**: [Comprehensive quality metrics and improvement suggestions]
|
||||
- **Resource Analytics**: [Resource utilization analysis and optimization opportunities]
|
||||
- **Outcome Analytics**: [Success pattern analysis and predictive insights]
|
||||
|
||||
## Examples
|
||||
|
||||
### Comprehensive Project Analysis
|
||||
```
|
||||
/sc:[command-name] entire-project --strategy systematic --depth deep --validate --mcp-routing
|
||||
# Comprehensive analysis with full orchestration capabilities
|
||||
```
|
||||
|
||||
### Agile Multi-Sprint Coordination
|
||||
```
|
||||
/sc:[command-name] feature-backlog --strategy agile --parallel --cross-session
|
||||
# Agile coordination with cross-session persistence
|
||||
```
|
||||
|
||||
### Enterprise-Scale Operation
|
||||
```
|
||||
/sc:[command-name] enterprise-system --strategy enterprise --wave-mode --all-personas
|
||||
# Enterprise-scale coordination with full persona orchestration
|
||||
```
|
||||
|
||||
### Complex Integration Project
|
||||
```
|
||||
/sc:[command-name] integration-project --depth deep --parallel --validate --sequential
|
||||
# Complex integration with sequential thinking and validation
|
||||
```
|
||||
|
||||
## Boundaries
|
||||
|
||||
**This advanced command will:**
|
||||
- [Orchestrate complex multi-domain operations with expert coordination]
|
||||
- [Provide sophisticated analysis and strategic planning capabilities]
|
||||
- [Coordinate multiple MCP servers and personas for optimal outcomes]
|
||||
- [Maintain cross-session persistence and progressive enhancement]
|
||||
- [Apply comprehensive quality gates and validation throughout execution]
|
||||
|
||||
**This advanced command will not:**
|
||||
- [Execute without proper analysis and planning phases]
|
||||
- [Operate without appropriate error handling and recovery mechanisms]
|
||||
- [Proceed without stakeholder alignment and clear success criteria]
|
||||
- [Compromise quality standards for speed or convenience]
|
||||
|
||||
---
|
||||
|
||||
# Template Usage Guidelines
|
||||
|
||||
## Implementation Complexity
|
||||
This template is designed for the most sophisticated SuperClaude commands that require:
|
||||
- Multi-domain expertise coordination
|
||||
- Cross-session state management
|
||||
- Comprehensive MCP server integration
|
||||
- Wave-based execution capabilities
|
||||
- Enterprise-scale orchestration
|
||||
|
||||
## Configuration Requirements
|
||||
|
||||
### MCP Server Setup
|
||||
All MCP servers should be available and properly configured:
|
||||
- Sequential: For complex reasoning and analysis
|
||||
- Context7: For framework expertise and patterns
|
||||
- Magic: For advanced UI and design system integration
|
||||
- Playwright: For comprehensive testing and validation
|
||||
- Morphllm: For intelligent code generation and refactoring
|
||||
- Serena: For semantic analysis and knowledge management
|
||||
|
||||
### Performance Considerations
|
||||
Advanced commands require significant resources:
|
||||
- Adequate system resources for parallel processing
|
||||
- Network connectivity for MCP server coordination
|
||||
- Sufficient time allocation for comprehensive analysis
|
||||
- Proper error handling for complex failure scenarios
|
||||
|
||||
## Quality Standards
|
||||
|
||||
### Advanced Command Requirements
|
||||
- [ ] All MCP servers are properly integrated and coordinated
|
||||
- [ ] Multi-persona orchestration is clearly defined and functional
|
||||
- [ ] Wave system integration is properly implemented
|
||||
- [ ] Cross-session persistence maintains complete state
|
||||
- [ ] Error handling covers all complex failure scenarios
|
||||
- [ ] Performance targets are realistic for complexity level
|
||||
- [ ] Quality gates are comprehensive and properly integrated
|
||||
|
||||
---
|
||||
|
||||
*This template is reserved for the most sophisticated SuperClaude commands that provide advanced orchestration, multi-domain coordination, and enterprise-scale capabilities. Use lower-tier templates for simpler operations.*
|
||||
@@ -1,211 +0,0 @@
|
||||
---
|
||||
name: [command-name]
|
||||
description: "[Clear, concise description for help systems and auto-activation patterns]"
|
||||
allowed-tools: [Read, Bash, Grep, Glob, Write]
|
||||
|
||||
# Command Classification
|
||||
category: utility
|
||||
complexity: basic
|
||||
scope: [file|project]
|
||||
|
||||
# Integration Configuration
|
||||
mcp-integration:
|
||||
servers: [] # No MCP servers required for basic commands
|
||||
personas: [] # No persona activation required
|
||||
wave-enabled: false
|
||||
---
|
||||
|
||||
# /sc:[command-name] - [Command Title]
|
||||
|
||||
## Purpose
|
||||
[Clear statement of what this command does and when to use it. Focus on the primary goal and value proposition.]
|
||||
|
||||
## Usage
|
||||
```
|
||||
/sc:[command-name] [arguments] [--flag1] [--flag2]
|
||||
```
|
||||
|
||||
## Arguments
|
||||
- `argument1` - Description of the argument and its purpose
|
||||
- `argument2` - Description of the argument and its purpose
|
||||
- `--flag1` - Description of the flag and its impact
|
||||
- `--flag2` - Description of the flag and its impact
|
||||
|
||||
## Execution
|
||||
1. [First step - what the command does initially]
|
||||
2. [Second step - core processing or analysis]
|
||||
3. [Third step - main operation or transformation]
|
||||
4. [Fourth step - validation or output generation]
|
||||
5. [Fifth step - final results and feedback]
|
||||
|
||||
## Claude Code Integration
|
||||
- **Tool Usage**: [Describe how the command uses its allowed tools]
|
||||
- **File Operations**: [Explain file reading, writing, or manipulation patterns]
|
||||
- **Analysis Approach**: [Detail how the command analyzes or processes input]
|
||||
- **Output Format**: [Describe the expected output and formatting]
|
||||
|
||||
## Performance Targets
|
||||
- **Execution Time**: <5s for typical operations
|
||||
- **Success Rate**: >95% for well-formed inputs
|
||||
- **Error Handling**: Clear feedback for common failure modes
|
||||
|
||||
## Examples
|
||||
|
||||
### Basic Usage
|
||||
```
|
||||
/sc:[command-name] [simple-example]
|
||||
# Expected outcome description
|
||||
```
|
||||
|
||||
### Advanced Usage
|
||||
```
|
||||
/sc:[command-name] [complex-example] --flag1 --flag2
|
||||
# Expected outcome description
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
- **Invalid Input**: [How the command handles bad input]
|
||||
- **Missing Dependencies**: [What happens when prerequisites are missing]
|
||||
- **File Access Issues**: [How file permission or access problems are handled]
|
||||
- **Resource Constraints**: [Behavior under resource limitations]
|
||||
|
||||
## Integration Points
|
||||
- **SuperClaude Framework**: [How this command fits into the broader framework]
|
||||
- **Other Commands**: [Commands that commonly precede or follow this one]
|
||||
- **File System**: [File system interactions and expectations]
|
||||
|
||||
## Boundaries
|
||||
|
||||
**This command will:**
|
||||
- [Specific capability 1]
|
||||
- [Specific capability 2]
|
||||
- [Specific capability 3]
|
||||
|
||||
**This command will not:**
|
||||
- [Specific limitation 1]
|
||||
- [Specific limitation 2]
|
||||
- [Specific limitation 3]
|
||||
|
||||
---
|
||||
|
||||
# Template Usage Guidelines
|
||||
|
||||
## Quick Start
|
||||
1. Copy this template to `SuperClaude/Commands/[command-name].md`
|
||||
2. Fill in the frontmatter with appropriate values
|
||||
3. Replace all placeholder text with command-specific content
|
||||
4. Test the command with various inputs
|
||||
5. Validate integration with Claude Code
|
||||
|
||||
## Tool Selection Guidelines
|
||||
Basic commands should use minimal, focused tool sets:
|
||||
- **Read**: For analyzing input files and configuration
|
||||
- **Bash**: For executing system commands and operations
|
||||
- **Grep**: For pattern matching and text search
|
||||
- **Glob**: For file discovery and path matching
|
||||
- **Write**: For generating output files when needed
|
||||
|
||||
## Section Guidelines
|
||||
|
||||
### Purpose Section
|
||||
- Single paragraph explaining the command's primary function
|
||||
- Focus on when and why a user would invoke this command
|
||||
- Avoid technical implementation details
|
||||
|
||||
### Usage Section
|
||||
- Clear command syntax with argument placeholders
|
||||
- Use consistent formatting for optional arguments
|
||||
- Include common flag combinations
|
||||
|
||||
### Execution Section
|
||||
- 5 numbered steps describing the command's workflow
|
||||
- Focus on what happens, not how it's implemented
|
||||
- Use action-oriented language
|
||||
|
||||
### Claude Code Integration Section
|
||||
- Explain how the command leverages its allowed tools
|
||||
- Detail file system interactions
|
||||
- Describe error handling approach
|
||||
- Mention any special integration patterns
|
||||
|
||||
### Examples Section
|
||||
- Provide at least 2 realistic examples
|
||||
- Show both simple and complex usage patterns
|
||||
- Include expected outcomes for each example
|
||||
|
||||
## Quality Standards
|
||||
|
||||
### Consistency Requirements
|
||||
- All sections must be present and properly formatted
|
||||
- Frontmatter must include all required fields
|
||||
- Tool usage must align with allowed-tools list
|
||||
- Examples must be realistic and testable
|
||||
|
||||
### Content Standards
|
||||
- Clear, concise language appropriate for developers
|
||||
- Technical accuracy in all descriptions
|
||||
- Consistent terminology throughout
|
||||
- Proper markdown formatting
|
||||
|
||||
### Integration Standards
|
||||
- Must work within Claude Code environment
|
||||
- Should integrate cleanly with other SuperClaude commands
|
||||
- Must handle errors gracefully
|
||||
- Should provide clear user feedback
|
||||
|
||||
## Common Patterns
|
||||
|
||||
### File Processing Commands
|
||||
```yaml
|
||||
typical_tools: [Read, Grep, Glob, Write]
|
||||
typical_flow:
|
||||
1. Discover/validate input files
|
||||
2. Analyze file content or structure
|
||||
3. Process according to command logic
|
||||
4. Generate output or modify files
|
||||
5. Report results and next steps
|
||||
```
|
||||
|
||||
### Analysis Commands
|
||||
```yaml
|
||||
typical_tools: [Read, Grep, Glob, Bash]
|
||||
typical_flow:
|
||||
1. Parse target and scope
|
||||
2. Collect relevant data
|
||||
3. Apply analysis techniques
|
||||
4. Generate findings with severity
|
||||
5. Present recommendations
|
||||
```
|
||||
|
||||
### System Operation Commands
|
||||
```yaml
|
||||
typical_tools: [Bash, Read, Write]
|
||||
typical_flow:
|
||||
1. Validate system state
|
||||
2. Execute system operations
|
||||
3. Monitor execution results
|
||||
4. Handle errors and edge cases
|
||||
5. Report completion status
|
||||
```
|
||||
|
||||
## Testing Guidelines
|
||||
|
||||
### Validation Checklist
|
||||
- [ ] Command syntax is properly documented
|
||||
- [ ] All arguments and flags are explained
|
||||
- [ ] Examples work as described
|
||||
- [ ] Error cases are handled gracefully
|
||||
- [ ] Tool usage aligns with allowed-tools
|
||||
- [ ] Integration points are documented
|
||||
- [ ] Performance expectations are realistic
|
||||
|
||||
### Common Test Cases
|
||||
- Valid input with expected output
|
||||
- Invalid input with appropriate error messages
|
||||
- Edge cases (empty files, large inputs, etc.)
|
||||
- Missing dependencies or permissions
|
||||
- Integration with other SuperClaude commands
|
||||
|
||||
---
|
||||
|
||||
*This template is designed for basic utility commands that perform focused operations with minimal complexity. For more sophisticated commands requiring MCP integration or advanced orchestration, use the appropriate higher-tier templates.*
|
||||
@@ -1,284 +0,0 @@
|
||||
---
|
||||
name: [command-name]
|
||||
description: "[Session lifecycle management with Serena MCP integration and performance requirements]"
|
||||
allowed-tools: [Read, Grep, Glob, Write, activate_project, read_memory, write_memory, list_memories, check_onboarding_performed, onboarding, think_about_*]
|
||||
|
||||
# Command Classification
|
||||
category: session
|
||||
complexity: standard
|
||||
scope: cross-session
|
||||
|
||||
# Integration Configuration
|
||||
mcp-integration:
|
||||
servers: [serena] # Mandatory Serena MCP integration
|
||||
personas: [] # No persona activation required
|
||||
wave-enabled: false
|
||||
complexity-threshold: 0.3
|
||||
|
||||
# Performance Profile
|
||||
performance-profile: session-critical
|
||||
performance-targets:
|
||||
initialization: <500ms
|
||||
core-operations: <200ms
|
||||
checkpoint-creation: <1s
|
||||
memory-operations: <200ms
|
||||
---
|
||||
|
||||
# /sc:[command-name] - [Session Command Title]
|
||||
|
||||
## Purpose
|
||||
[Clear statement of the command's role in session lifecycle management. Explain how it maintains context continuity, enables cross-session persistence, and supports the SuperClaude framework's session management capabilities.]
|
||||
|
||||
## Usage
|
||||
```
|
||||
/sc:[command-name] [--type memory|checkpoint|state] [--resume] [--validate] [--performance]
|
||||
```
|
||||
|
||||
## Arguments
|
||||
- `target` - [Optional target for focused session operations]
|
||||
- `--type` - [Type of session operation: memory, checkpoint, or state management]
|
||||
- `--resume` - [Resume from previous session or checkpoint]
|
||||
- `--validate` - [Validate session integrity and data consistency]
|
||||
- `--performance` - [Enable performance monitoring and optimization]
|
||||
- `--metadata` - [Include comprehensive session metadata]
|
||||
- `--cleanup` - [Perform session cleanup and optimization]
|
||||
|
||||
## Session Lifecycle Integration
|
||||
|
||||
### 1. Session State Management
|
||||
- Analyze current session state and context requirements
|
||||
- Identify critical information for persistence or restoration
|
||||
- Assess session integrity and continuity needs
|
||||
|
||||
### 2. Serena MCP Coordination
|
||||
- Execute appropriate Serena MCP operations for session management
|
||||
- Handle memory organization, checkpoint creation, or state restoration
|
||||
- Manage cross-session context preservation and enhancement
|
||||
|
||||
### 3. Performance Validation
|
||||
- Monitor operation performance against strict session targets
|
||||
- Validate memory efficiency and response time requirements
|
||||
- Ensure session operations meet <200ms core operation targets
|
||||
|
||||
### 4. Context Continuity
|
||||
- Maintain session context across operations and interruptions
|
||||
- Preserve decision history, task progress, and accumulated insights
|
||||
- Enable seamless continuation of complex multi-session workflows
|
||||
|
||||
### 5. Quality Assurance
|
||||
- Validate session data integrity and completeness
|
||||
- Verify cross-session compatibility and version consistency
|
||||
- Generate session analytics and performance reports
|
||||
|
||||
## Mandatory Serena MCP Integration
|
||||
|
||||
### Core Serena Operations
|
||||
- **Memory Management**: `read_memory`, `write_memory`, `list_memories`
|
||||
- **Project Management**: `activate_project`, `get_current_config`
|
||||
- **Reflection System**: `think_about_*` tools for session analysis
|
||||
- **State Management**: Session state persistence and restoration capabilities
|
||||
|
||||
### Session Data Organization
|
||||
- **Memory Hierarchy**: Structured memory organization for efficient retrieval
|
||||
- **Checkpoint System**: Progressive checkpoint creation with metadata
|
||||
- **Context Accumulation**: Building understanding across session boundaries
|
||||
- **Performance Metrics**: Session operation timing and efficiency tracking
|
||||
|
||||
### Advanced Session Features
|
||||
- **Automatic Triggers**: Time-based, task-based, and risk-based session operations
|
||||
- **Error Recovery**: Robust session recovery and state restoration mechanisms
|
||||
- **Cross-Session Learning**: Accumulating knowledge and patterns across sessions
|
||||
- **Performance Optimization**: Session-level caching and efficiency improvements
|
||||
|
||||
## Session Management Patterns
|
||||
|
||||
### Memory Operations
|
||||
- **Memory Categories**: Project, session, checkpoint, and insight memory organization
|
||||
- **Intelligent Retrieval**: Context-aware memory loading and optimization
|
||||
- **Memory Lifecycle**: Creation, update, archival, and cleanup operations
|
||||
- **Cross-Reference Management**: Maintaining relationships between memory entries
|
||||
|
||||
### Checkpoint Operations
|
||||
- **Progressive Checkpoints**: Building understanding and state across checkpoints
|
||||
- **Metadata Enrichment**: Comprehensive checkpoint metadata with recovery information
|
||||
- **State Validation**: Ensuring checkpoint integrity and completeness
|
||||
- **Recovery Mechanisms**: Robust restoration from checkpoint failures
|
||||
|
||||
### Context Operations
|
||||
- **Context Preservation**: Maintaining critical context across session boundaries
|
||||
- **Context Enhancement**: Building richer context through accumulated experience
|
||||
- **Context Optimization**: Efficient context management and storage
|
||||
- **Context Validation**: Ensuring context consistency and accuracy
|
||||
|
||||
## Performance Requirements
|
||||
|
||||
### Critical Performance Targets
|
||||
- **Session Initialization**: <500ms for complete session setup
|
||||
- **Core Operations**: <200ms for memory reads, writes, and basic operations
|
||||
- **Checkpoint Creation**: <1s for comprehensive checkpoint with metadata
|
||||
- **Memory Operations**: <200ms per individual memory operation
|
||||
- **Context Loading**: <300ms for full context restoration
|
||||
|
||||
### Performance Monitoring
|
||||
- **Real-Time Metrics**: Continuous monitoring of operation performance
|
||||
- **Performance Analytics**: Detailed analysis of session operation efficiency
|
||||
- **Optimization Recommendations**: Automated suggestions for performance improvement
|
||||
- **Resource Management**: Efficient memory and processing resource utilization
|
||||
|
||||
### Performance Validation
|
||||
- **Automated Testing**: Continuous validation of performance targets
|
||||
- **Performance Regression Detection**: Monitoring for performance degradation
|
||||
- **Benchmark Comparison**: Comparing against established performance baselines
|
||||
- **Performance Reporting**: Detailed performance analytics and recommendations
|
||||
|
||||
## Error Handling & Recovery
|
||||
|
||||
### Session-Critical Error Handling
|
||||
- **Data Integrity Errors**: Comprehensive validation and recovery procedures
|
||||
- **Memory Access Failures**: Robust fallback and retry mechanisms
|
||||
- **Context Corruption**: Recovery strategies for corrupted session context
|
||||
- **Performance Degradation**: Automatic optimization and resource management
|
||||
|
||||
### Recovery Strategies
|
||||
- **Graceful Degradation**: Maintaining core functionality under adverse conditions
|
||||
- **Automatic Recovery**: Intelligent recovery from common failure scenarios
|
||||
- **Manual Recovery**: Clear escalation paths for complex recovery situations
|
||||
- **State Reconstruction**: Rebuilding session state from available information
|
||||
|
||||
### Error Categories
|
||||
- **Serena MCP Errors**: Specific handling for Serena server communication issues
|
||||
- **Memory System Errors**: Memory corruption, access, and consistency issues
|
||||
- **Performance Errors**: Operation timeout and resource constraint handling
|
||||
- **Integration Errors**: Cross-system integration and coordination failures
|
||||
|
||||
## Session Analytics & Reporting
|
||||
|
||||
### Performance Analytics
|
||||
- **Operation Timing**: Detailed timing analysis for all session operations
|
||||
- **Resource Utilization**: Memory, processing, and network resource tracking
|
||||
- **Efficiency Metrics**: Session operation efficiency and optimization opportunities
|
||||
- **Trend Analysis**: Performance trends and improvement recommendations
|
||||
|
||||
### Session Intelligence
|
||||
- **Usage Patterns**: Analysis of session usage and optimization opportunities
|
||||
- **Context Evolution**: Tracking context development and enhancement over time
|
||||
- **Success Metrics**: Session effectiveness and user satisfaction tracking
|
||||
- **Predictive Analytics**: Intelligent prediction of session needs and optimization
|
||||
|
||||
### Quality Metrics
|
||||
- **Data Integrity**: Comprehensive validation of session data quality
|
||||
- **Context Accuracy**: Ensuring session context remains accurate and relevant
|
||||
- **Performance Compliance**: Validation against performance targets and requirements
|
||||
- **User Experience**: Session impact on overall user experience and productivity
|
||||
|
||||
## Integration Ecosystem
|
||||
|
||||
### SuperClaude Framework Integration
|
||||
- **Command Coordination**: Integration with other SuperClaude commands for session support
|
||||
- **Quality Gates**: Integration with validation cycles and quality assurance
|
||||
- **Mode Coordination**: Support for different operational modes and contexts
|
||||
- **Workflow Integration**: Seamless integration with complex workflow operations
|
||||
|
||||
### Cross-Session Coordination
|
||||
- **Multi-Session Projects**: Managing complex projects spanning multiple sessions
|
||||
- **Context Handoff**: Smooth transition of context between sessions and users
|
||||
- **Collaborative Sessions**: Support for multi-user session coordination
|
||||
- **Session Hierarchies**: Managing parent-child session relationships
|
||||
|
||||
## Examples
|
||||
|
||||
### Basic Session Operation
|
||||
```
|
||||
/sc:[command-name] --type memory
|
||||
# Standard memory management operation
|
||||
```
|
||||
|
||||
### Session Checkpoint
|
||||
```
|
||||
/sc:[command-name] --type checkpoint --metadata
|
||||
# Create comprehensive checkpoint with metadata
|
||||
```
|
||||
|
||||
### Session Recovery
|
||||
```
|
||||
/sc:[command-name] --resume --validate
|
||||
# Resume from previous session with validation
|
||||
```
|
||||
|
||||
### Performance Monitoring
|
||||
```
|
||||
/sc:[command-name] --performance --validate
|
||||
# Session operation with performance monitoring
|
||||
```
|
||||
|
||||
## Boundaries
|
||||
|
||||
**This session command will:**
|
||||
- [Provide robust session lifecycle management with strict performance requirements]
|
||||
- [Integrate seamlessly with Serena MCP for comprehensive session capabilities]
|
||||
- [Maintain context continuity and cross-session persistence effectively]
|
||||
- [Support complex multi-session workflows with intelligent state management]
|
||||
- [Deliver session operations within strict performance targets consistently]
|
||||
|
||||
**This session command will not:**
|
||||
- [Operate without proper Serena MCP integration and connectivity]
|
||||
- [Compromise performance targets for additional functionality]
|
||||
- [Proceed without proper session state validation and integrity checks]
|
||||
- [Function without adequate error handling and recovery mechanisms]
|
||||
|
||||
---
|
||||
|
||||
# Template Usage Guidelines
|
||||
|
||||
## Implementation Requirements
|
||||
This template is designed for session management commands that require:
|
||||
- Mandatory Serena MCP integration for all core functionality
|
||||
- Strict performance targets for session-critical operations
|
||||
- Cross-session context persistence and continuity
|
||||
- Comprehensive session lifecycle management
|
||||
- Advanced error handling and recovery capabilities
|
||||
|
||||
## Serena MCP Integration Requirements
|
||||
|
||||
### Mandatory Tools
|
||||
All session commands must integrate with these Serena MCP tools:
|
||||
- **Memory Management**: read_memory, write_memory, list_memories, delete_memory
|
||||
- **Project Management**: activate_project, get_current_config
|
||||
- **Reflection System**: think_about_* tools for session analysis and validation
|
||||
- **State Management**: Session state persistence and restoration capabilities
|
||||
|
||||
### Integration Patterns
|
||||
- **Memory-First Approach**: All operations should leverage Serena memory system
|
||||
- **Performance Validation**: Continuous monitoring against strict performance targets
|
||||
- **Context Preservation**: Maintaining rich context across session boundaries
|
||||
- **Error Recovery**: Robust recovery mechanisms for session-critical failures
|
||||
|
||||
## Performance Validation Requirements
|
||||
|
||||
### Critical Performance Targets
|
||||
Session commands must meet these non-negotiable performance requirements:
|
||||
- Session initialization: <500ms for complete setup
|
||||
- Core operations: <200ms for memory and basic operations
|
||||
- Checkpoint creation: <1s for comprehensive checkpoints
|
||||
- Memory operations: <200ms per individual operation
|
||||
|
||||
### Performance Monitoring
|
||||
- Real-time performance tracking and validation
|
||||
- Automated performance regression detection
|
||||
- Detailed performance analytics and reporting
|
||||
- Resource optimization and efficiency recommendations
|
||||
|
||||
## Quality Standards
|
||||
|
||||
### Session Command Requirements
|
||||
- [ ] Mandatory Serena MCP integration is properly implemented
|
||||
- [ ] All performance targets are realistic and consistently achievable
|
||||
- [ ] Cross-session context persistence works reliably
|
||||
- [ ] Error handling covers all session-critical failure scenarios
|
||||
- [ ] Memory organization follows established patterns
|
||||
- [ ] Session lifecycle integration is comprehensive
|
||||
- [ ] Performance monitoring and analytics are functional
|
||||
|
||||
---
|
||||
|
||||
*This template is specifically designed for session management commands that provide critical session lifecycle capabilities with mandatory Serena MCP integration and strict performance requirements.*
|
||||
@@ -1,280 +0,0 @@
|
||||
---
|
||||
name: [command-name]
|
||||
description: "[Specialized command for unique system operations with custom integration patterns]"
|
||||
allowed-tools: [Read, Write, Edit, Grep, Glob, Bash, TodoWrite]
|
||||
|
||||
# Command Classification
|
||||
category: special
|
||||
complexity: [medium|high]
|
||||
scope: [system|meta]
|
||||
|
||||
# Integration Configuration
|
||||
mcp-integration:
|
||||
servers: [] # Specify required MCP servers if any
|
||||
personas: [] # Specify required personas if any
|
||||
wave-enabled: false
|
||||
complexity-threshold: 0.6
|
||||
|
||||
# Performance Profile
|
||||
performance-profile: specialized
|
||||
---
|
||||
|
||||
# /sc:[command-name] - [Special Command Title]
|
||||
|
||||
## Purpose
|
||||
[Clear statement of this command's unique role in the SuperClaude ecosystem. Explain the specialized functionality that doesn't fit standard command patterns and why this custom approach is necessary.]
|
||||
|
||||
## Usage
|
||||
```
|
||||
/sc:[command-name] [specialized-args] [--custom-flag1] [--custom-flag2]
|
||||
```
|
||||
|
||||
## Arguments
|
||||
- `specialized-arg` - [Description of command-specific argument unique to this operation]
|
||||
- `--custom-flag1` - [Command-specific flag with specialized behavior]
|
||||
- `--custom-flag2` - [Another specialized flag unique to this command]
|
||||
- `--validate` - [Optional validation for complex specialized operations]
|
||||
- `--dry-run` - [Preview mode for specialized operations with system impact]
|
||||
|
||||
## Specialized Execution Flow
|
||||
|
||||
### 1. Unique Analysis Phase
|
||||
- [Command-specific analysis unique to this operation]
|
||||
- [Specialized context evaluation and requirement assessment]
|
||||
- [Custom validation and prerequisite checking]
|
||||
|
||||
### 2. Specialized Processing
|
||||
- [Core specialized functionality that defines this command]
|
||||
- [Custom algorithms, logic, or system interactions]
|
||||
- [Unique data processing or transformation operations]
|
||||
|
||||
### 3. Custom Integration
|
||||
- [Specialized integration with SuperClaude framework components]
|
||||
- [Custom MCP server coordination if required]
|
||||
- [Unique persona activation patterns if applicable]
|
||||
|
||||
### 4. Specialized Validation
|
||||
- [Command-specific validation and quality assurance]
|
||||
- [Custom success criteria and outcome verification]
|
||||
- [Specialized error detection and handling]
|
||||
|
||||
### 5. Custom Output Generation
|
||||
- [Specialized output format or system changes]
|
||||
- [Custom reporting or system state modifications]
|
||||
- [Unique integration with downstream systems]
|
||||
|
||||
## Custom Architecture Features
|
||||
|
||||
### Specialized System Integration
|
||||
- **[Custom Integration Point 1]**: [Description of unique system integration]
|
||||
- **[Custom Integration Point 2]**: [Description of specialized framework integration]
|
||||
- **[Custom Integration Point 3]**: [Description of unique coordination patterns]
|
||||
|
||||
### Unique Processing Capabilities
|
||||
- **[Specialized Capability 1]**: [Description of unique processing capability]
|
||||
- **[Specialized Capability 2]**: [Description of custom analysis or transformation]
|
||||
- **[Specialized Capability 3]**: [Description of specialized system interaction]
|
||||
|
||||
### Custom Performance Characteristics
|
||||
- **[Performance Aspect 1]**: [Specialized performance requirements or optimizations]
|
||||
- **[Performance Aspect 2]**: [Custom resource management or efficiency considerations]
|
||||
- **[Performance Aspect 3]**: [Unique scalability or resource utilization patterns]
|
||||
|
||||
## Advanced Specialized Features
|
||||
|
||||
### [Custom Feature Category 1]
|
||||
- **[Specialized Feature 1]**: [Description of unique capability]
|
||||
- **[Specialized Feature 2]**: [Description of custom functionality]
|
||||
- **[Specialized Feature 3]**: [Description of specialized behavior]
|
||||
|
||||
### [Custom Feature Category 2]
|
||||
- **[Advanced Capability 1]**: [Description of sophisticated specialized feature]
|
||||
- **[Advanced Capability 2]**: [Description of complex custom integration]
|
||||
- **[Advanced Capability 3]**: [Description of unique system coordination]
|
||||
|
||||
### [Custom Feature Category 3]
|
||||
- **[Meta-System Feature 1]**: [Description of system-level specialized capability]
|
||||
- **[Meta-System Feature 2]**: [Description of framework-level custom integration]
|
||||
- **[Meta-System Feature 3]**: [Description of ecosystem-level specialized behavior]
|
||||
|
||||
## Specialized Tool Coordination
|
||||
|
||||
### Custom Tool Integration
|
||||
- **[Tool Category 1]**: [How this command uses tools in specialized ways]
|
||||
- **[Tool Category 2]**: [Custom tool coordination patterns]
|
||||
- **[Tool Category 3]**: [Specialized tool sequencing or orchestration]
|
||||
|
||||
### Unique Tool Patterns
|
||||
- **[Pattern 1]**: [Description of custom tool usage pattern]
|
||||
- **[Pattern 2]**: [Description of specialized tool coordination]
|
||||
- **[Pattern 3]**: [Description of unique tool integration approach]
|
||||
|
||||
### Tool Performance Optimization
|
||||
- **[Optimization 1]**: [Specialized tool performance optimization]
|
||||
- **[Optimization 2]**: [Custom resource management for tool usage]
|
||||
- **[Optimization 3]**: [Unique efficiency patterns for specialized operations]
|
||||
|
||||
## Custom Error Handling
|
||||
|
||||
### Specialized Error Categories
|
||||
- **[Error Type 1]**: [Command-specific error category and handling approach]
|
||||
- **[Error Type 2]**: [Specialized failure mode and recovery strategy]
|
||||
- **[Error Type 3]**: [Unique error condition and mitigation approach]
|
||||
|
||||
### Custom Recovery Strategies
|
||||
- **[Recovery Strategy 1]**: [Specialized recovery approach for unique failures]
|
||||
- **[Recovery Strategy 2]**: [Custom error mitigation and system restoration]
|
||||
- **[Recovery Strategy 3]**: [Unique failure handling and graceful degradation]
|
||||
|
||||
### Error Prevention
|
||||
- **[Prevention Method 1]**: [Proactive error prevention for specialized operations]
|
||||
- **[Prevention Method 2]**: [Custom validation to prevent specialized failures]
|
||||
- **[Prevention Method 3]**: [Unique safeguards for specialized system interactions]
|
||||
|
||||
## Integration Patterns
|
||||
|
||||
### SuperClaude Framework Integration
|
||||
- **[Framework Integration 1]**: [How this command integrates with SuperClaude ecosystem]
|
||||
- **[Framework Integration 2]**: [Specialized coordination with other components]
|
||||
- **[Framework Integration 3]**: [Unique contribution to framework capabilities]
|
||||
|
||||
### Custom MCP Integration (if applicable)
|
||||
- **[MCP Integration 1]**: [Specialized MCP server coordination]
|
||||
- **[MCP Integration 2]**: [Custom MCP server usage patterns]
|
||||
- **[MCP Integration 3]**: [Unique MCP server integration approach]
|
||||
|
||||
### Specialized System Coordination
|
||||
- **[System Coordination 1]**: [Custom system-level integration]
|
||||
- **[System Coordination 2]**: [Specialized external system coordination]
|
||||
- **[System Coordination 3]**: [Unique system state management]
|
||||
|
||||
## Performance & Scalability
|
||||
|
||||
### Specialized Performance Requirements
|
||||
- **[Performance Requirement 1]**: [Custom performance target specific to this command]
|
||||
- **[Performance Requirement 2]**: [Specialized efficiency requirement]
|
||||
- **[Performance Requirement 3]**: [Unique scalability consideration]
|
||||
|
||||
### Custom Resource Management
|
||||
- **[Resource Management 1]**: [Specialized resource allocation and management]
|
||||
- **[Resource Management 2]**: [Custom resource optimization approach]
|
||||
- **[Resource Management 3]**: [Unique resource utilization pattern]
|
||||
|
||||
### Scalability Characteristics
|
||||
- **[Scalability Aspect 1]**: [How the command scales with specialized workloads]
|
||||
- **[Scalability Aspect 2]**: [Custom scaling patterns and limitations]
|
||||
- **[Scalability Aspect 3]**: [Unique scalability optimization approaches]
|
||||
|
||||
## Examples
|
||||
|
||||
### Basic Specialized Operation
|
||||
```
|
||||
/sc:[command-name] [basic-specialized-example]
|
||||
# Description of expected specialized outcome
|
||||
```
|
||||
|
||||
### Advanced Specialized Usage
|
||||
```
|
||||
/sc:[command-name] [complex-example] --custom-flag1 --validate
|
||||
# Description of advanced specialized behavior
|
||||
```
|
||||
|
||||
### System-Level Operation
|
||||
```
|
||||
/sc:[command-name] [system-example] --custom-flag2 --dry-run
|
||||
# Description of system-level specialized operation
|
||||
```
|
||||
|
||||
### Meta-Operation Example
|
||||
```
|
||||
/sc:[command-name] [meta-example] --all-flags --comprehensive
|
||||
# Description of comprehensive specialized operation
|
||||
```
|
||||
|
||||
## Quality Standards
|
||||
|
||||
### Specialized Validation Criteria
|
||||
- **[Validation Criterion 1]**: [Custom validation specific to specialized functionality]
|
||||
- **[Validation Criterion 2]**: [Specialized quality assurance requirement]
|
||||
- **[Validation Criterion 3]**: [Unique success criteria for specialized operations]
|
||||
|
||||
### Custom Success Metrics
|
||||
- **[Success Metric 1]**: [Specialized metric for measuring command effectiveness]
|
||||
- **[Success Metric 2]**: [Custom performance indicator]
|
||||
- **[Success Metric 3]**: [Unique quality measurement approach]
|
||||
|
||||
### Specialized Compliance Requirements
|
||||
- **[Compliance Requirement 1]**: [Command-specific compliance or standard]
|
||||
- **[Compliance Requirement 2]**: [Specialized regulatory or policy requirement]
|
||||
- **[Compliance Requirement 3]**: [Unique framework compliance consideration]
|
||||
|
||||
## Boundaries
|
||||
|
||||
**This specialized command will:**
|
||||
- [Specialized capability 1 unique to this command]
|
||||
- [Specialized capability 2 that defines this command's purpose]
|
||||
- [Specialized capability 3 that integrates with SuperClaude ecosystem]
|
||||
- [Specialized capability 4 that provides unique value]
|
||||
|
||||
**This specialized command will not:**
|
||||
- [Specialized limitation 1 related to command boundaries]
|
||||
- [Specialized limitation 2 defining scope restrictions]
|
||||
- [Specialized limitation 3 related to system safety]
|
||||
- [Specialized limitation 4 defining integration boundaries]
|
||||
|
||||
---
|
||||
|
||||
# Template Usage Guidelines
|
||||
|
||||
## Implementation Approach
|
||||
This template is designed for commands that require:
|
||||
- Unique functionality that doesn't fit standard command patterns
|
||||
- Specialized system interactions or meta-operations
|
||||
- Custom integration patterns with SuperClaude framework
|
||||
- Advanced error handling for specialized failure modes
|
||||
- Custom performance characteristics or resource management
|
||||
|
||||
## Specialization Guidelines
|
||||
|
||||
### When to Use Special Template
|
||||
- Command provides functionality not covered by other templates
|
||||
- Requires custom integration patterns with framework components
|
||||
- Needs specialized error handling or recovery mechanisms
|
||||
- Has unique performance characteristics or resource requirements
|
||||
- Provides meta-operations or system-level functionality
|
||||
|
||||
### Customization Requirements
|
||||
- Define specialized arguments and flags unique to the command
|
||||
- Implement custom execution flow that matches specialized functionality
|
||||
- Create specialized error handling for unique failure modes
|
||||
- Design custom integration patterns with SuperClaude ecosystem
|
||||
- Establish specialized performance targets and validation criteria
|
||||
|
||||
## Development Guidelines
|
||||
|
||||
### Architecture Considerations
|
||||
- Ensure specialized functionality integrates cleanly with SuperClaude framework
|
||||
- Design custom error handling that maintains system stability
|
||||
- Implement specialized performance monitoring for unique operations
|
||||
- Create custom validation patterns for specialized functionality
|
||||
- Design specialized documentation that explains unique capabilities
|
||||
|
||||
### Quality Assurance
|
||||
- Validate specialized functionality meets unique requirements
|
||||
- Test custom error handling and recovery mechanisms
|
||||
- Verify specialized performance characteristics
|
||||
- Ensure custom integration patterns work correctly
|
||||
- Validate specialized boundaries and limitations
|
||||
|
||||
## Quality Checklist
|
||||
- [ ] Specialized functionality is clearly defined and documented
|
||||
- [ ] Custom integration patterns are properly implemented
|
||||
- [ ] Specialized error handling covers all unique failure modes
|
||||
- [ ] Custom performance requirements are realistic and measurable
|
||||
- [ ] Specialized validation criteria are comprehensive
|
||||
- [ ] Custom boundaries and limitations are clearly defined
|
||||
- [ ] Specialized examples demonstrate real-world usage patterns
|
||||
|
||||
---
|
||||
|
||||
*This template is reserved for specialized commands that provide unique functionality not covered by standard command patterns. Each special command should be carefully designed to integrate cleanly with the SuperClaude framework while providing distinctive specialized capabilities.*
|
||||
@@ -1,265 +0,0 @@
|
||||
---
|
||||
name: [command-name]
|
||||
description: "[Clear description for help systems and auto-activation patterns with workflow context]"
|
||||
allowed-tools: [Read, Write, Edit, MultiEdit, Bash, Grep, Glob, TodoWrite, Task]
|
||||
|
||||
# Command Classification
|
||||
category: workflow
|
||||
complexity: standard
|
||||
scope: [project|cross-file]
|
||||
|
||||
# Integration Configuration
|
||||
mcp-integration:
|
||||
servers: [context7, sequential] # Optional MCP servers for enhanced capabilities
|
||||
personas: [architect, frontend, backend, security] # Auto-activated based on context
|
||||
wave-enabled: false
|
||||
complexity-threshold: 0.5
|
||||
|
||||
# Performance Profile
|
||||
performance-profile: standard
|
||||
---
|
||||
|
||||
# /sc:[command-name] - [Command Title]
|
||||
|
||||
## Purpose
|
||||
[Clear statement of what this command does in the context of development workflows. Explain how it fits into typical development processes and when it provides the most value.]
|
||||
|
||||
## Usage
|
||||
```
|
||||
/sc:[command-name] [target] [--type option1|option2|option3] [--safe] [--interactive]
|
||||
```
|
||||
|
||||
## Arguments
|
||||
- `target` - [Description of the target: files, directories, or project scope]
|
||||
- `--type` - [Workflow type or approach selection]
|
||||
- `--safe` - [Conservative approach with minimal risk]
|
||||
- `--interactive` - [Enable user interaction for complex decisions]
|
||||
- `--preview` - [Show changes without applying them]
|
||||
- `--validate` - [Enable additional validation steps]
|
||||
|
||||
## Execution Flow
|
||||
|
||||
### 1. Context Analysis
|
||||
- Analyze target scope and detect relevant technologies
|
||||
- Identify project patterns and existing conventions
|
||||
- Assess complexity and potential impact of operation
|
||||
|
||||
### 2. Strategy Selection
|
||||
- Choose appropriate approach based on --type and context
|
||||
- Auto-activate relevant personas for domain expertise
|
||||
- Configure MCP servers for enhanced capabilities
|
||||
|
||||
### 3. Core Operation
|
||||
- Execute primary workflow with appropriate validation
|
||||
- Apply domain-specific best practices and patterns
|
||||
- Monitor progress and handle edge cases
|
||||
|
||||
### 4. Quality Assurance
|
||||
- Validate results against requirements and standards
|
||||
- Run automated checks and testing where applicable
|
||||
- Generate comprehensive feedback and recommendations
|
||||
|
||||
### 5. Integration & Handoff
|
||||
- Update related documentation and configuration
|
||||
- Prepare for follow-up commands or next steps
|
||||
- Persist relevant context for future operations
|
||||
|
||||
## MCP Server Integration
|
||||
|
||||
### Context7 Integration
|
||||
- **Automatic Activation**: [When Context7 enhances command capabilities]
|
||||
- **Library Patterns**: [How the command leverages framework documentation]
|
||||
- **Best Practices**: [Integration with established patterns and conventions]
|
||||
|
||||
### Sequential Thinking Integration
|
||||
- **Complex Analysis**: [When Sequential thinking provides systematic analysis]
|
||||
- **Multi-Step Planning**: [How Sequential breaks down complex operations]
|
||||
- **Validation Logic**: [Use of Sequential for verification and quality checks]
|
||||
|
||||
## Persona Auto-Activation
|
||||
|
||||
### Context-Based Activation
|
||||
The command automatically activates relevant personas based on detected context:
|
||||
|
||||
- **Architect Persona**: [When architectural decisions or system design are involved]
|
||||
- **Frontend Persona**: [For UI/UX related operations and client-side concerns]
|
||||
- **Backend Persona**: [For server-side logic, APIs, and data operations]
|
||||
- **Security Persona**: [When security considerations are paramount]
|
||||
|
||||
### Multi-Persona Coordination
|
||||
- **Collaborative Analysis**: [How multiple personas work together]
|
||||
- **Expertise Integration**: [Combining domain-specific knowledge]
|
||||
- **Conflict Resolution**: [Handling different persona recommendations]
|
||||
|
||||
## Advanced Features
|
||||
|
||||
### Task Integration
|
||||
- **Complex Operations**: Use Task tool for multi-step workflows
|
||||
- **Parallel Processing**: Coordinate independent work streams
|
||||
- **Progress Tracking**: TodoWrite integration for status management
|
||||
|
||||
### Workflow Orchestration
|
||||
- **Dependency Management**: Handle prerequisites and sequencing
|
||||
- **Error Recovery**: Graceful handling of failures and rollbacks
|
||||
- **State Management**: Maintain operation state across interruptions
|
||||
|
||||
### Quality Gates
|
||||
- **Pre-validation**: Check requirements before execution
|
||||
- **Progress Validation**: Intermediate quality checks
|
||||
- **Post-validation**: Comprehensive results verification
|
||||
|
||||
## Performance Optimization
|
||||
|
||||
### Efficiency Features
|
||||
- **Intelligent Batching**: Group related operations for efficiency
|
||||
- **Context Caching**: Reuse analysis results within session
|
||||
- **Parallel Execution**: Independent operations run concurrently
|
||||
- **Resource Management**: Optimal tool and server utilization
|
||||
|
||||
### Performance Targets
|
||||
- **Analysis Phase**: <10s for project-level analysis
|
||||
- **Execution Phase**: <30s for standard operations
|
||||
- **Validation Phase**: <5s for quality checks
|
||||
- **Overall Command**: <60s for complex workflows
|
||||
|
||||
## Examples
|
||||
|
||||
### Basic Workflow
|
||||
```
|
||||
/sc:[command-name] src/components --type standard
|
||||
# Standard workflow with automatic persona activation
|
||||
```
|
||||
|
||||
### Safe Mode Operation
|
||||
```
|
||||
/sc:[command-name] entire-project --safe --preview
|
||||
# Conservative approach with preview of changes
|
||||
```
|
||||
|
||||
### Interactive Complex Operation
|
||||
```
|
||||
/sc:[command-name] src --interactive --validate --type advanced
|
||||
# Interactive mode with enhanced validation
|
||||
```
|
||||
|
||||
### Framework-Specific Operation
|
||||
```
|
||||
/sc:[command-name] frontend-app --type react --c7
|
||||
# Leverage Context7 for React-specific patterns
|
||||
```
|
||||
|
||||
## Error Handling & Recovery
|
||||
|
||||
### Graceful Degradation
|
||||
- **MCP Server Unavailable**: [Fallback behavior when servers are offline]
|
||||
- **Persona Activation Failure**: [Default behavior without persona enhancement]
|
||||
- **Tool Access Issues**: [Alternative approaches when tools are unavailable]
|
||||
|
||||
### Error Categories
|
||||
- **Input Validation Errors**: [Clear feedback for invalid inputs]
|
||||
- **Process Execution Errors**: [Handling of runtime failures]
|
||||
- **Integration Errors**: [MCP server or persona coordination issues]
|
||||
- **Resource Constraint Errors**: [Behavior under resource limitations]
|
||||
|
||||
### Recovery Strategies
|
||||
- **Automatic Retry**: [When and how automatic retry is attempted]
|
||||
- **User Intervention**: [When user input is required for recovery]
|
||||
- **Partial Success Handling**: [Managing partially completed operations]
|
||||
- **State Cleanup**: [Ensuring clean state after failures]
|
||||
|
||||
## Integration Patterns
|
||||
|
||||
### Command Coordination
|
||||
- **Preparation Commands**: [Commands typically run before this one]
|
||||
- **Follow-up Commands**: [Commands that commonly follow this one]
|
||||
- **Parallel Commands**: [Commands that can run simultaneously]
|
||||
|
||||
### Framework Integration
|
||||
- **SuperClaude Ecosystem**: [How this fits into the broader framework]
|
||||
- **Quality Gates**: [Integration with validation cycles]
|
||||
- **Session Management**: [Interaction with session lifecycle]
|
||||
|
||||
### Tool Coordination
|
||||
- **Multi-Tool Operations**: [How different tools work together]
|
||||
- **Tool Selection Logic**: [Dynamic tool selection based on context]
|
||||
- **Resource Sharing**: [Efficient use of shared resources]
|
||||
|
||||
## Customization & Configuration
|
||||
|
||||
### Configuration Options
|
||||
- **Default Behavior**: [Standard operation mode]
|
||||
- **User Preferences**: [How user preferences affect behavior]
|
||||
- **Project-Specific Settings**: [Project-level customization]
|
||||
|
||||
### Extension Points
|
||||
- **Custom Workflows**: [How to extend with custom logic]
|
||||
- **Plugin Integration**: [Integration with external tools]
|
||||
- **Hook Points**: [Where custom logic can be inserted]
|
||||
|
||||
## Quality Standards
|
||||
|
||||
### Validation Criteria
|
||||
- **Functional Correctness**: [Ensuring the command achieves its purpose]
|
||||
- **Performance Standards**: [Meeting performance targets]
|
||||
- **Integration Compliance**: [Proper integration with ecosystem]
|
||||
- **Error Handling Quality**: [Comprehensive error management]
|
||||
|
||||
### Success Metrics
|
||||
- **Completion Rate**: >95% for well-formed inputs
|
||||
- **Performance Targets**: Meeting specified timing requirements
|
||||
- **User Satisfaction**: Clear feedback and expected outcomes
|
||||
- **Integration Success**: Proper coordination with other components
|
||||
|
||||
## Boundaries
|
||||
|
||||
**This command will:**
|
||||
- [Primary capability with workflow integration]
|
||||
- [Secondary capability with persona support]
|
||||
- [Quality assurance and validation capability]
|
||||
- [Integration and handoff capability]
|
||||
|
||||
**This command will not:**
|
||||
- [Limitation related to scope boundaries]
|
||||
- [Limitation related to complexity boundaries]
|
||||
- [Limitation related to safety boundaries]
|
||||
- [Limitation related to tool boundaries]
|
||||
|
||||
---
|
||||
|
||||
# Template Usage Guidelines
|
||||
|
||||
## Implementation Steps
|
||||
1. **Copy Template**: Use this for workflow commands requiring moderate complexity
|
||||
2. **Configure Integration**: Set up MCP servers and persona activation patterns
|
||||
3. **Define Workflows**: Specify the main execution flow and edge cases
|
||||
4. **Test Integration**: Validate MCP server coordination and persona activation
|
||||
5. **Performance Validation**: Ensure the command meets performance targets
|
||||
|
||||
## MCP Integration Guidelines
|
||||
|
||||
### Context7 Integration
|
||||
- Use for framework-specific patterns and best practices
|
||||
- Leverage library documentation and example patterns
|
||||
- Enable automatic activation for technology-specific contexts
|
||||
|
||||
### Sequential Integration
|
||||
- Apply for complex multi-step analysis and planning
|
||||
- Use for systematic validation and quality checking
|
||||
- Enable for operations requiring structured reasoning
|
||||
|
||||
### Persona Coordination
|
||||
- Define clear activation criteria for each persona
|
||||
- Handle multi-persona scenarios with coordination logic
|
||||
- Provide fallback behavior when personas are unavailable
|
||||
|
||||
## Quality Checklist
|
||||
- [ ] All MCP integration points are documented
|
||||
- [ ] Persona activation logic is clearly defined
|
||||
- [ ] Performance targets are realistic and measurable
|
||||
- [ ] Error handling covers all integration failure modes
|
||||
- [ ] Tool coordination is efficient and resource-aware
|
||||
- [ ] Examples demonstrate real-world usage patterns
|
||||
|
||||
---
|
||||
|
||||
*This template is designed for standard workflow commands that benefit from MCP integration and persona activation while maintaining moderate complexity. Use higher-tier templates for advanced orchestration or session management needs.*
|
||||
@@ -1,293 +0,0 @@
|
||||
# [Flag Name] Flag
|
||||
|
||||
**`--[flag-name]` / `--[alias]`** *(if applicable)*
|
||||
|
||||
## Metadata
|
||||
```yaml
|
||||
name: --[flag-name]
|
||||
aliases: [--[alias1], --[alias2]] # Optional
|
||||
category: [Planning|Efficiency|MCP Control|Delegation|Scope|Focus|Iteration|Introspection]
|
||||
priority: [1-10] # Higher number = higher precedence
|
||||
token_impact: [low|medium|high|variable]
|
||||
```
|
||||
|
||||
## Purpose
|
||||
[One-line description of what this flag does and when to use it]
|
||||
|
||||
## Behavior
|
||||
[Detailed explanation of flag behavior in 2-3 sentences. Include what happens when the flag is active, any side effects, and performance implications.]
|
||||
|
||||
## Auto-Activation Rules
|
||||
|
||||
**Conditions**:
|
||||
- [Condition 1 that triggers auto-activation]
|
||||
- [Condition 2 that triggers auto-activation]
|
||||
- [Threshold or metric if applicable]
|
||||
|
||||
**Detection Patterns**:
|
||||
- Keywords: `[keyword1]`, `[keyword2]`, `[keyword3]`
|
||||
- File patterns: `[pattern1]`, `[pattern2]`
|
||||
- Complexity indicators: [describe complexity metrics]
|
||||
- Resource thresholds: [describe resource conditions]
|
||||
|
||||
**Precedence**: [Describe any special precedence rules]
|
||||
|
||||
## Token Impact
|
||||
- **Base Usage**: [Estimated token usage]
|
||||
- **Scaling Factor**: [How usage scales with project size]
|
||||
- **Optimization**: [Any token-saving features when active]
|
||||
|
||||
## Conflicts & Resolution
|
||||
|
||||
**Incompatible With**:
|
||||
- `--[flag1]`: [Reason for incompatibility]
|
||||
- `--[flag2]`: [Reason for incompatibility]
|
||||
|
||||
**Resolution Strategy**:
|
||||
1. [Step 1 for conflict resolution]
|
||||
2. [Step 2 for conflict resolution]
|
||||
|
||||
**Overrides**:
|
||||
- Overridden by: `--[higher-priority-flag]`
|
||||
- Overrides: `--[lower-priority-flag]`
|
||||
|
||||
## Integration Points
|
||||
|
||||
### Compatible Commands
|
||||
- `/sc:[command1]` - [How the flag enhances this command]
|
||||
- `/sc:[command2]` - [How the flag enhances this command]
|
||||
- `/sc:[command3]` - [How the flag enhances this command]
|
||||
|
||||
### MCP Servers
|
||||
- **[Server Name]**: [How this flag interacts with the server]
|
||||
- **[Server Name]**: [How this flag interacts with the server]
|
||||
|
||||
### Synergistic Flags
|
||||
- `--[flag1]`: [How they work together]
|
||||
- `--[flag2]`: [How they work together]
|
||||
|
||||
## Usage Examples
|
||||
|
||||
### Basic Usage
|
||||
```bash
|
||||
claude "your request here" --[flag-name]
|
||||
```
|
||||
|
||||
### With Parameters *(if applicable)*
|
||||
```bash
|
||||
claude "your request here" --[flag-name] [parameter]
|
||||
```
|
||||
|
||||
### Combined with Other Flags
|
||||
```bash
|
||||
claude "your request here" --[flag-name] --[other-flag]
|
||||
```
|
||||
|
||||
### Real-World Scenario
|
||||
```bash
|
||||
# [Describe a real use case]
|
||||
claude "[specific request example]" --[flag-name]
|
||||
```
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
**Performance Considerations**:
|
||||
- [Note about performance impact]
|
||||
- [Resource usage patterns]
|
||||
|
||||
**Best Practices**:
|
||||
- [When to use this flag]
|
||||
- [When NOT to use this flag]
|
||||
- [Common pitfalls to avoid]
|
||||
|
||||
---
|
||||
|
||||
# Flag Template Usage Guide
|
||||
|
||||
## Overview
|
||||
This template provides a standardized format for documenting flags in the SuperClaude framework. Each flag should have its own section in FLAGS.md following this structure.
|
||||
|
||||
## Creating a New Flag
|
||||
|
||||
### 1. Choose Appropriate Naming
|
||||
- Use lowercase with hyphens: `--flag-name`
|
||||
- Be descriptive but concise
|
||||
- Consider aliases for common variations
|
||||
- Examples: `--think-hard`, `--safe-mode`, `--wave-mode`
|
||||
|
||||
### 2. Select Category
|
||||
Choose from these standard categories:
|
||||
- **Planning & Analysis**: Thinking modes, analysis depth
|
||||
- **Compression & Efficiency**: Token optimization, output control
|
||||
- **MCP Control**: Server activation/deactivation
|
||||
- **Delegation**: Sub-agent and task distribution
|
||||
- **Scope & Focus**: Operation boundaries and domains
|
||||
- **Iteration**: Loop and refinement controls
|
||||
- **Wave Orchestration**: Multi-stage execution
|
||||
- **Introspection**: Transparency and debugging
|
||||
|
||||
### 3. Set Priority (1-10)
|
||||
Priority determines precedence in conflicts:
|
||||
- **10**: Safety flags (--safe-mode)
|
||||
- **8-9**: Explicit user flags
|
||||
- **6-7**: Performance and efficiency flags
|
||||
- **4-5**: Feature flags
|
||||
- **1-3**: Convenience flags
|
||||
|
||||
### 4. Define Auto-Activation
|
||||
Specify clear, measurable conditions:
|
||||
- **Threshold-based**: "complexity > 0.7"
|
||||
- **Count-based**: "files > 50"
|
||||
- **Pattern-based**: "import statements detected"
|
||||
- **Composite**: "complexity > 0.8 AND domains > 2"
|
||||
|
||||
### 5. Document Token Impact
|
||||
Classify token usage:
|
||||
- **Low**: <1K additional tokens
|
||||
- **Medium**: 1K-10K additional tokens
|
||||
- **High**: 10K+ additional tokens
|
||||
- **Variable**: Depends on operation scope
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Do's
|
||||
✅ Provide clear auto-activation conditions
|
||||
✅ Document all conflicts explicitly
|
||||
✅ Include real-world usage examples
|
||||
✅ Specify token impact estimates
|
||||
✅ List integration points comprehensively
|
||||
✅ Test flag interactions thoroughly
|
||||
|
||||
### Don'ts
|
||||
❌ Create overlapping flags without clear differentiation
|
||||
❌ Use vague auto-activation conditions
|
||||
❌ Ignore precedence rules
|
||||
❌ Forget to update integration sections
|
||||
❌ Skip conflict resolution documentation
|
||||
|
||||
## Testing Your Flag
|
||||
|
||||
### 1. Manual Testing
|
||||
```bash
|
||||
# Test basic functionality
|
||||
claude "test request" --your-flag
|
||||
|
||||
# Test with parameters
|
||||
claude "test request" --your-flag parameter
|
||||
|
||||
# Test combinations
|
||||
claude "test request" --your-flag --other-flag
|
||||
```
|
||||
|
||||
### 2. Auto-Activation Testing
|
||||
- Create scenarios that should trigger activation
|
||||
- Verify activation occurs at correct thresholds
|
||||
- Ensure no false positives
|
||||
|
||||
### 3. Conflict Testing
|
||||
- Test with known incompatible flags
|
||||
- Verify resolution strategy works
|
||||
- Check precedence ordering
|
||||
|
||||
### 4. Integration Testing
|
||||
- Test with relevant commands
|
||||
- Verify MCP server interactions
|
||||
- Check synergistic flag combinations
|
||||
|
||||
## Common Flag Patterns
|
||||
|
||||
### Analysis Flags
|
||||
```yaml
|
||||
category: Planning & Analysis
|
||||
auto_activation: complexity-based
|
||||
token_impact: high
|
||||
integrates_with: Sequential MCP
|
||||
```
|
||||
|
||||
### Control Flags
|
||||
```yaml
|
||||
category: MCP Control
|
||||
auto_activation: context-based
|
||||
token_impact: variable
|
||||
conflicts_with: opposite controls
|
||||
```
|
||||
|
||||
### Performance Flags
|
||||
```yaml
|
||||
category: Efficiency
|
||||
auto_activation: resource-based
|
||||
token_impact: reduces overall
|
||||
integrates_with: all operations
|
||||
```
|
||||
|
||||
### Safety Flags
|
||||
```yaml
|
||||
category: Safety
|
||||
priority: 10
|
||||
auto_activation: risk-based
|
||||
overrides: most other flags
|
||||
```
|
||||
|
||||
## Flag Categories Reference
|
||||
|
||||
| Category | Purpose | Common Patterns |
|
||||
|----------|---------|-----------------|
|
||||
| Planning & Analysis | Deep thinking modes | --think, --analyze |
|
||||
| Efficiency | Token optimization | --uc, --compress |
|
||||
| MCP Control | Server management | --seq, --no-mcp |
|
||||
| Delegation | Task distribution | --delegate, --concurrency |
|
||||
| Scope | Operation boundaries | --scope, --focus |
|
||||
| Iteration | Refinement loops | --loop, --iterations |
|
||||
| Wave | Multi-stage execution | --wave-mode, --wave-strategy |
|
||||
| Introspection | Debugging/transparency | --introspect, --debug |
|
||||
|
||||
## Integration with FLAGS.md
|
||||
|
||||
When adding a new flag to FLAGS.md:
|
||||
|
||||
1. **Find the appropriate section** based on category
|
||||
2. **Maintain alphabetical order** within sections
|
||||
3. **Update the Flag System Architecture** if introducing new concepts
|
||||
4. **Add to Integration Patterns** section if relevant
|
||||
5. **Update any affected precedence rules**
|
||||
|
||||
## Version Compatibility
|
||||
|
||||
- Document which version introduced the flag
|
||||
- Note any breaking changes in behavior
|
||||
- Specify minimum Claude Code version required
|
||||
- List deprecated flags this replaces (if any)
|
||||
|
||||
## Examples of Well-Documented Flags
|
||||
|
||||
### Example 1: Thinking Flag
|
||||
```markdown
|
||||
**`--think`**
|
||||
- Multi-file analysis (~4K tokens)
|
||||
- Enables Sequential MCP for structured problem-solving
|
||||
- Auto-activates: Import chains >5 files, cross-module calls >10 references
|
||||
- Auto-enables `--seq` for systematic analysis
|
||||
```
|
||||
|
||||
### Example 2: Delegation Flag
|
||||
```markdown
|
||||
**`--delegate [files|folders|auto]`**
|
||||
- Enable Task tool sub-agent delegation for parallel processing
|
||||
- **files**: Delegate individual file analysis to sub-agents
|
||||
- **folders**: Delegate directory-level analysis to sub-agents
|
||||
- **auto**: Auto-detect delegation strategy based on scope and complexity
|
||||
- Auto-activates: >7 directories or >50 files
|
||||
- 40-70% time savings for suitable operations
|
||||
```
|
||||
|
||||
### Example 3: Safety Flag
|
||||
```markdown
|
||||
**`--safe-mode`**
|
||||
- Maximum validation with conservative execution
|
||||
- Auto-activates: Resource usage >85% or production environment
|
||||
- Enables validation checks, forces --uc mode, blocks risky operations
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
This template ensures consistent, comprehensive documentation for all SuperClaude flags, making them easy to understand, implement, and maintain.
|
||||
@@ -1,148 +0,0 @@
|
||||
# [Server Name] MCP Server
|
||||
|
||||
## Purpose
|
||||
[One-line description of what this MCP server provides]
|
||||
|
||||
## Activation Patterns
|
||||
|
||||
**Automatic Activation**:
|
||||
- [Condition 1 that triggers automatic activation]
|
||||
- [Condition 2 that triggers automatic activation]
|
||||
|
||||
**Manual Activation**:
|
||||
- Flag: `--[shorthand]`, `--[fullname]`
|
||||
|
||||
**Smart Detection**:
|
||||
- [Context-aware activation patterns]
|
||||
- [Keywords or patterns that suggest server usage]
|
||||
|
||||
## Workflow Process
|
||||
|
||||
1. **[Step Name]**: [Description of what happens]
|
||||
2. **[Step Name]**: [Description of what happens]
|
||||
3. **[Step Name]**: [Description of what happens]
|
||||
[Continue numbering as needed]
|
||||
|
||||
## Integration Points
|
||||
|
||||
**Commands**: [List of commands that commonly use this server]
|
||||
|
||||
**Thinking Modes**: [How it integrates with --think flags if applicable]
|
||||
|
||||
**Other MCP Servers**: [Which other servers it coordinates with]
|
||||
|
||||
## Core Capabilities
|
||||
|
||||
### [Capability Category 1]
|
||||
- [Specific capability]
|
||||
- [Specific capability]
|
||||
|
||||
### [Capability Category 2]
|
||||
- [Specific capability]
|
||||
- [Specific capability]
|
||||
|
||||
## Use Cases
|
||||
|
||||
- **[Use Case 1]**: [Description]
|
||||
- **[Use Case 2]**: [Description]
|
||||
- **[Use Case 3]**: [Description]
|
||||
|
||||
## Error Recovery
|
||||
|
||||
- **[Error Scenario 1]** → [Recovery Strategy] → [Fallback]
|
||||
- **[Error Scenario 2]** → [Recovery Strategy] → [Fallback]
|
||||
- **[Error Scenario 3]** → [Recovery Strategy] → [Fallback]
|
||||
|
||||
## Caching Strategy
|
||||
|
||||
- **Cache Type**: [What gets cached]
|
||||
- **Cache Duration**: [How long cache persists]
|
||||
- **Cache Key**: [How cache entries are identified]
|
||||
|
||||
## Configuration
|
||||
|
||||
```yaml
|
||||
[server_name]:
|
||||
activation:
|
||||
automatic: [true/false]
|
||||
complexity_threshold: [0.0-1.0]
|
||||
performance:
|
||||
timeout: [milliseconds]
|
||||
max_retries: [number]
|
||||
cache:
|
||||
enabled: [true/false]
|
||||
ttl: [seconds]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# MCP Server Template Guide
|
||||
|
||||
## Overview
|
||||
This template provides a standardized format for documenting MCP (Model Context Protocol) servers in the SuperClaude framework. Each MCP server should have its own file following this structure.
|
||||
|
||||
## Section Guidelines
|
||||
|
||||
### Purpose
|
||||
- Keep it to one clear, concise line
|
||||
- Focus on the primary value the server provides
|
||||
- Example: "Official library documentation, code examples, and best practices"
|
||||
|
||||
### Activation Patterns
|
||||
Document three types of activation:
|
||||
1. **Automatic**: Conditions that trigger without user intervention
|
||||
2. **Manual**: Explicit flags users can specify
|
||||
3. **Smart**: Context-aware patterns Claude Code detects
|
||||
|
||||
### Workflow Process
|
||||
- Number each step sequentially
|
||||
- Use bold formatting for step names
|
||||
- Keep descriptions action-oriented
|
||||
- Include coordination with other servers if applicable
|
||||
|
||||
### Integration Points
|
||||
- List relevant commands without the `/` prefix
|
||||
- Specify which thinking modes apply
|
||||
- Note other MCP servers this one coordinates with
|
||||
|
||||
### Core Capabilities
|
||||
- Group related capabilities under categories
|
||||
- Use bullet points for specific features
|
||||
- Be concrete and specific
|
||||
|
||||
### Use Cases
|
||||
- Provide 3-5 real-world examples
|
||||
- Use bold formatting for use case names
|
||||
- Keep descriptions brief but clear
|
||||
|
||||
### Error Recovery
|
||||
- Format: **Error** → Recovery → Fallback
|
||||
- Include common failure scenarios
|
||||
- Provide actionable recovery strategies
|
||||
|
||||
### Caching Strategy
|
||||
- Specify what gets cached
|
||||
- Include cache duration/TTL
|
||||
- Explain cache key structure
|
||||
|
||||
### Rules
|
||||
- Specify mandatory rules for this server
|
||||
- Use bullet points for clarity
|
||||
- Only simple, actionable rules
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Consistency**: Follow this template structure exactly
|
||||
2. **Clarity**: Write for developers who need quick reference
|
||||
3. **Completeness**: Cover all major functionality
|
||||
4. **Examples**: Use concrete examples where helpful
|
||||
5. **Updates**: Keep documentation synchronized with implementation
|
||||
|
||||
## File Naming
|
||||
- Use prefix: `MCP_ServerName.md`
|
||||
- Match the server's official name with MCP_ prefix
|
||||
- Examples: `MCP_Context7.md`, `MCP_Sequential.md`, `MCP_Magic.md`
|
||||
|
||||
## Location
|
||||
All MCP server documentation files should be placed in:
|
||||
`SuperClaude/MCP/`
|
||||
@@ -1,138 +0,0 @@
|
||||
# [Mode Name] Mode
|
||||
|
||||
**[Optional Subtitle]** - [Brief description of the mode's primary function]
|
||||
|
||||
## Purpose
|
||||
|
||||
[Clear, comprehensive description of what this mode enables and why it exists. Should explain the operational behavior change this mode provides.]
|
||||
|
||||
## Core Capabilities
|
||||
|
||||
### 1. [Capability Category]
|
||||
- **[Specific Feature]**: [Description of what it does]
|
||||
- **[Specific Feature]**: [Description of what it does]
|
||||
- **[Specific Feature]**: [Description of what it does]
|
||||
|
||||
### 2. [Capability Category]
|
||||
- **[Specific Feature]**: [Description of what it does]
|
||||
- **[Specific Feature]**: [Description of what it does]
|
||||
|
||||
[Continue numbering as needed]
|
||||
|
||||
## Activation
|
||||
|
||||
### Manual Activation
|
||||
- **Primary Flag**: `--[shorthand]` or `--[fullname]`
|
||||
- **Context**: [When users would manually activate this]
|
||||
|
||||
### Automatic Activation
|
||||
1. **[Trigger Condition]**: [Description of what triggers activation]
|
||||
2. **[Trigger Condition]**: [Description of what triggers activation]
|
||||
3. **[Trigger Condition]**: [Description of what triggers activation]
|
||||
[Continue as needed]
|
||||
|
||||
## [Mode-Specific Section]
|
||||
|
||||
[This section varies by mode type. Examples:]
|
||||
- For state-based modes: ## States
|
||||
- For communication modes: ## Communication Markers
|
||||
- For optimization modes: ## Techniques
|
||||
- For analysis modes: ## Analysis Types
|
||||
|
||||
## Communication Style
|
||||
|
||||
[How this mode affects interaction with the user]
|
||||
|
||||
### [Subsection if needed]
|
||||
[Details about specific communication patterns]
|
||||
|
||||
## Integration Points
|
||||
|
||||
### Related Flags
|
||||
- **`--[flag]`**: [How it interacts with this mode]
|
||||
- **`--[flag]`**: [How it interacts with this mode]
|
||||
|
||||
### [Other Integration Categories]
|
||||
[Commands, Agents, MCP Servers, Tools, etc.]
|
||||
|
||||
## Configuration
|
||||
|
||||
```yaml
|
||||
[mode_name]:
|
||||
activation:
|
||||
automatic: [true/false]
|
||||
[threshold_name]: [value]
|
||||
[category]:
|
||||
[setting]: [value]
|
||||
[setting]: [value]
|
||||
[category]:
|
||||
[setting]: [value]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Mode Template Guide
|
||||
|
||||
## Overview
|
||||
This template provides a standardized format for documenting Modes in the SuperClaude framework. Modes define HOW Claude operates, as opposed to Agents which define WHO Claude becomes.
|
||||
|
||||
## Key Differences: Modes vs Agents
|
||||
- **Modes**: Operational behaviors, interaction patterns, processing methods
|
||||
- **Agents**: Domain expertise, persona, specialized knowledge
|
||||
- **Example**: Brainstorming Mode (interactive dialogue) + brainstorm-PRD Agent (requirements expertise)
|
||||
|
||||
## Section Guidelines
|
||||
|
||||
### Purpose
|
||||
- Focus on operational behavior changes
|
||||
- Explain what interaction pattern or processing method is enabled
|
||||
- Keep it clear and action-oriented
|
||||
|
||||
### Core Capabilities
|
||||
- Group related capabilities under numbered categories
|
||||
- Use bold formatting for feature names
|
||||
- Be specific about behavioral changes
|
||||
|
||||
### Activation
|
||||
- Document both manual (flag-based) and automatic triggers
|
||||
- Automatic triggers should be observable patterns
|
||||
- Include confidence thresholds where applicable
|
||||
|
||||
### Mode-Specific Sections
|
||||
Choose based on mode type:
|
||||
- **State-Based**: Document states, transitions, and exit conditions
|
||||
- **Communication**: Define markers, styles, and patterns
|
||||
- **Processing**: Explain techniques, optimizations, and algorithms
|
||||
- **Analysis**: Describe types, methods, and outputs
|
||||
|
||||
### Communication Style
|
||||
- How the mode changes Claude's interaction
|
||||
- Include examples of communication patterns
|
||||
- Note any special markers or formatting
|
||||
|
||||
### Integration Points
|
||||
- List all related flags with their interactions
|
||||
- Include relevant commands, agents, or tools
|
||||
- Note any mode combinations or conflicts
|
||||
|
||||
### Configuration
|
||||
- YAML block showing configurable settings
|
||||
- Include defaults and valid ranges
|
||||
- Group settings logically
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Clarity**: Write for developers who need quick reference
|
||||
2. **Specificity**: Focus on observable behavior changes
|
||||
3. **Examples**: Include concrete examples where helpful
|
||||
4. **Consistency**: Follow this template structure exactly
|
||||
5. **Completeness**: Cover all major behavioral aspects
|
||||
|
||||
## File Naming
|
||||
- Use prefix: `MODE_ModeName.md`
|
||||
- Be descriptive but concise with MODE_ prefix
|
||||
- Examples: `MODE_Brainstorming.md`, `MODE_Introspection.md`, `MODE_Token_Efficiency.md`
|
||||
|
||||
## Location
|
||||
All Mode documentation files should be placed in:
|
||||
`SuperClaude/Modes/`
|
||||
@@ -1,285 +0,0 @@
|
||||
---
|
||||
name: [mode-name]
|
||||
description: "[Clear purpose and behavioral modification description]"
|
||||
type: behavioral
|
||||
|
||||
# Mode Classification
|
||||
category: [optimization|analysis]
|
||||
complexity: basic
|
||||
scope: [session|framework]
|
||||
|
||||
# Activation Configuration
|
||||
activation:
|
||||
automatic: [true|false]
|
||||
manual-flags: [list of flags]
|
||||
confidence-threshold: [0.0-1.0]
|
||||
detection-patterns: [list of trigger patterns]
|
||||
|
||||
# Integration Configuration
|
||||
framework-integration:
|
||||
mcp-servers: [list of coordinated servers]
|
||||
commands: [list of integrated commands]
|
||||
modes: [list of coordinated modes]
|
||||
quality-gates: [list of quality integration points]
|
||||
|
||||
# Performance Profile
|
||||
performance-profile: lightweight
|
||||
---
|
||||
|
||||
# [Mode Name] Mode
|
||||
|
||||
**[Optional Subtitle]** - [Brief description focusing on behavioral modification and framework impact]
|
||||
|
||||
## Purpose
|
||||
|
||||
[Clear description of the behavioral framework this mode provides. Focus on:
|
||||
- What operational behavior changes it enables
|
||||
- How it modifies Claude Code's approach to tasks
|
||||
- Why this behavioral modification is valuable
|
||||
- What problems it solves in the SuperClaude framework]
|
||||
|
||||
## Core [Capabilities|Framework]
|
||||
|
||||
### 1. [Primary Framework Category]
|
||||
- **[Core Feature]**: [Specific behavioral modification it provides]
|
||||
- **[Core Feature]**: [How it changes Claude's operational approach]
|
||||
- **[Core Feature]**: [Framework integration point or enhancement]
|
||||
- **[Core Feature]**: [Quality or performance improvement provided]
|
||||
|
||||
### 2. [Secondary Framework Category]
|
||||
- **[Supporting Feature]**: [Additional behavioral enhancement]
|
||||
- **[Supporting Feature]**: [Integration with other framework components]
|
||||
- **[Supporting Feature]**: [Cross-cutting concern or optimization]
|
||||
|
||||
### 3. [Integration Framework Category]
|
||||
- **[Integration Feature]**: [How it coordinates with MCP servers]
|
||||
- **[Integration Feature]**: [How it enhances command execution]
|
||||
- **[Integration Feature]**: [How it supports quality gates]
|
||||
|
||||
[Continue with additional categories as needed for the specific mode]
|
||||
|
||||
## Activation Patterns
|
||||
|
||||
### Automatic Activation
|
||||
[Mode] auto-activates when SuperClaude detects:
|
||||
|
||||
1. **[Primary Trigger Category]**: [Description of detection pattern]
|
||||
2. **[Secondary Trigger Category]**: [Specific conditions or keywords]
|
||||
3. **[Context Trigger Category]**: [Environmental or situational triggers]
|
||||
4. **[Performance Trigger Category]**: [Resource or performance-based triggers]
|
||||
5. **[Integration Trigger Category]**: [Framework or quality-based triggers]
|
||||
|
||||
### Manual Activation
|
||||
- **Primary Flag**: `--[shorthand]` or `--[fullname]`
|
||||
- **Context**: [When users would explicitly request this behavioral mode]
|
||||
- **Integration**: [How it works with other flags or commands]
|
||||
- **Fallback Control**: `--no-[shorthand]` disables automatic activation
|
||||
|
||||
## [Mode-Specific Framework Section]
|
||||
|
||||
[This section varies by behavioral mode type:]
|
||||
|
||||
### For Optimization Modes: Optimization Framework
|
||||
[Include frameworks like symbol systems, compression strategies, resource management, etc.]
|
||||
|
||||
### For Analysis Modes: Analysis Framework
|
||||
[Include analysis markers, communication patterns, assessment categories, etc.]
|
||||
|
||||
### Framework Components
|
||||
[Document the core framework elements this mode provides:]
|
||||
|
||||
## Framework Integration
|
||||
|
||||
### SuperClaude Mode Coordination
|
||||
- **[Related Mode]**: [How this mode coordinates with other behavioral modes]
|
||||
- **[Related Mode]**: [Shared configuration or mutual enhancement]
|
||||
- **[Related Mode]**: [Conflict resolution or priority handling]
|
||||
|
||||
### MCP Server Integration
|
||||
- **[Server Name]**: [How this mode enhances or coordinates with MCP servers]
|
||||
- **[Server Name]**: [Specific integration points or optimizations]
|
||||
- **[Server Name]**: [Performance improvements or behavioral modifications]
|
||||
|
||||
### Quality Gate Integration
|
||||
- **[Gate Step]**: [How this mode contributes to validation process]
|
||||
- **[Gate Step]**: [Specific quality enhancements provided]
|
||||
- **[Gate Type]**: [Continuous monitoring or checkpoint integration]
|
||||
|
||||
### Command Integration
|
||||
- **[Command Category]**: [How this mode modifies command execution]
|
||||
- **[Command Category]**: [Behavioral enhancements during command flow]
|
||||
- **[Command Category]**: [Performance or quality improvements]
|
||||
|
||||
## Communication Style
|
||||
|
||||
### [Primary Communication Pattern]
|
||||
1. **[Style Element]**: [How this mode changes Claude's communication]
|
||||
2. **[Style Element]**: [Specific behavioral modifications in responses]
|
||||
3. **[Style Element]**: [Integration with SuperClaude communication standards]
|
||||
4. **[Style Element]**: [Quality or efficiency improvements in dialogue]
|
||||
|
||||
### [Secondary Communication Pattern]
|
||||
1. **[Pattern Element]**: [Additional communication behaviors]
|
||||
2. **[Pattern Element]**: [Framework compliance in communication]
|
||||
3. **[Pattern Element]**: [Cross-mode communication consistency]
|
||||
|
||||
[Include mode-specific communication elements like symbols, markers, abbreviations, etc.]
|
||||
|
||||
## Configuration
|
||||
|
||||
```yaml
|
||||
[mode_name]_mode:
|
||||
activation:
|
||||
automatic: [true|false]
|
||||
confidence_threshold: [0.0-1.0]
|
||||
detection_patterns:
|
||||
[pattern_category]: [list of patterns]
|
||||
[pattern_category]: [list of patterns]
|
||||
|
||||
[framework_category]:
|
||||
[setting]: [value]
|
||||
[setting]: [value]
|
||||
[threshold_name]: [threshold_value]
|
||||
|
||||
framework_integration:
|
||||
mcp_servers: [list of coordinated servers]
|
||||
quality_gates: [list of integration points]
|
||||
mode_coordination: [list of coordinated modes]
|
||||
|
||||
behavioral_settings:
|
||||
[behavior_aspect]: [configuration]
|
||||
[behavior_aspect]: [configuration]
|
||||
|
||||
performance:
|
||||
[performance_metric]: [target_value]
|
||||
[performance_metric]: [target_value]
|
||||
```
|
||||
|
||||
## Integration Ecosystem
|
||||
|
||||
### SuperClaude Framework Compliance
|
||||
|
||||
```yaml
|
||||
framework_integration:
|
||||
quality_gates: [specific quality integration points]
|
||||
mcp_coordination: [server coordination patterns]
|
||||
mode_orchestration: [cross-mode behavioral coordination]
|
||||
document_persistence: [how behavioral changes are documented]
|
||||
|
||||
behavioral_consistency:
|
||||
communication_patterns: [standardized behavioral modifications]
|
||||
performance_standards: [performance targets and monitoring]
|
||||
quality_enforcement: [framework standards maintained]
|
||||
integration_protocols: [coordination with other components]
|
||||
```
|
||||
|
||||
### Cross-Mode Behavioral Coordination
|
||||
|
||||
```yaml
|
||||
mode_interactions:
|
||||
[related_mode]: [specific coordination pattern]
|
||||
[related_mode]: [shared behavioral modifications]
|
||||
[related_mode]: [conflict resolution strategy]
|
||||
|
||||
orchestration_principles:
|
||||
behavioral_consistency: [how consistency is maintained]
|
||||
configuration_harmony: [shared settings and coordination]
|
||||
quality_enforcement: [SuperClaude standards preserved]
|
||||
performance_optimization: [efficiency gains through coordination]
|
||||
```
|
||||
|
||||
## Related Documentation
|
||||
|
||||
- **Framework Reference**: [ORCHESTRATOR.md or other relevant framework docs]
|
||||
- **Integration Patterns**: [specific command or MCP integration docs]
|
||||
- **Quality Standards**: [quality gate or validation references]
|
||||
- **Performance Targets**: [performance monitoring or optimization docs]
|
||||
|
||||
---
|
||||
|
||||
# Template Guide: Basic Behavioral Modes
|
||||
|
||||
## Overview
|
||||
|
||||
This template is designed for **basic behavioral framework modes** that provide lightweight, session-scoped behavioral modifications to Claude Code's operation. These modes focus on optimizing specific aspects of the SuperClaude framework through global behavioral changes.
|
||||
|
||||
## Behavioral Mode Characteristics
|
||||
|
||||
### Key Features
|
||||
- **Lightweight Performance Profile**: Minimal resource overhead with maximum behavioral impact
|
||||
- **Global Behavioral Modification**: Changes that apply consistently across all operations
|
||||
- **Framework Integration**: Deep integration with SuperClaude's quality gates and orchestration
|
||||
- **Adaptive Intelligence**: Context-aware behavioral adjustments based on task complexity
|
||||
- **Evidence-Based Operation**: All behavioral modifications validated with metrics
|
||||
|
||||
### Mode Types Supported
|
||||
|
||||
#### Optimization Modes
|
||||
- **Focus**: Performance, efficiency, resource management, token optimization
|
||||
- **Examples**: Token Efficiency, Resource Management, Performance Optimization
|
||||
- **Framework**: Symbol systems, compression strategies, threshold management
|
||||
- **Metrics**: Performance targets, efficiency gains, resource utilization
|
||||
|
||||
#### Analysis Modes
|
||||
- **Focus**: Meta-cognitive analysis, introspection, framework troubleshooting
|
||||
- **Examples**: Introspection, Quality Analysis, Framework Compliance
|
||||
- **Framework**: Analysis markers, assessment categories, communication patterns
|
||||
- **Metrics**: Analysis depth, insight quality, framework compliance
|
||||
|
||||
## Template Sections
|
||||
|
||||
### Required Sections
|
||||
1. **YAML Frontmatter**: Structured metadata for mode classification and configuration
|
||||
2. **Purpose**: Clear behavioral modification description
|
||||
3. **Core Framework**: The specific framework this mode provides
|
||||
4. **Activation Patterns**: Auto-detection and manual activation
|
||||
5. **Framework Integration**: SuperClaude ecosystem integration
|
||||
6. **Configuration**: YAML configuration structures
|
||||
|
||||
### Optional Sections
|
||||
- **Communication Style**: For modes that modify interaction patterns
|
||||
- **Mode-Specific Framework**: Custom framework elements (symbols, markers, etc.)
|
||||
- **Integration Ecosystem**: Advanced coordination patterns
|
||||
|
||||
## Usage Guidelines
|
||||
|
||||
### When to Use This Template
|
||||
- **Simple behavioral modifications** that don't require complex state management
|
||||
- **Global optimizations** that apply across all operations
|
||||
- **Framework enhancements** that integrate with SuperClaude's core systems
|
||||
- **Lightweight modes** with minimal performance overhead
|
||||
|
||||
### When NOT to Use This Template
|
||||
- **Complex workflow modes** with multiple states (use Template_Mode_Advanced.md)
|
||||
- **Agent-like modes** with domain expertise (use Template_Agent.md)
|
||||
- **Command-integrated modes** with execution workflows (use Template_Command_Session.md)
|
||||
|
||||
## Customization Points
|
||||
|
||||
### For Optimization Modes
|
||||
- Focus on **performance metrics** and **efficiency frameworks**
|
||||
- Include **symbol systems** or **compression strategies**
|
||||
- Emphasize **resource management** and **threshold configurations**
|
||||
- Document **integration with MCP servers** for performance gains
|
||||
|
||||
### For Analysis Modes
|
||||
- Focus on **analysis frameworks** and **assessment categories**
|
||||
- Include **communication markers** and **transparency patterns**
|
||||
- Emphasize **meta-cognitive capabilities** and **framework compliance**
|
||||
- Document **troubleshooting patterns** and **insight generation**
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Clear Behavioral Focus**: Each mode should have a single, clear behavioral modification
|
||||
2. **Framework Integration**: Deep integration with SuperClaude's quality gates and orchestration
|
||||
3. **Performance Awareness**: Document performance impact and optimization benefits
|
||||
4. **Evidence-Based Design**: Include metrics and validation for all behavioral changes
|
||||
5. **Consistent Communication**: Maintain SuperClaude's communication standards
|
||||
|
||||
## File Naming Convention
|
||||
- **Prefix**: `MODE_`
|
||||
- **Format**: `MODE_{ModeName}.md`
|
||||
- **Examples**: `MODE_Token_Efficiency.md`, `MODE_Introspection.md`
|
||||
|
||||
## Location
|
||||
All Basic Behavioral Mode files should be placed in: `SuperClaude/Modes/`
|
||||
@@ -1,351 +0,0 @@
|
||||
---
|
||||
name: [mode-name]
|
||||
description: "[Clear purpose and behavioral modification description]"
|
||||
type: command-integrated
|
||||
|
||||
# Mode Classification
|
||||
category: [orchestration|coordination|behavioral|processing]
|
||||
complexity: [standard|advanced|enterprise]
|
||||
scope: [session|cross-session|project|system]
|
||||
|
||||
# Activation Configuration
|
||||
activation:
|
||||
automatic: [true|false]
|
||||
manual-flags: [list of flags]
|
||||
confidence-threshold: [0.0-1.0]
|
||||
detection-patterns: [list of trigger patterns]
|
||||
|
||||
# Integration Configuration
|
||||
framework-integration:
|
||||
mcp-servers: [list of coordinated servers]
|
||||
commands: [primary command integration]
|
||||
modes: [list of coordinated modes]
|
||||
quality-gates: [list of quality integration points]
|
||||
|
||||
# Performance Profile
|
||||
performance-profile: [standard|optimized|enterprise]
|
||||
---
|
||||
|
||||
# [Mode Name] Mode
|
||||
|
||||
**[Optional Subtitle]** - [Brief description emphasizing command integration and behavioral framework]
|
||||
|
||||
## Purpose
|
||||
|
||||
[Comprehensive description explaining the behavioral framework mode and its integration with the primary command. Should cover:]
|
||||
- Primary behavioral modification provided
|
||||
- Command integration relationship and coordination
|
||||
- Cross-session capabilities and persistence
|
||||
- Agent orchestration and handoff workflows
|
||||
|
||||
## Core Behavioral Framework
|
||||
|
||||
### 1. [Primary Behavioral Category]
|
||||
- **[Behavioral Feature]**: [Description of behavioral modification]
|
||||
- **[Behavioral Feature]**: [Description of behavioral modification]
|
||||
- **[Behavioral Feature]**: [Description of behavioral modification]
|
||||
- **[Behavioral Feature]**: [Description of behavioral modification]
|
||||
|
||||
### 2. [Integration Capabilities Category]
|
||||
- **[Integration Feature]**: [Description of integration capability]
|
||||
- **[Integration Feature]**: [Description of integration capability]
|
||||
- **[Integration Feature]**: [Description of integration capability]
|
||||
- **[Integration Feature]**: [Description of integration capability]
|
||||
|
||||
### 3. [Configuration Management Category]
|
||||
- **[Configuration Feature]**: [Description of configuration management]
|
||||
- **[Configuration Feature]**: [Description of configuration management]
|
||||
- **[Configuration Feature]**: [Description of configuration management]
|
||||
- **[Configuration Feature]**: [Description of configuration management]
|
||||
|
||||
## Mode Activation
|
||||
|
||||
### Automatic Activation Patterns
|
||||
[Mode Name] Mode auto-activates when SuperClaude detects:
|
||||
|
||||
1. **[Pattern Category]**: [Description and examples of trigger patterns]
|
||||
2. **[Pattern Category]**: [Description and examples of trigger patterns]
|
||||
3. **[Pattern Category]**: [Description and examples of trigger patterns]
|
||||
4. **[Pattern Category]**: [Description and examples of trigger patterns]
|
||||
5. **[Pattern Category]**: [Description and examples of trigger patterns]
|
||||
|
||||
### Manual Activation
|
||||
- **Primary Flag**: `--[primary-flag]` or `--[shorthand]`
|
||||
- **Integration**: Works with [primary-command] command for explicit invocation
|
||||
- **Fallback Control**: `--no-[mode-name]` disables automatic activation
|
||||
|
||||
### Command Integration
|
||||
- **Primary Implementation**: [primary-command] command handles execution workflow
|
||||
- **Mode Responsibility**: Behavioral configuration and auto-activation logic
|
||||
- **Workflow Reference**: See [primary-command] for detailed [workflow-type] phases and execution steps
|
||||
|
||||
## Framework Integration
|
||||
|
||||
### SuperClaude Mode Coordination
|
||||
- **[Related Mode]**: [Description of coordination relationship]
|
||||
- **[Related Mode]**: [Description of coordination relationship]
|
||||
- **[Related Mode]**: [Description of coordination relationship]
|
||||
|
||||
### MCP Server Integration
|
||||
- **[Server Name]**: [Description of server coordination and purpose]
|
||||
- **[Server Name]**: [Description of server coordination and purpose]
|
||||
- **[Server Name]**: [Description of server coordination and purpose]
|
||||
|
||||
### Quality Gate Integration
|
||||
- **Step [X.X]**: [Description of quality gate integration point]
|
||||
- **Step [X.X]**: [Description of quality gate integration point]
|
||||
- **Continuous**: [Description of ongoing quality monitoring]
|
||||
|
||||
### Agent Orchestration
|
||||
- **[Orchestration Type]**: [Description of agent coordination]
|
||||
- **[Orchestration Type]**: [Description of agent coordination]
|
||||
- **[Orchestration Type]**: [Description of agent coordination]
|
||||
|
||||
## [Mode-Specific Integration Pattern]
|
||||
|
||||
**[Integration Pattern Name]** - [Description of specialized integration workflow]
|
||||
|
||||
### [Integration Feature Name]
|
||||
[Description of when and how this integration occurs]
|
||||
|
||||
1. **[Step Name]**: [Description of integration step]
|
||||
2. **[Step Name]**: [Description of integration step]
|
||||
3. **[Step Name]**: [Description of integration step]
|
||||
4. **[Step Name]**: [Description of integration step]
|
||||
5. **[Step Name]**: [Description of integration step]
|
||||
|
||||
### [Integration Intelligence Feature]
|
||||
```yaml
|
||||
[feature_name]:
|
||||
[setting_category]: [list of settings]
|
||||
[setting_category]: [list of settings]
|
||||
[setting_category]: [list of settings]
|
||||
|
||||
[related_feature]:
|
||||
[setting_category]: [value or description]
|
||||
[setting_category]: [value or description]
|
||||
[setting_category]: [value or description]
|
||||
```
|
||||
|
||||
### Integration Benefits
|
||||
- **[Benefit Category]**: [Description of integration advantage]
|
||||
- **[Benefit Category]**: [Description of integration advantage]
|
||||
- **[Benefit Category]**: [Description of integration advantage]
|
||||
- **[Benefit Category]**: [Description of integration advantage]
|
||||
|
||||
## Mode Configuration
|
||||
|
||||
```yaml
|
||||
[mode_name]_mode:
|
||||
activation:
|
||||
automatic: [true|false]
|
||||
confidence_threshold: [0.0-1.0]
|
||||
detection_patterns:
|
||||
[pattern_category]: [list of patterns]
|
||||
[pattern_category]: [list of patterns]
|
||||
[pattern_category]: [list of patterns]
|
||||
|
||||
mode_command_integration:
|
||||
primary_implementation: "[primary-command]"
|
||||
parameter_mapping:
|
||||
# MODE YAML Setting → Command Parameter
|
||||
[setting_name]: "[command-parameter]" # Default: [value]
|
||||
[setting_name]: "[command-parameter]" # Default: [value]
|
||||
[setting_name]: "[command-parameter]" # Default: [value]
|
||||
[setting_name]: "[command-parameter]" # Default: [value]
|
||||
[setting_name]: "[command-parameter]" # Default: [value]
|
||||
override_precedence: "explicit > mode > framework > system"
|
||||
coordination_workflow:
|
||||
- [workflow_step]
|
||||
- [workflow_step]
|
||||
- [workflow_step]
|
||||
- [workflow_step]
|
||||
- [workflow_step]
|
||||
|
||||
[integration_category]:
|
||||
[setting_name]: [value]
|
||||
[setting_name]: [list of values]
|
||||
[setting_name]: [value]
|
||||
[setting_name]: [value]
|
||||
|
||||
framework_integration:
|
||||
mcp_servers: [list of servers]
|
||||
quality_gates: [list of quality integration points]
|
||||
mode_coordination: [list of coordinated modes]
|
||||
|
||||
behavioral_settings:
|
||||
[behavior_category]: [value]
|
||||
[behavior_category]: [value]
|
||||
[behavior_category]: [value]
|
||||
[behavior_category]: [value]
|
||||
|
||||
persistence:
|
||||
[storage_location]: [path or description]
|
||||
[tracking_type]: [true|false]
|
||||
[tracking_type]: [true|false]
|
||||
[tracking_type]: [true|false]
|
||||
[tracking_type]: [true|false]
|
||||
```
|
||||
|
||||
## Related Documentation
|
||||
|
||||
- **Primary Implementation**: [primary-command] command
|
||||
- **Agent Integration**: [related-agent] for [integration-purpose]
|
||||
- **Framework Reference**: [related-mode-file] for [coordination-purpose]
|
||||
- **Quality Standards**: [reference-file] for [validation-purpose]
|
||||
|
||||
---
|
||||
|
||||
# Command-Integrated Mode Template Guide
|
||||
|
||||
## Overview
|
||||
This template provides a standardized format for documenting Command-Integrated Modes in the SuperClaude framework. These modes define behavioral frameworks that coordinate closely with specific commands to provide seamless user experiences.
|
||||
|
||||
## Key Characteristics: Command-Integrated Modes
|
||||
|
||||
### Architecture Pattern
|
||||
**Behavioral Mode + Command Implementation = Unified Experience**
|
||||
|
||||
- **Mode**: Provides behavioral framework, auto-detection, and configuration
|
||||
- **Command**: Handles execution workflow, parameter processing, and results
|
||||
- **Integration**: Seamless parameter mapping, workflow coordination, and quality validation
|
||||
|
||||
### Integration Types
|
||||
- **Orchestration Modes**: Coordinate multiple systems (agents, MCP servers, quality gates)
|
||||
- **Coordination Modes**: Manage cross-session workflows and state persistence
|
||||
- **Behavioral Modes**: Modify interaction patterns and communication styles
|
||||
- **Processing Modes**: Enhance execution with specialized algorithms or optimizations
|
||||
|
||||
## Frontmatter Configuration
|
||||
|
||||
### Required Fields
|
||||
```yaml
|
||||
name: [kebab-case-name] # Machine-readable identifier
|
||||
description: "[clear-purpose]" # Human-readable purpose statement
|
||||
type: command-integrated # Always this value for this template
|
||||
|
||||
category: [classification] # Primary mode category
|
||||
complexity: [level] # Implementation complexity level
|
||||
scope: [operational-scope] # Operational boundaries
|
||||
|
||||
activation: # Activation configuration
|
||||
automatic: [boolean] # Whether mode auto-activates
|
||||
manual-flags: [list] # Manual activation flags
|
||||
confidence-threshold: [float] # Auto-activation confidence level
|
||||
detection-patterns: [list] # Pattern matching triggers
|
||||
|
||||
framework-integration: # Integration points
|
||||
mcp-servers: [list] # Coordinated MCP servers
|
||||
commands: [list] # Integrated commands
|
||||
modes: [list] # Coordinated modes
|
||||
quality-gates: [list] # Quality integration points
|
||||
|
||||
performance-profile: [level] # Performance characteristics
|
||||
```
|
||||
|
||||
### Value Guidelines
|
||||
- **Category**: orchestration, coordination, behavioral, processing
|
||||
- **Complexity**: standard, advanced, enterprise
|
||||
- **Scope**: session, cross-session, project, system
|
||||
- **Performance Profile**: standard, optimized, enterprise
|
||||
|
||||
## Section Guidelines
|
||||
|
||||
### Purpose Section
|
||||
Should comprehensively explain:
|
||||
- The behavioral framework provided by the mode
|
||||
- How it integrates with the primary command
|
||||
- Cross-session capabilities and persistence features
|
||||
- Agent orchestration and handoff workflows
|
||||
|
||||
### Core Behavioral Framework
|
||||
- **3 numbered subsections minimum**
|
||||
- Focus on behavioral modifications and integration capabilities
|
||||
- Include configuration management and framework compliance
|
||||
- Use consistent bullet point formatting
|
||||
|
||||
### Mode Activation
|
||||
- **Automatic Activation Patterns**: 5+ specific trigger patterns with examples
|
||||
- **Manual Activation**: Primary flags and integration details
|
||||
- **Command Integration**: Clear workflow responsibilities and references
|
||||
|
||||
### Framework Integration
|
||||
- **4 subsections required**: Mode Coordination, MCP Integration, Quality Gates, Agent Orchestration
|
||||
- Document all coordination relationships
|
||||
- Include specific integration points and workflows
|
||||
|
||||
### Mode-Specific Integration Pattern
|
||||
- **Customizable section name** based on mode's primary integration feature
|
||||
- Document specialized workflows unique to this mode
|
||||
- Include YAML configuration blocks for complex features
|
||||
- List concrete integration benefits
|
||||
|
||||
### Mode Configuration
|
||||
- **Comprehensive YAML structure** with nested categories
|
||||
- **Parameter mapping section** showing mode-to-command parameter inheritance
|
||||
- **Coordination workflow** documenting integration steps
|
||||
- **Behavioral settings** and persistence configuration
|
||||
|
||||
### Related Documentation
|
||||
- Always include primary command reference
|
||||
- Link to related agents and their integration purpose
|
||||
- Reference framework coordination documentation
|
||||
- Include quality standards and validation references
|
||||
|
||||
## Best Practices
|
||||
|
||||
### 1. Integration Clarity
|
||||
- Clearly separate mode responsibilities from command responsibilities
|
||||
- Document parameter inheritance and override precedence
|
||||
- Explain coordination workflows step-by-step
|
||||
|
||||
### 2. Behavioral Focus
|
||||
- Emphasize how the mode modifies SuperClaude's behavior
|
||||
- Document communication patterns and interaction changes
|
||||
- Include examples of behavioral modifications
|
||||
|
||||
### 3. Framework Compliance
|
||||
- Ensure integration with SuperClaude quality gates
|
||||
- Document MCP server coordination patterns
|
||||
- Include agent orchestration workflows
|
||||
|
||||
### 4. Configuration Completeness
|
||||
- Provide comprehensive YAML configuration examples
|
||||
- Document all parameter mappings between mode and command
|
||||
- Include default values and valid ranges
|
||||
|
||||
### 5. Cross-Session Awareness
|
||||
- Document persistence and session lifecycle integration
|
||||
- Include cross-session coordination patterns
|
||||
- Explain context retention and state management
|
||||
|
||||
## Integration Architecture
|
||||
|
||||
### Mode-Command Coordination Flow
|
||||
```
|
||||
1. Pattern Detection (Mode)
|
||||
2. Auto-Activation (Mode)
|
||||
3. Parameter Mapping (Mode → Command)
|
||||
4. Command Invocation (Framework)
|
||||
5. Behavioral Enforcement (Mode)
|
||||
6. Quality Validation (Framework)
|
||||
7. Result Coordination (Mode + Command)
|
||||
```
|
||||
|
||||
### Quality Gate Integration Points
|
||||
- **Pre-Activation**: Mode detection and pattern validation
|
||||
- **Parameter Mapping**: Configuration inheritance and validation
|
||||
- **Execution Monitoring**: Behavioral compliance and quality tracking
|
||||
- **Post-Execution**: Result validation and session persistence
|
||||
|
||||
## File Naming Convention
|
||||
- **Pattern**: `Template_Mode_Command_Integrated.md`
|
||||
- **Usage**: For modes that integrate closely with specific commands
|
||||
- **Examples**: Brainstorming Mode + /sc:brainstorm, Task Management Mode + /task
|
||||
|
||||
## Location
|
||||
Template files should be placed in:
|
||||
`SuperClaude/Templates/`
|
||||
|
||||
Implemented modes should be placed in:
|
||||
`SuperClaude/Modes/` or directly in the global configuration directory
|
||||
@@ -1,401 +0,0 @@
|
||||
# [Monitoring Mode Name] Mode
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: [mode-name]
|
||||
description: "[Clear purpose and behavioral modification description]"
|
||||
type: monitoring
|
||||
|
||||
# Mode Classification
|
||||
category: tracking
|
||||
complexity: system
|
||||
scope: framework
|
||||
|
||||
# Activation Configuration
|
||||
activation:
|
||||
automatic: [true|false]
|
||||
manual-flags: [list of flags]
|
||||
confidence-threshold: [0.0-1.0]
|
||||
detection-patterns: [monitoring trigger patterns]
|
||||
|
||||
# Integration Configuration
|
||||
framework-integration:
|
||||
mcp-servers: [list of coordinated servers]
|
||||
commands: [list of monitored commands]
|
||||
modes: [list of coordinated modes]
|
||||
quality-gates: [monitoring integration points]
|
||||
|
||||
# Performance Profile
|
||||
performance-profile: real-time
|
||||
performance-targets: [specific monitoring requirements]
|
||||
---
|
||||
```
|
||||
|
||||
**[Optional Subtitle]** - [Brief description of real-time monitoring and metrics collection capabilities]
|
||||
|
||||
## Purpose & Monitoring Scope
|
||||
|
||||
[Clear description of what aspects of the system this mode monitors and tracks. Explain the real-time monitoring capabilities and why continuous metrics collection is critical for this domain.]
|
||||
|
||||
### Monitoring Domains
|
||||
- **[Domain 1]**: [What aspects are monitored and why]
|
||||
- **[Domain 2]**: [Specific metrics and tracking requirements]
|
||||
- **[Domain 3]**: [Performance characteristics monitored]
|
||||
|
||||
### Tracking Objectives
|
||||
- **[Objective 1]**: [Specific measurement goals and targets]
|
||||
- **[Objective 2]**: [Quality metrics and thresholds]
|
||||
- **[Objective 3]**: [Performance optimization goals]
|
||||
|
||||
## Core Capabilities
|
||||
|
||||
### 1. Real-Time Metrics Collection
|
||||
- **[Metric Category]**: [Description of metrics tracked and collection method]
|
||||
- **[Metric Category]**: [Real-time measurement approach and frequency]
|
||||
- **[Metric Category]**: [Data aggregation and storage strategy]
|
||||
- **[Metric Category]**: [Historical trend analysis capabilities]
|
||||
|
||||
### 2. Performance Monitoring
|
||||
- **[Performance Aspect]**: [Specific performance metrics and targets]
|
||||
- **[Performance Aspect]**: [Threshold monitoring and alert systems]
|
||||
- **[Performance Aspect]**: [Optimization detection and recommendations]
|
||||
- **[Performance Aspect]**: [Resource utilization tracking]
|
||||
|
||||
### 3. Analytics & Pattern Recognition
|
||||
- **[Analysis Type]**: [Pattern detection algorithms and insights]
|
||||
- **[Analysis Type]**: [Trend analysis and predictive capabilities]
|
||||
- **[Analysis Type]**: [Anomaly detection and alert mechanisms]
|
||||
- **[Analysis Type]**: [Correlation analysis across metrics]
|
||||
|
||||
### 4. Dashboard & Reporting
|
||||
- **[Dashboard Type]**: [Real-time dashboard format and information]
|
||||
- **[Report Format]**: [Structured reporting capabilities and frequency]
|
||||
- **[Alert System]**: [Notification mechanisms and escalation paths]
|
||||
- **[Export Capabilities]**: [Data export formats and integration options]
|
||||
|
||||
## Activation Patterns
|
||||
|
||||
### Automatic Activation
|
||||
1. **[Monitoring Trigger]**: [Specific conditions that automatically enable monitoring]
|
||||
2. **[Performance Threshold]**: [Performance degradation or optimization opportunities]
|
||||
3. **[System Event]**: [System lifecycle events requiring monitoring]
|
||||
4. **[Risk Indicator]**: [High-risk operations needing continuous tracking]
|
||||
5. **[Quality Gate]**: [Integration with SuperClaude quality validation steps]
|
||||
|
||||
### Manual Activation
|
||||
- **Primary Flag**: `--[shorthand]` or `--[fullname]`
|
||||
- **Monitoring Scope**: `--monitor-[scope]` for targeted monitoring
|
||||
- **Alert Level**: `--alert-level [level]` for threshold configuration
|
||||
- **Context**: [When users would manually activate comprehensive monitoring]
|
||||
|
||||
### Smart Detection Patterns
|
||||
- **[Pattern Type]**: [Detection algorithms and confidence thresholds]
|
||||
- **[Context Indicator]**: [Situational awareness patterns]
|
||||
- **[Risk Assessment]**: [Risk-based activation strategies]
|
||||
|
||||
## Performance Targets
|
||||
|
||||
### Response Time Requirements
|
||||
- **Metrics Collection**: [Target collection frequency and latency]
|
||||
- **Dashboard Updates**: [Real-time update requirements]
|
||||
- **Alert Generation**: [Alert response time targets]
|
||||
- **Report Generation**: [Report compilation time limits]
|
||||
|
||||
### Accuracy Standards
|
||||
- **Measurement Precision**: [Required accuracy levels for different metrics]
|
||||
- **Data Integrity**: [Data validation and consistency requirements]
|
||||
- **Historical Accuracy**: [Long-term data preservation standards]
|
||||
|
||||
### Resource Efficiency
|
||||
- **CPU Overhead**: [Maximum CPU usage for monitoring operations]
|
||||
- **Memory Usage**: [Memory footprint limits and optimization]
|
||||
- **Storage Requirements**: [Data retention and compression strategies]
|
||||
- **Network Impact**: [Network utilization limits for distributed monitoring]
|
||||
|
||||
## Monitoring Framework
|
||||
|
||||
### Metrics Collection Engine
|
||||
- **[Collection Method]**: [Real-time data collection approach and tools]
|
||||
- **[Aggregation Strategy]**: [Data aggregation algorithms and time windows]
|
||||
- **[Storage Architecture]**: [Metrics storage and retrieval system]
|
||||
- **[Retention Policy]**: [Data lifecycle and archival strategies]
|
||||
|
||||
### Real-Time Monitoring Systems
|
||||
- **[Monitoring Component]**: [Continuous monitoring implementation]
|
||||
- **[Alert Engine]**: [Real-time alert generation and routing]
|
||||
- **[Threshold Management]**: [Dynamic threshold adjustment capabilities]
|
||||
- **[Escalation System]**: [Alert escalation and notification workflows]
|
||||
|
||||
### Analytics Infrastructure
|
||||
- **[Analysis Engine]**: [Real-time analytics processing capabilities]
|
||||
- **[Pattern Detection]**: [Automated pattern recognition systems]
|
||||
- **[Predictive Analytics]**: [Forecasting and trend prediction capabilities]
|
||||
- **[Correlation Analysis]**: [Cross-metric correlation and causation analysis]
|
||||
|
||||
## Integration Patterns
|
||||
|
||||
### Session Lifecycle Integration
|
||||
- **Session Start**: [Monitoring initialization and baseline establishment]
|
||||
- **Active Monitoring**: [Continuous tracking during work sessions]
|
||||
- **Checkpoint Integration**: [Metrics capture during checkpoints]
|
||||
- **Session End**: [Final metrics collection and summary generation]
|
||||
|
||||
### Quality Gates Integration
|
||||
- **[Quality Gate Step]**: [Specific monitoring integration point]
|
||||
- **[Validation Phase]**: [Performance validation during quality checks]
|
||||
- **[Compliance Monitoring]**: [Framework compliance tracking]
|
||||
|
||||
### Command Coordination
|
||||
- **[Command Category]**: [Monitoring integration with specific command types]
|
||||
- **[Operation Type]**: [Performance tracking for different operation categories]
|
||||
- **[Workflow Integration]**: [Monitoring embedded in standard workflows]
|
||||
|
||||
### MCP Server Coordination
|
||||
- **[Server Name]**: [Monitoring integration with specific MCP servers]
|
||||
- **[Cross-Server Analytics]**: [Coordination monitoring across multiple servers]
|
||||
- **[Performance Correlation]**: [Server performance impact analysis]
|
||||
|
||||
### Mode Interactions
|
||||
- **[Coordinated Mode]**: [How monitoring integrates with other active modes]
|
||||
- **[Mode Switching]**: [Monitoring behavior during mode transitions]
|
||||
- **[Multi-Mode Analytics]**: [Analysis across multiple active modes]
|
||||
|
||||
## Analytics & Reporting
|
||||
|
||||
### Dashboard Formats
|
||||
- **[Dashboard Type]**: [Real-time dashboard structure and components]
|
||||
- **[Visualization Format]**: [Chart types and data presentation methods]
|
||||
- **[Interactive Features]**: [User interaction capabilities and drill-down options]
|
||||
|
||||
### Report Structures
|
||||
- **[Report Category]**: [Structured report format and content organization]
|
||||
- **[Summary Format]**: [Executive summary and key metrics presentation]
|
||||
- **[Detailed Analysis]**: [In-depth analysis report structure]
|
||||
|
||||
### Trend Analysis
|
||||
- **[Trend Type]**: [Historical trend analysis capabilities]
|
||||
- **[Predictive Modeling]**: [Forecasting algorithms and accuracy metrics]
|
||||
- **[Comparative Analysis]**: [Baseline comparison and performance evolution]
|
||||
|
||||
### Alert Systems
|
||||
- **[Alert Level]**: [Alert severity classification and response requirements]
|
||||
- **[Notification Methods]**: [Alert delivery mechanisms and routing]
|
||||
- **[Escalation Procedures]**: [Alert escalation workflows and timeouts]
|
||||
|
||||
## Advanced Features
|
||||
|
||||
### [Feature Category 1]
|
||||
- **[Advanced Feature]**: [Description of sophisticated monitoring capability]
|
||||
- **[Integration Method]**: [How advanced features integrate with core monitoring]
|
||||
- **[Performance Impact]**: [Resource requirements and optimization strategies]
|
||||
|
||||
### [Feature Category 2]
|
||||
- **[Analytics Feature]**: [Advanced analytics and machine learning capabilities]
|
||||
- **[Automation Feature]**: [Automated response and optimization features]
|
||||
- **[Integration Feature]**: [Advanced integration with external systems]
|
||||
|
||||
## Hook System Integration
|
||||
|
||||
### Event-Driven Monitoring
|
||||
- **[Hook Category]**: [Monitoring hooks for specific event types]
|
||||
- **[Trigger Events]**: [Events that activate monitoring collection]
|
||||
- **[Response Actions]**: [Automated responses to monitoring events]
|
||||
|
||||
### Performance Hooks
|
||||
- **[Performance Event]**: [Performance-related hook integration]
|
||||
- **[Optimization Trigger]**: [Automatic optimization based on monitoring data]
|
||||
- **[Alerting Hook]**: [Hook-based alert generation and routing]
|
||||
|
||||
## Error Handling & Recovery
|
||||
|
||||
### Monitoring Failures
|
||||
- **[Failure Type]**: [How different monitoring failures are handled]
|
||||
- **[Fallback Strategy]**: [Backup monitoring approaches and degraded modes]
|
||||
- **[Recovery Procedure]**: [Automatic recovery and manual intervention options]
|
||||
|
||||
### Data Integrity
|
||||
- **[Validation Method]**: [Data validation and consistency checking]
|
||||
- **[Corruption Handling]**: [Data corruption detection and recovery]
|
||||
- **[Backup Strategy]**: [Monitoring data backup and restoration procedures]
|
||||
|
||||
## Configuration
|
||||
|
||||
```yaml
|
||||
[mode_name]_monitoring:
|
||||
# Activation Configuration
|
||||
activation:
|
||||
automatic: [true|false]
|
||||
confidence_threshold: [0.0-1.0]
|
||||
detection_patterns: [list]
|
||||
|
||||
# Performance Targets
|
||||
performance:
|
||||
collection_frequency_ms: [number]
|
||||
alert_response_time_ms: [number]
|
||||
dashboard_update_interval_ms: [number]
|
||||
report_generation_timeout_ms: [number]
|
||||
|
||||
# Metrics Configuration
|
||||
metrics:
|
||||
collection_interval: [duration]
|
||||
retention_period: [duration]
|
||||
aggregation_windows: [list]
|
||||
precision_level: [number]
|
||||
|
||||
# Monitoring Scope
|
||||
scope:
|
||||
commands: [list]
|
||||
operations: [list]
|
||||
resources: [list]
|
||||
integrations: [list]
|
||||
|
||||
# Alert Configuration
|
||||
alerts:
|
||||
enabled: [true|false]
|
||||
severity_levels: [list]
|
||||
notification_methods: [list]
|
||||
escalation_timeout: [duration]
|
||||
|
||||
# Dashboard Configuration
|
||||
dashboard:
|
||||
real_time_updates: [true|false]
|
||||
refresh_interval_ms: [number]
|
||||
visualization_types: [list]
|
||||
interactive_features: [true|false]
|
||||
|
||||
# Analytics Configuration
|
||||
analytics:
|
||||
pattern_detection: [true|false]
|
||||
trend_analysis: [true|false]
|
||||
predictive_modeling: [true|false]
|
||||
correlation_analysis: [true|false]
|
||||
|
||||
# Storage Configuration
|
||||
storage:
|
||||
backend_type: [string]
|
||||
compression_enabled: [true|false]
|
||||
retention_policy: [string]
|
||||
archival_strategy: [string]
|
||||
|
||||
# Integration Configuration
|
||||
integration:
|
||||
quality_gates: [list]
|
||||
mcp_servers: [list]
|
||||
hook_system: [true|false]
|
||||
session_lifecycle: [true|false]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# Monitoring Mode Template Guide
|
||||
|
||||
## Overview
|
||||
This template provides a specialized format for documenting Monitoring and Analytics Modes in the SuperClaude framework. These modes focus on real-time tracking, metrics collection, performance monitoring, and analytical insights.
|
||||
|
||||
## Key Characteristics: Monitoring Modes
|
||||
|
||||
### Primary Focus Areas
|
||||
- **Real-Time Tracking**: Continuous monitoring with immediate feedback
|
||||
- **Performance Metrics**: Quantitative measurement and optimization
|
||||
- **System Analytics**: Pattern recognition and trend analysis
|
||||
- **Quality Assurance**: Compliance monitoring and validation
|
||||
- **Resource Optimization**: Efficiency tracking and improvement
|
||||
|
||||
### Behavioral Modifications
|
||||
- **Continuous Collection**: Ongoing metrics gathering during operations
|
||||
- **Alert Generation**: Proactive notification of issues or opportunities
|
||||
- **Dashboard Updates**: Real-time information presentation
|
||||
- **Trend Analysis**: Historical pattern recognition and forecasting
|
||||
- **Performance Optimization**: Automatic or recommended improvements
|
||||
|
||||
## Section Guidelines
|
||||
|
||||
### Purpose & Monitoring Scope
|
||||
- Define what aspects of the system are monitored
|
||||
- Explain the value and necessity of continuous tracking
|
||||
- Identify specific domains and objectives for monitoring
|
||||
- Clarify the scope and boundaries of monitoring activities
|
||||
|
||||
### Core Capabilities
|
||||
- **Real-Time Metrics**: Continuous data collection and processing
|
||||
- **Performance Monitoring**: System performance tracking and optimization
|
||||
- **Analytics & Pattern Recognition**: Data analysis and insight generation
|
||||
- **Dashboard & Reporting**: Information presentation and communication
|
||||
|
||||
### Activation Patterns
|
||||
- Document automatic activation triggers based on system conditions
|
||||
- Include performance thresholds and quality gate integration
|
||||
- Specify manual activation flags and configuration options
|
||||
- Define smart detection patterns and confidence thresholds
|
||||
|
||||
### Performance Targets
|
||||
- Specify concrete timing requirements for all monitoring operations
|
||||
- Define accuracy standards and data integrity requirements
|
||||
- Set resource efficiency limits and optimization constraints
|
||||
- Establish baseline performance metrics and improvement targets
|
||||
|
||||
### Monitoring Framework
|
||||
- Detail the technical implementation of metrics collection
|
||||
- Describe real-time monitoring systems and alert engines
|
||||
- Explain analytics infrastructure and processing capabilities
|
||||
- Document data storage, retention, and archival strategies
|
||||
|
||||
### Integration Patterns
|
||||
- Show how monitoring integrates with session lifecycle
|
||||
- Define quality gate integration points and validation phases
|
||||
- Explain coordination with commands, MCP servers, and other modes
|
||||
- Detail hook system integration for event-driven monitoring
|
||||
|
||||
### Analytics & Reporting
|
||||
- Define dashboard formats and visualization approaches
|
||||
- Specify report structures and content organization
|
||||
- Explain trend analysis capabilities and predictive modeling
|
||||
- Detail alert systems and notification mechanisms
|
||||
|
||||
### Configuration
|
||||
- Comprehensive YAML configuration covering all monitoring aspects
|
||||
- Include performance targets, alert settings, and integration options
|
||||
- Define storage configuration and analytics capabilities
|
||||
- Specify activation parameters and scope settings
|
||||
|
||||
## Best Practices for Monitoring Modes
|
||||
|
||||
### Performance-First Design
|
||||
1. **Minimal Overhead**: Monitoring should not significantly impact system performance
|
||||
2. **Efficient Collection**: Optimize data collection methods for minimal resource usage
|
||||
3. **Smart Aggregation**: Use intelligent aggregation to reduce storage and processing requirements
|
||||
4. **Selective Monitoring**: Enable targeted monitoring based on context and needs
|
||||
|
||||
### Real-Time Responsiveness
|
||||
1. **Immediate Feedback**: Provide real-time updates and immediate alert generation
|
||||
2. **Low Latency**: Minimize delay between events and monitoring response
|
||||
3. **Continuous Operation**: Ensure monitoring continues even during system stress
|
||||
4. **Graceful Degradation**: Maintain essential monitoring even when resources are constrained
|
||||
|
||||
### Data Quality & Integrity
|
||||
1. **Accurate Measurement**: Ensure monitoring data is precise and reliable
|
||||
2. **Consistent Collection**: Maintain consistency in data collection methods
|
||||
3. **Validation Checks**: Implement data validation and integrity checking
|
||||
4. **Error Handling**: Robust error handling for monitoring failures
|
||||
|
||||
### Integration Excellence
|
||||
1. **Seamless Integration**: Monitoring should integrate transparently with existing workflows
|
||||
2. **Framework Compliance**: Maintain compliance with SuperClaude framework standards
|
||||
3. **Cross-Mode Coordination**: Coordinate effectively with other active modes
|
||||
4. **Hook System Integration**: Leverage hook system for event-driven monitoring
|
||||
|
||||
## File Naming Convention
|
||||
- Use prefix: `MODE_[MonitoringType]_Monitoring.md`
|
||||
- Examples: `MODE_Performance_Monitoring.md`, `MODE_Quality_Analytics.md`, `MODE_Resource_Tracking.md`
|
||||
|
||||
## Location
|
||||
All Monitoring Mode documentation files should be placed in:
|
||||
`SuperClaude/Modes/`
|
||||
|
||||
## Integration with Template System
|
||||
This template specializes the base `Template_Mode.md` for monitoring and analytics use cases, providing:
|
||||
- Enhanced performance target specifications
|
||||
- Comprehensive monitoring framework documentation
|
||||
- Advanced analytics and reporting capabilities
|
||||
- Real-time system integration patterns
|
||||
- Sophisticated configuration options for monitoring systems
|
||||
@@ -1,297 +0,0 @@
|
||||
# {Mode Name} Mode
|
||||
|
||||
## Core Principles
|
||||
- [Primary Principle]: [Description with measurable outcomes]
|
||||
- [Secondary Principle]: [Description with validation criteria]
|
||||
- [Tertiary Principle]: [Description with quality gates]
|
||||
- [Quality Principle]: [Description with enforcement mechanisms]
|
||||
|
||||
## Architecture Layers
|
||||
|
||||
### Layer 1: {Foundation Layer} ([Scope Description])
|
||||
- **Scope**: [Operating scope and boundaries]
|
||||
- **States**: [Available states and transitions]
|
||||
- **Capacity**: [Operational limits and thresholds]
|
||||
- **Integration**: [How this layer connects to others]
|
||||
|
||||
### Layer 2: {Coordination Layer} ([Scope Description])
|
||||
- **Scope**: [Operating scope and boundaries]
|
||||
- **Structure**: [Organizational patterns and hierarchies]
|
||||
- **Persistence**: [State management and durability]
|
||||
- **Coordination**: [Inter-layer communication patterns]
|
||||
|
||||
### Layer 3: {Orchestration Layer} ([Scope Description])
|
||||
- **Scope**: [Operating scope and boundaries]
|
||||
- **Features**: [Advanced capabilities and coordination]
|
||||
- **Management**: [Resource and dependency management]
|
||||
- **Intelligence**: [Decision-making and optimization]
|
||||
|
||||
### Layer 4: {Enhancement Layer} ([Scope Description])
|
||||
- **Scope**: [Operating scope and boundaries]
|
||||
- **Features**: [Progressive and iterative capabilities]
|
||||
- **Optimization**: [Performance and quality improvements]
|
||||
- **Analytics**: [Measurement and feedback loops]
|
||||
|
||||
## {Primary System} Detection and Creation
|
||||
|
||||
### Automatic Triggers
|
||||
- [Trigger Category 1]: [Description with examples]
|
||||
- [Trigger Category 2]: [Description with detection patterns]
|
||||
- [Trigger Category 3]: [Description with keyword patterns]
|
||||
- [Scope Indicators]: [Description with complexity thresholds]
|
||||
|
||||
### {Primary System} State Management
|
||||
- **{state_1}** {emoji}: [Description and transition criteria]
|
||||
- **{state_2}** {emoji}: [Description and constraints]
|
||||
- **{state_3}** {emoji}: [Description and dependency handling]
|
||||
- **{state_4}** {emoji}: [Description and completion criteria]
|
||||
|
||||
## Related Flags
|
||||
|
||||
### {Primary Delegation} Flags
|
||||
**`--{primary-flag} [{option1}|{option2}|{option3}]`**
|
||||
- Enable {system} for {capability description}
|
||||
- **{option1}**: [Description and use cases]
|
||||
- **{option2}**: [Description and use cases]
|
||||
- **{option3}**: [Description and intelligent behavior]
|
||||
- Auto-activates: [Threshold conditions]
|
||||
- [Performance benefit]: [Quantified improvement metrics]
|
||||
|
||||
**`--{control-flag} [n]`**
|
||||
- Control [parameter description] (default: [N], range: [min-max])
|
||||
- [Dynamic behavior]: [Description of adaptive behavior]
|
||||
- [Safety feature]: [Description of protection mechanisms]
|
||||
|
||||
### {Secondary System} Flags
|
||||
**`--{orchestration-flag} [{mode1}|{mode2}|{mode3}]`**
|
||||
- Control {orchestration system} activation
|
||||
- **{mode1}**: [Auto-activation criteria and behavior]
|
||||
- **{mode2}**: [Override conditions and use cases]
|
||||
- **{mode3}**: [Disable conditions and fallback behavior]
|
||||
- [Performance metric]: [Quantified improvement through intelligence]
|
||||
|
||||
**`--{strategy-flag} [{strategy1}|{strategy2}|{strategy3}|{strategy4}]`**
|
||||
- Select {orchestration system} strategy
|
||||
- **{strategy1}**: [Description and optimal use cases]
|
||||
- **{strategy2}**: [Description and complexity handling]
|
||||
- **{strategy3}**: [Description and adaptive behavior]
|
||||
- **{strategy4}**: [Description and enterprise-scale handling]
|
||||
|
||||
**`--{delegation-flag} [{type1}|{type2}|{type3}]`**
|
||||
- Control how {system} delegates work to {subsystem}
|
||||
- **{type1}**: [Description and granularity]
|
||||
- **{type2}**: [Description and organizational approach]
|
||||
- **{type3}**: [Description and functional approach]
|
||||
|
||||
### {Enhancement System} Flags
|
||||
**`--{enhancement-flag}`**
|
||||
- Enable {enhancement capability} for {target operations}
|
||||
- Auto-activates: [Keyword detection and operation types]
|
||||
- Compatible operations: [List of compatible commands/operations]
|
||||
- Default: [Default behavior and validation approach]
|
||||
|
||||
**`--{control-param} [n]`**
|
||||
- Control [parameter description] (default: [N], range: [min-max])
|
||||
- Overrides [intelligent behavior description]
|
||||
|
||||
**`--{interaction-flag}`**
|
||||
- Enable [interaction type] between [system components]
|
||||
- [Behavior description]: [Detailed interaction patterns]
|
||||
- [Benefit description]: [User control and guidance capabilities]
|
||||
|
||||
## Auto-Activation Thresholds
|
||||
- **{Primary System}**: [Threshold conditions with logical operators]
|
||||
- **{Orchestration System}**: [Complex multi-condition thresholds]
|
||||
- **{Enhancement System}**: [Keyword and pattern detection criteria]
|
||||
|
||||
## Document Persistence
|
||||
|
||||
**{Comprehensive description}** with {automated features} and {analytics capabilities}.
|
||||
|
||||
### Directory Structure
|
||||
```
|
||||
ClaudeDocs/{PrimaryCategory}/{SecondaryCategory}/
|
||||
├── {Subcategory1}/ # {Description}
|
||||
├── {Subcategory2}/ # {Description}
|
||||
├── {Subcategory3}/ # {Description}
|
||||
├── {Subcategory4}/ # {Description}
|
||||
└── Archives/ # {Description}
|
||||
```
|
||||
|
||||
### Summary Documents
|
||||
```
|
||||
ClaudeDocs/Summary/
|
||||
├── {summary-type1}-{identifier}-{YYYY-MM-DD-HHMMSS}.md
|
||||
├── {summary-type2}-{project}-{YYYY-MM-DD-HHMMSS}.md
|
||||
├── {summary-type3}-{project}-{YYYY-MM-DD-HHMMSS}.md
|
||||
└── {summary-type4}-{session-id}-{YYYY-MM-DD-HHMMSS}.md
|
||||
```
|
||||
|
||||
### File Naming Convention
|
||||
```
|
||||
{operation-type}-{category}-{YYYY-MM-DD-HHMMSS}.md
|
||||
|
||||
Examples:
|
||||
- {example1}-{category}-2024-12-15-143022.md
|
||||
- {example2}-{category}-2024-12-15-143045.md
|
||||
- {example3}-{category}-2024-12-15-143108.md
|
||||
- {example4}-{category}-2024-12-15-143131.md
|
||||
```
|
||||
|
||||
### {Summary Category} Summaries
|
||||
```
|
||||
{summary-format1}-{identifier}-{YYYY-MM-DD-HHMMSS}.md
|
||||
{summary-format2}-{project}-{YYYY-MM-DD-HHMMSS}.md
|
||||
{summary-format3}-{project}-{YYYY-MM-DD-HHMMSS}.md
|
||||
{summary-format4}-{session-id}-{YYYY-MM-DD-HHMMSS}.md
|
||||
```
|
||||
|
||||
### Metadata Format
|
||||
```yaml
|
||||
---
|
||||
operation_type: [{type1}|{type2}|{type3}|{type4}]
|
||||
timestamp: 2024-12-15T14:30:22Z
|
||||
session_id: session_abc123
|
||||
{complexity_metric}: 0.85
|
||||
{primary_metrics}:
|
||||
{metric1}: {strategy/mode}
|
||||
{metric2}: 3
|
||||
{metric3}: 0.78
|
||||
{metric4}: 0.92
|
||||
{secondary_analytics}:
|
||||
{metric5}: 5
|
||||
{metric6}: 0.65
|
||||
{metric7}: 0.72
|
||||
{metric8}: 0.88
|
||||
{performance_analytics}:
|
||||
{metric9}: 0.45
|
||||
{metric10}: 0.96
|
||||
{metric11}: 0.71
|
||||
{metric12}: 0.38
|
||||
---
|
||||
```
|
||||
|
||||
### Persistence Workflow
|
||||
|
||||
#### {Primary Summary} Generation
|
||||
1. **{Detection Step}**: [Description of trigger detection]
|
||||
2. **{Analysis Step}**: [Description of metrics calculation]
|
||||
3. **{Generation Step}**: [Description of summary creation]
|
||||
4. **{Cross-Reference Step}**: [Description of linking and relationships]
|
||||
5. **{Knowledge Step}**: [Description of pattern documentation]
|
||||
|
||||
#### {Secondary Summary}
|
||||
1. **{Tracking Step}**: [Description of process monitoring]
|
||||
2. **{Metrics Step}**: [Description of performance measurement]
|
||||
3. **{Pattern Step}**: [Description of pattern identification]
|
||||
4. **{Documentation Step}**: [Description of summary generation]
|
||||
5. **{Best Practices Step}**: [Description of pattern documentation]
|
||||
|
||||
### Integration Points
|
||||
|
||||
#### Quality Gates Integration
|
||||
- **Step 2.5**: [Description of mid-process validation]
|
||||
- **Step 7.5**: [Description of completion validation]
|
||||
- **Continuous**: [Description of real-time monitoring]
|
||||
- **Post-{Process}**: [Description of comprehensive analytics]
|
||||
|
||||
## Integration Points
|
||||
|
||||
### {Framework} Integration
|
||||
- **{Integration Type 1}**: [Description and coordination patterns]
|
||||
- **{Integration Type 2}**: [Description and compatibility requirements]
|
||||
- **{Integration Type 3}**: [Description and cross-system coordination]
|
||||
- **{Integration Type 4}**: [Description and workflow orchestration]
|
||||
|
||||
### {Cross-System} Coordination
|
||||
- **{Coordination Type 1}**: [Description and interaction patterns]
|
||||
- **{Coordination Type 2}**: [Description and shared capabilities]
|
||||
- **{Coordination Type 3}**: [Description and complementary functionality]
|
||||
- **{Coordination Type 4}**: [Description and unified workflows]
|
||||
|
||||
### Quality Gates Integration
|
||||
- **Step {N}.5**: [Description of validation point integration]
|
||||
- **Step {M}.5**: [Description of completion verification]
|
||||
- **Continuous**: [Description of ongoing monitoring]
|
||||
- **{Specialized}**: [Description of specialized validation]
|
||||
|
||||
## Configuration
|
||||
|
||||
```yaml
|
||||
{mode_name}:
|
||||
activation:
|
||||
automatic: {true|false}
|
||||
{threshold_type}: 0.{N}
|
||||
detection_patterns:
|
||||
{pattern_type1}: ["{pattern1}", "{pattern2}", "{pattern3}"]
|
||||
{pattern_type2}: [{keyword1}, {keyword2}, {keyword3}]
|
||||
{pattern_type3}: [{indicator1}, {indicator2}, {indicator3}]
|
||||
|
||||
{system1}_coordination:
|
||||
{param1}: {default_value}
|
||||
{param2}: [{option1}, {option2}, {option3}]
|
||||
{param3}: {behavior_description}
|
||||
{param4}: {intelligence_feature}
|
||||
|
||||
{system2}_integration:
|
||||
{feature1}: {true|false}
|
||||
{feature2}: {value}
|
||||
{feature3}: {configuration}
|
||||
{feature4}: {coordination_setting}
|
||||
|
||||
{analytics_system}:
|
||||
{metric1}: {target_value}
|
||||
{metric2}: {measurement_approach}
|
||||
{metric3}: {optimization_setting}
|
||||
{metric4}: {reporting_configuration}
|
||||
|
||||
{performance_tuning}:
|
||||
{param1}: {performance_value}
|
||||
{param2}: {efficiency_setting}
|
||||
{param3}: {resource_limit}
|
||||
{param4}: {optimization_approach}
|
||||
|
||||
{persistence_config}:
|
||||
enabled: true
|
||||
directory: "ClaudeDocs/{Category}/"
|
||||
auto_save: true
|
||||
{feature1}:
|
||||
- {type1}
|
||||
- {type2}
|
||||
- {type3}
|
||||
{feature2}: yaml
|
||||
{feature3}: {retention_period}
|
||||
```
|
||||
|
||||
## Related Documentation
|
||||
|
||||
- **{Primary Implementation}**: [Description and reference]
|
||||
- **{Secondary Integration}**: [Description and cross-reference]
|
||||
- **{Framework Reference}**: [Description and coordination guide]
|
||||
- **{Quality Standards}**: [Description and validation reference]
|
||||
|
||||
---
|
||||
|
||||
## Template Usage Notes
|
||||
|
||||
**Mode Classification Requirements:**
|
||||
- **system-architecture**: Multi-layer systems with complex orchestration, extensive flag systems, and comprehensive integration
|
||||
- **Category: orchestration**: Advanced coordination and management capabilities
|
||||
- **Complexity: advanced**: Sophisticated logic, multiple integration points, comprehensive analytics
|
||||
- **Scope: framework**: Deep integration with SuperClaude framework and cross-system coordination
|
||||
|
||||
**Key Architectural Elements:**
|
||||
1. **Multi-Layer Architecture**: Hierarchical system organization with clear layer boundaries and interactions
|
||||
2. **Extensive Flag Systems**: Complex flag coordination with delegation, orchestration, and enhancement capabilities
|
||||
3. **Auto-Activation Logic**: Sophisticated threshold systems with multi-condition evaluation
|
||||
4. **Comprehensive Persistence**: Advanced documentation with metadata, analytics, and cross-referencing
|
||||
5. **Framework Integration**: Deep quality gate integration and cross-system coordination
|
||||
6. **Performance Analytics**: Comprehensive metrics collection and optimization tracking
|
||||
|
||||
**Template Customization Guidelines:**
|
||||
- Replace `{Mode Name}` with actual mode name
|
||||
- Customize layer descriptions based on actual architecture
|
||||
- Adapt flag systems to match mode capabilities
|
||||
- Configure persistence structure for mode requirements
|
||||
- Align integration points with framework standards
|
||||
- Adjust configuration YAML to mode specifications
|
||||
@@ -1,275 +0,0 @@
|
||||
# Session Metadata Template
|
||||
|
||||
This template defines the standard structure for session metadata used by the SuperClaude session lifecycle pattern with Serena MCP integration.
|
||||
|
||||
## Core Session Metadata Template
|
||||
|
||||
### Memory Key Format
|
||||
```
|
||||
session_metadata_{YYYY_MM_DD}_{session_id}
|
||||
```
|
||||
|
||||
### YAML Structure
|
||||
```yaml
|
||||
# Session Metadata - SuperClaude Session Lifecycle
|
||||
# Memory Key: session_metadata_{YYYY_MM_DD}_{session_id}
|
||||
# Created: {ISO8601_timestamp}
|
||||
# Version: 1.0
|
||||
|
||||
metadata:
|
||||
format_version: "1.0"
|
||||
created_by: "SuperClaude Session Lifecycle"
|
||||
template_source: "Template_Session_Metadata.md"
|
||||
|
||||
session:
|
||||
id: "session-{YYYY-MM-DD-HHMMSS}"
|
||||
project: "{project_name}"
|
||||
start_time: "{ISO8601_timestamp}" # UTC format
|
||||
end_time: "{ISO8601_timestamp}" # UTC format
|
||||
duration_minutes: {number}
|
||||
state: "{initializing|active|checkpointed|completed}"
|
||||
user_timezone: "{timezone}"
|
||||
claude_model: "{model_version}"
|
||||
|
||||
context:
|
||||
memories_loaded:
|
||||
- "{memory_key_1}"
|
||||
- "{memory_key_2}"
|
||||
initial_context_size: {tokens}
|
||||
final_context_size: {tokens}
|
||||
context_growth: {percentage}
|
||||
onboarding_performed: {true|false}
|
||||
|
||||
work:
|
||||
tasks_completed:
|
||||
- id: "{task_id}"
|
||||
description: "{task_description}"
|
||||
start_time: "{ISO8601_timestamp}"
|
||||
end_time: "{ISO8601_timestamp}"
|
||||
duration_minutes: {number}
|
||||
priority: "{high|medium|low}"
|
||||
status: "{completed|failed|blocked}"
|
||||
|
||||
files_modified:
|
||||
- path: "{absolute_path}"
|
||||
operations: ["{edit|create|delete}"]
|
||||
changes: {number}
|
||||
size_before: {bytes}
|
||||
size_after: {bytes}
|
||||
|
||||
commands_executed:
|
||||
- command: "{command_name}"
|
||||
timestamp: "{ISO8601_timestamp}"
|
||||
duration_ms: {number}
|
||||
success: {true|false}
|
||||
|
||||
decisions_made:
|
||||
- timestamp: "{ISO8601_timestamp}"
|
||||
decision: "{decision_description}"
|
||||
rationale: "{reasoning}"
|
||||
impact: "{architectural|functional|performance|security}"
|
||||
confidence: {0.0-1.0}
|
||||
|
||||
discoveries:
|
||||
patterns_found:
|
||||
- pattern: "{pattern_description}"
|
||||
confidence: {0.0-1.0}
|
||||
examples: ["{example_1}", "{example_2}"]
|
||||
|
||||
insights_gained:
|
||||
- insight: "{insight_description}"
|
||||
category: "{architectural|technical|process|quality}"
|
||||
actionable: {true|false}
|
||||
|
||||
performance_improvements:
|
||||
- improvement: "{improvement_description}"
|
||||
metric: "{metric_name}"
|
||||
before: {value}
|
||||
after: {value}
|
||||
improvement_percentage: {percentage}
|
||||
|
||||
issues_identified:
|
||||
- issue: "{issue_description}"
|
||||
severity: "{critical|high|medium|low}"
|
||||
category: "{bug|performance|security|quality}"
|
||||
resolution_status: "{resolved|pending|deferred}"
|
||||
|
||||
checkpoints:
|
||||
automatic:
|
||||
- timestamp: "{ISO8601_timestamp}"
|
||||
type: "{task_complete|time_based|risk_based|error_recovery}"
|
||||
trigger: "{trigger_description}"
|
||||
checkpoint_id: "checkpoint-{YYYY-MM-DD-HHMMSS}"
|
||||
|
||||
manual:
|
||||
- timestamp: "{ISO8601_timestamp}"
|
||||
user_requested: {true|false}
|
||||
checkpoint_id: "checkpoint-{YYYY-MM-DD-HHMMSS}"
|
||||
notes: "{user_notes}"
|
||||
|
||||
performance:
|
||||
operations:
|
||||
- name: "{operation_name}"
|
||||
duration_ms: {number}
|
||||
target_ms: {number}
|
||||
status: "{pass|warning|fail}"
|
||||
overhead_percentage: {percentage}
|
||||
|
||||
session_metrics:
|
||||
- metric: "session_initialization"
|
||||
value: {milliseconds}
|
||||
target: 500
|
||||
|
||||
- metric: "memory_operations_avg"
|
||||
value: {milliseconds}
|
||||
target: 200
|
||||
|
||||
- metric: "tool_selection_avg"
|
||||
value: {milliseconds}
|
||||
target: 100
|
||||
|
||||
- metric: "context_loading"
|
||||
value: {milliseconds}
|
||||
target: 500
|
||||
|
||||
alerts:
|
||||
- timestamp: "{ISO8601_timestamp}"
|
||||
metric: "{metric_name}"
|
||||
threshold_exceeded: {value}
|
||||
threshold_limit: {value}
|
||||
severity: "{warning|critical}"
|
||||
|
||||
integration:
|
||||
mcp_servers_used:
|
||||
- server: "serena"
|
||||
operations: {number}
|
||||
average_response_ms: {number}
|
||||
success_rate: {percentage}
|
||||
|
||||
- server: "morphllm"
|
||||
operations: {number}
|
||||
average_response_ms: {number}
|
||||
success_rate: {percentage}
|
||||
|
||||
hooks_triggered:
|
||||
- hook: "{hook_name}"
|
||||
timestamp: "{ISO8601_timestamp}"
|
||||
duration_ms: {number}
|
||||
success: {true|false}
|
||||
|
||||
quality_gates_passed:
|
||||
- gate: "{gate_name}"
|
||||
timestamp: "{ISO8601_timestamp}"
|
||||
result: "{pass|fail|warning}"
|
||||
score: {0.0-1.0}
|
||||
|
||||
learning:
|
||||
patterns_evolved:
|
||||
- pattern: "{pattern_name}"
|
||||
evolution: "{improvement_description}"
|
||||
confidence_change: {percentage}
|
||||
|
||||
knowledge_accumulated:
|
||||
- domain: "{domain_name}"
|
||||
new_concepts: {number}
|
||||
connections_made: {number}
|
||||
|
||||
effectiveness_metrics:
|
||||
- metric: "problem_solving_efficiency"
|
||||
value: {0.0-1.0}
|
||||
trend: "{improving|stable|declining}"
|
||||
|
||||
- metric: "context_retention"
|
||||
value: {percentage}
|
||||
target: 90
|
||||
|
||||
cross_references:
|
||||
related_sessions:
|
||||
- session_id: "{related_session_id}"
|
||||
relationship: "{continuation|related_project|similar_pattern}"
|
||||
|
||||
memory_updates:
|
||||
- memory_key: "{memory_key}"
|
||||
update_type: "{created|updated|enhanced}"
|
||||
|
||||
documentation_created:
|
||||
- document: "{document_path}"
|
||||
type: "{prd|brief|report|analysis}"
|
||||
|
||||
validation:
|
||||
data_integrity: {true|false}
|
||||
required_fields_present: {true|false}
|
||||
timestamp_consistency: {true|false}
|
||||
performance_targets_met: {percentage}
|
||||
|
||||
completion_criteria:
|
||||
- criterion: "all_tasks_resolved"
|
||||
met: {true|false}
|
||||
|
||||
- criterion: "context_preserved"
|
||||
met: {true|false}
|
||||
|
||||
- criterion: "performance_acceptable"
|
||||
met: {true|false}
|
||||
```
|
||||
|
||||
## Usage Instructions
|
||||
|
||||
### 1. Session Initialization
|
||||
- Copy template structure
|
||||
- Replace all `{placeholder}` values with actual data
|
||||
- Use UTC timestamps in ISO8601 format
|
||||
- Set initial state to "initializing"
|
||||
|
||||
### 2. During Session
|
||||
- Update work.tasks_completed as tasks finish
|
||||
- Add files_modified entries for each file operation
|
||||
- Record decisions_made with full context
|
||||
- Track performance.operations for timing
|
||||
|
||||
### 3. Session Completion
|
||||
- Set end_time and final state
|
||||
- Calculate duration_minutes
|
||||
- Ensure all performance metrics recorded
|
||||
- Validate completion criteria
|
||||
|
||||
### 4. Memory Storage
|
||||
Use Serena MCP `write_memory` tool:
|
||||
```
|
||||
write_memory
|
||||
{
|
||||
"memory_name": "session_metadata_2025_01_31_143022",
|
||||
"content": "{YAML_content_above}"
|
||||
}
|
||||
```
|
||||
|
||||
## Integration Points
|
||||
|
||||
### With /sc:load Command
|
||||
- Initialize session metadata on project activation
|
||||
- Load checkpoint metadata for session restoration
|
||||
- Track context loading performance
|
||||
|
||||
### With /sc:save Command
|
||||
- Update session metadata throughout work
|
||||
- Create checkpoint metadata when triggered
|
||||
- Record final session state and metrics
|
||||
|
||||
### With Hooks System
|
||||
- Track hook execution in integration.hooks_triggered
|
||||
- Record quality gate results
|
||||
- Monitor performance impact of hooks
|
||||
|
||||
## Validation Rules
|
||||
|
||||
1. **Required Fields**: session.id, session.project, session.start_time must be present
|
||||
2. **Timestamp Format**: All timestamps must be ISO8601 UTC format
|
||||
3. **Performance Targets**: All operations must record duration and compare to targets
|
||||
4. **State Consistency**: Session state must follow lifecycle pattern
|
||||
5. **Cross-References**: All memory_updates must reference valid memory keys
|
||||
|
||||
## Template Versioning
|
||||
|
||||
- **Version 1.0**: Initial template supporting basic session lifecycle
|
||||
- **Future Versions**: Will extend with additional metrics and integration points
|
||||
- **Backward Compatibility**: New versions will maintain core structure compatibility
|
||||
Reference in New Issue
Block a user