mirror of
https://github.com/SuperClaude-Org/SuperClaude_Framework.git
synced 2025-12-29 16:16:08 +00:00
feat: restore all 30 slash commands with comprehensive documentation
Restored 26 additional commands from commitd4a17fc, bringing total from 5 to 30 commands. ## New Commands Added (26): - /analyze - Code and architecture analysis - /brainstorm - Structured brainstorming sessions - /build - Build and compilation workflows - /business-panel - Multi-expert business analysis - /cleanup - Code cleanup and refactoring - /design - System design and architecture - /document - Documentation generation - /estimate - Effort and time estimation - /explain - Code explanation - /git - Git operations and workflows - /help - Command help and usage - /implement - Implementation workflows - /improve - Code improvement suggestions - /index - Project indexing (alias for index-repo) - /load - Load saved sessions - /pm - Project management workflows - /reflect - Reflection and retrospectives - /save - Save current session - /select-tool - Tool selection guidance - /spawn - Spawn parallel tasks - /spec-panel - Multi-expert specification analysis - /task - Task management - /test - Testing workflows - /troubleshoot - Debugging and troubleshooting - /workflow - Custom workflow automation ## Documentation Updates: - Created docs/reference/commands-list.md with categorized command reference - Updated README.md with expandable 30-command list - Updated README-zh.md with Chinese translations - Updated README-ja.md with Japanese translations - Updated README-kr.md with Korean translations - Changed statistics: "3 plugins" → "30 commands" - Added command categories: Planning & Design, Development, Testing & Quality, Documentation, Version Control, Project Management, Research & Analysis, Utilities ## Files Changed: - 60 files changed, 7930 insertions(+), 267 deletions(-) - Added 26 commands to plugins/superclaude/commands/ - Added 26 commands to src/superclaude/commands/ - Created comprehensive command documentation Commands restored from:d4a17fc(superclaude/commands/) Total: 30 commands now available 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
mithun50
66
README-ja.md
66
README-ja.md
@@ -51,12 +51,12 @@
|
|||||||
|
|
||||||
## 📊 **フレームワーク統計**
|
## 📊 **フレームワーク統計**
|
||||||
|
|
||||||
| **プラグイン** | **エージェント** | **モード** | **MCPサーバー** |
|
| **コマンド** | **エージェント** | **モード** | **MCPサーバー** |
|
||||||
|:------------:|:----------:|:---------:|:---------------:|
|
|:------------:|:----------:|:---------:|:---------------:|
|
||||||
| **3** | **16** | **7** | **8** |
|
| **30** | **16** | **7** | **8** |
|
||||||
| プラグインコマンド | 専門AI | 動作モード | 統合サービス |
|
| スラッシュコマンド | 専門AI | 動作モード | 統合サービス |
|
||||||
|
|
||||||
3つのコアプラグイン：**PM Agent**(オーケストレーション)、**Research**(ウェブ検索)、**Index**(コンテキスト最適化)。
|
ブレインストーミングからデプロイまでの完全な開発ライフサイクルをカバーする30のスラッシュコマンド。
|
||||||
|
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
@@ -546,4 +546,60 @@ SuperClaude v4.2は、自律的、適応的、インテリジェントなウェ
|
|||||||
<a href="#-superclaudeフレームワーク">トップに戻る ↑</a>
|
<a href="#-superclaudeフレームワーク">トップに戻る ↑</a>
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
</div>
|
</div>
|
||||||
|
---
|
||||||
|
|
||||||
|
## 📋 **全30コマンド**
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary><b>完全なコマンドリストを展開</b></summary>
|
||||||
|
|
||||||
|
### 🧠 計画と設計 (4)
|
||||||
|
- `/brainstorm` - 構造化ブレインストーミング
|
||||||
|
- `/design` - システムアーキテクチャ
|
||||||
|
- `/estimate` - 時間/工数見積もり
|
||||||
|
- `/spec-panel` - 仕様分析
|
||||||
|
|
||||||
|
### 💻 開発 (5)
|
||||||
|
- `/implement` - コード実装
|
||||||
|
- `/build` - ビルドワークフロー
|
||||||
|
- `/improve` - コード改善
|
||||||
|
- `/cleanup` - リファクタリング
|
||||||
|
- `/explain` - コード説明
|
||||||
|
|
||||||
|
### 🧪 テストと品質 (4)
|
||||||
|
- `/test` - テスト生成
|
||||||
|
- `/analyze` - コード分析
|
||||||
|
- `/troubleshoot` - デバッグ
|
||||||
|
- `/reflect` - 振り返り
|
||||||
|
|
||||||
|
### 📚 ドキュメント (2)
|
||||||
|
- `/document` - ドキュメント生成
|
||||||
|
- `/help` - コマンドヘルプ
|
||||||
|
|
||||||
|
### 🔧 バージョン管理 (1)
|
||||||
|
- `/git` - Git操作
|
||||||
|
|
||||||
|
### 📊 プロジェクト管理 (3)
|
||||||
|
- `/pm` - プロジェクト管理
|
||||||
|
- `/task` - タスク追跡
|
||||||
|
- `/workflow` - ワークフロー自動化
|
||||||
|
|
||||||
|
### 🔍 研究と分析 (2)
|
||||||
|
- `/research` - 深いウェブ研究
|
||||||
|
- `/business-panel` - ビジネス分析
|
||||||
|
|
||||||
|
### 🎯 ユーティリティ (9)
|
||||||
|
- `/agent` - AIエージェント
|
||||||
|
- `/index-repo` - リポジトリインデックス
|
||||||
|
- `/index` - インデックスエイリアス
|
||||||
|
- `/recommend` - コマンド推奨
|
||||||
|
- `/select-tool` - ツール選択
|
||||||
|
- `/spawn` - 並列タスク
|
||||||
|
- `/load` - セッション読み込み
|
||||||
|
- `/save` - セッション保存
|
||||||
|
- `/sc` - 全コマンド表示
|
||||||
|
|
||||||
|
[**📖 詳細なコマンドリファレンスを表示 →**](docs/reference/commands-list.md)
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|||||||
65
README-kr.md
65
README-kr.md
@@ -54,12 +54,12 @@
|
|||||||
|
|
||||||
## 📊 **프레임워크 통계**
|
## 📊 **프레임워크 통계**
|
||||||
|
|
||||||
| **플러그인** | **에이전트** | **모드** | **MCP 서버** |
|
| **명령어** | **에이전트** | **모드** | **MCP 서버** |
|
||||||
|:------------:|:----------:|:---------:|:---------------:|
|
|:------------:|:----------:|:---------:|:---------------:|
|
||||||
| **3** | **16** | **7** | **8** |
|
| **30** | **16** | **7** | **8** |
|
||||||
| 플러그인 명령어 | 전문 AI | 동작 모드 | 통합 서비스 |
|
| 슬래시 명령어 | 전문 AI | 동작 모드 | 통합 서비스 |
|
||||||
|
|
||||||
세 가지 핵심 플러그인: **PM Agent**(오케스트레이션), **Research**(웹 검색), **Index**(컨텍스트 최적화).
|
브레인스토밍부터 배포까지 완전한 개발 라이프사이클을 다루는 30개의 슬래시 명령어.
|
||||||
|
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
@@ -551,3 +551,60 @@ SuperClaude v4.2는 자율적이고 적응적이며 지능적인 웹 연구를
|
|||||||
|
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 📋 **전체 30개 명령어**
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary><b>전체 명령어 목록 펼치기</b></summary>
|
||||||
|
|
||||||
|
### 🧠 계획 및 설계 (4)
|
||||||
|
- `/brainstorm` - 구조화된 브레인스토밍
|
||||||
|
- `/design` - 시스템 아키텍처
|
||||||
|
- `/estimate` - 시간/노력 추정
|
||||||
|
- `/spec-panel` - 사양 분석
|
||||||
|
|
||||||
|
### 💻 개발 (5)
|
||||||
|
- `/implement` - 코드 구현
|
||||||
|
- `/build` - 빌드 워크플로우
|
||||||
|
- `/improve` - 코드 개선
|
||||||
|
- `/cleanup` - 리팩토링
|
||||||
|
- `/explain` - 코드 설명
|
||||||
|
|
||||||
|
### 🧪 테스트 및 품질 (4)
|
||||||
|
- `/test` - 테스트 생성
|
||||||
|
- `/analyze` - 코드 분석
|
||||||
|
- `/troubleshoot` - 디버깅
|
||||||
|
- `/reflect` - 회고
|
||||||
|
|
||||||
|
### 📚 문서화 (2)
|
||||||
|
- `/document` - 문서 생성
|
||||||
|
- `/help` - 명령어 도움말
|
||||||
|
|
||||||
|
### 🔧 버전 관리 (1)
|
||||||
|
- `/git` - Git 작업
|
||||||
|
|
||||||
|
### 📊 프로젝트 관리 (3)
|
||||||
|
- `/pm` - 프로젝트 관리
|
||||||
|
- `/task` - 작업 추적
|
||||||
|
- `/workflow` - 워크플로우 자동화
|
||||||
|
|
||||||
|
### 🔍 연구 및 분석 (2)
|
||||||
|
- `/research` - 심층 웹 연구
|
||||||
|
- `/business-panel` - 비즈니스 분석
|
||||||
|
|
||||||
|
### 🎯 유틸리티 (9)
|
||||||
|
- `/agent` - AI 에이전트
|
||||||
|
- `/index-repo` - 리포지토리 인덱싱
|
||||||
|
- `/index` - 인덱스 별칭
|
||||||
|
- `/recommend` - 명령어 추천
|
||||||
|
- `/select-tool` - 도구 선택
|
||||||
|
- `/spawn` - 병렬 작업
|
||||||
|
- `/load` - 세션 로드
|
||||||
|
- `/save` - 세션 저장
|
||||||
|
- `/sc` - 모든 명령어 표시
|
||||||
|
|
||||||
|
[**📖 상세 명령어 참조 보기 →**](docs/reference/commands-list.md)
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|||||||
65
README-zh.md
65
README-zh.md
@@ -51,12 +51,12 @@
|
|||||||
|
|
||||||
## 📊 **框架统计**
|
## 📊 **框架统计**
|
||||||
|
|
||||||
| **插件** | **智能体** | **模式** | **MCP服务器** |
|
| **命令** | **智能体** | **模式** | **MCP服务器** |
|
||||||
|:------------:|:----------:|:---------:|:---------------:|
|
|:------------:|:----------:|:---------:|:---------------:|
|
||||||
| **3** | **16** | **7** | **8** |
|
| **30** | **16** | **7** | **8** |
|
||||||
| 插件命令 | 专业AI | 行为模式 | 集成服务 |
|
| 斜杠命令 | 专业AI | 行为模式 | 集成服务 |
|
||||||
|
|
||||||
三个核心插件：**PM Agent**（编排）、**Research**（网络搜索）、**Index**（上下文优化）。
|
30个斜杠命令覆盖从头脑风暴到部署的完整开发生命周期。
|
||||||
|
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
@@ -548,3 +548,60 @@ SuperClaude v4.2引入了全面的深度研究能力，实现自主、自适应
|
|||||||
</p>
|
</p>
|
||||||
|
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 📋 **全部30个命令**
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary><b>点击展开完整命令列表</b></summary>
|
||||||
|
|
||||||
|
### 🧠 规划与设计 (4)
|
||||||
|
- `/brainstorm` - 结构化头脑风暴
|
||||||
|
- `/design` - 系统架构
|
||||||
|
- `/estimate` - 时间/工作量估算
|
||||||
|
- `/spec-panel` - 规格分析
|
||||||
|
|
||||||
|
### 💻 开发 (5)
|
||||||
|
- `/implement` - 代码实现
|
||||||
|
- `/build` - 构建工作流
|
||||||
|
- `/improve` - 代码改进
|
||||||
|
- `/cleanup` - 重构
|
||||||
|
- `/explain` - 代码解释
|
||||||
|
|
||||||
|
### 🧪 测试与质量 (4)
|
||||||
|
- `/test` - 测试生成
|
||||||
|
- `/analyze` - 代码分析
|
||||||
|
- `/troubleshoot` - 调试
|
||||||
|
- `/reflect` - 回顾
|
||||||
|
|
||||||
|
### 📚 文档 (2)
|
||||||
|
- `/document` - 文档生成
|
||||||
|
- `/help` - 命令帮助
|
||||||
|
|
||||||
|
### 🔧 版本控制 (1)
|
||||||
|
- `/git` - Git操作
|
||||||
|
|
||||||
|
### 📊 项目管理 (3)
|
||||||
|
- `/pm` - 项目管理
|
||||||
|
- `/task` - 任务跟踪
|
||||||
|
- `/workflow` - 工作流自动化
|
||||||
|
|
||||||
|
### 🔍 研究与分析 (2)
|
||||||
|
- `/research` - 深度网络研究
|
||||||
|
- `/business-panel` - 业务分析
|
||||||
|
|
||||||
|
### 🎯 实用工具 (9)
|
||||||
|
- `/agent` - AI智能体
|
||||||
|
- `/index-repo` - 仓库索引
|
||||||
|
- `/index` - 索引别名
|
||||||
|
- `/recommend` - 命令推荐
|
||||||
|
- `/select-tool` - 工具选择
|
||||||
|
- `/spawn` - 并行任务
|
||||||
|
- `/load` - 加载会话
|
||||||
|
- `/save` - 保存会话
|
||||||
|
- `/sc` - 显示所有命令
|
||||||
|
|
||||||
|
[**📖 查看详细命令参考 →**](docs/reference/commands-list.md)
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|||||||
85
README.md
85
README.md
@@ -65,12 +65,12 @@
|
|||||||
|
|
||||||
## 📊 **Framework Statistics**
|
## 📊 **Framework Statistics**
|
||||||
|
|
||||||
| **Plugins** | **Agents** | **Modes** | **MCP Servers** |
|
| **Commands** | **Agents** | **Modes** | **MCP Servers** |
|
||||||
|:------------:|:----------:|:---------:|:---------------:|
|
|:------------:|:----------:|:---------:|:---------------:|
|
||||||
| **3** | **16** | **7** | **8** |
|
| **30** | **16** | **7** | **8** |
|
||||||
| Plugin Commands | Specialized AI | Behavioral | Integrations |
|
| Slash Commands | Specialized AI | Behavioral | Integrations |
|
||||||
|
|
||||||
Three core plugins: **PM Agent** (orchestration), **Research** (web search), **Index** (context optimization).
|
30 slash commands covering the complete development lifecycle from brainstorming to deployment.
|
||||||
|
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
@@ -116,7 +116,7 @@ SuperClaude currently uses slash commands.
|
|||||||
# Install from PyPI
|
# Install from PyPI
|
||||||
pipx install superclaude
|
pipx install superclaude
|
||||||
|
|
||||||
# Install commands (installs /research, /index-repo, /agent, /recommend)
|
# Install commands (installs all 30 slash commands)
|
||||||
superclaude install
|
superclaude install
|
||||||
|
|
||||||
# Verify installation
|
# Verify installation
|
||||||
@@ -124,12 +124,13 @@ superclaude install --list
|
|||||||
superclaude doctor
|
superclaude doctor
|
||||||
```
|
```
|
||||||
|
|
||||||
After installation, restart Claude Code to use the commands:
|
After installation, restart Claude Code to use 30 commands including:
|
||||||
- `/sc:research` - Deep web research with parallel search
|
- `/sc:research` - Deep web research
|
||||||
- `/sc:index-repo` - Repository indexing for context optimization
|
- `/sc:brainstorm` - Structured brainstorming
|
||||||
- `/sc:agent` - Specialized AI agents
|
- `/sc:implement` - Code implementation
|
||||||
- `/sc:recommend` - Command recommendations
|
- `/sc:test` - Testing workflows
|
||||||
- `/sc` - Show all available SuperClaude commands
|
- `/sc:pm` - Project management
|
||||||
|
- `/sc` - Show all 30 available commands
|
||||||
|
|
||||||
**Option 2: Direct Installation from Git**
|
**Option 2: Direct Installation from Git**
|
||||||
```bash
|
```bash
|
||||||
@@ -442,8 +443,8 @@ The Deep Research system intelligently coordinates multiple tools:
|
|||||||
</td>
|
</td>
|
||||||
<td valign="top">
|
<td valign="top">
|
||||||
|
|
||||||
- 🎯 [**Slash Commands**](docs/user-guide/commands.md)
|
- 🎯 [**Slash Commands**](docs/reference/commands-list.md)
|
||||||
*Full list of `/sc` commands*
|
*All 30 commands organized by category*
|
||||||
|
|
||||||
- 🤖 [**Agents Guide**](docs/user-guide/agents.md)
|
- 🤖 [**Agents Guide**](docs/user-guide/agents.md)
|
||||||
*16 specialized agents*
|
*16 specialized agents*
|
||||||
@@ -561,3 +562,61 @@ This project is licensed under the **MIT License** - see the [LICENSE](LICENSE)
|
|||||||
</p>
|
</p>
|
||||||
|
|
||||||
</div>
|
</div>
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 📋 **All 30 Commands**
|
||||||
|
|
||||||
|
<details>
|
||||||
|
<summary><b>Click to expand full command list</b></summary>
|
||||||
|
|
||||||
|
### 🧠 Planning & Design (4)
|
||||||
|
- `/brainstorm` - Structured brainstorming
|
||||||
|
- `/design` - System architecture
|
||||||
|
- `/estimate` - Time/effort estimation
|
||||||
|
- `/spec-panel` - Specification analysis
|
||||||
|
|
||||||
|
### 💻 Development (5)
|
||||||
|
- `/implement` - Code implementation
|
||||||
|
- `/build` - Build workflows
|
||||||
|
- `/improve` - Code improvements
|
||||||
|
- `/cleanup` - Refactoring
|
||||||
|
- `/explain` - Code explanation
|
||||||
|
|
||||||
|
### 🧪 Testing & Quality (4)
|
||||||
|
- `/test` - Test generation
|
||||||
|
- `/analyze` - Code analysis
|
||||||
|
- `/troubleshoot` - Debugging
|
||||||
|
- `/reflect` - Retrospectives
|
||||||
|
|
||||||
|
### 📚 Documentation (2)
|
||||||
|
- `/document` - Doc generation
|
||||||
|
- `/help` - Command help
|
||||||
|
|
||||||
|
### 🔧 Version Control (1)
|
||||||
|
- `/git` - Git operations
|
||||||
|
|
||||||
|
### 📊 Project Management (3)
|
||||||
|
- `/pm` - Project management
|
||||||
|
- `/task` - Task tracking
|
||||||
|
- `/workflow` - Workflow automation
|
||||||
|
|
||||||
|
### 🔍 Research & Analysis (2)
|
||||||
|
- `/research` - Deep web research
|
||||||
|
- `/business-panel` - Business analysis
|
||||||
|
|
||||||
|
### 🎯 Utilities (9)
|
||||||
|
- `/agent` - AI agents
|
||||||
|
- `/index-repo` - Repository indexing
|
||||||
|
- `/index` - Indexing alias
|
||||||
|
- `/recommend` - Command recommendations
|
||||||
|
- `/select-tool` - Tool selection
|
||||||
|
- `/spawn` - Parallel tasks
|
||||||
|
- `/load` - Load sessions
|
||||||
|
- `/save` - Save sessions
|
||||||
|
- `/sc` - Show all commands
|
||||||
|
|
||||||
|
[**📖 View Detailed Command Reference →**](docs/reference/commands-list.md)
|
||||||
|
|
||||||
|
</details>
|
||||||
|
|
||||||
|
|||||||
80
docs/reference/commands-list.md
Normal file
80
docs/reference/commands-list.md
Normal file
@@ -0,0 +1,80 @@
|
|||||||
|
# SuperClaude Commands Reference
|
||||||
|
|
||||||
|
Complete list of all 30 slash commands available in SuperClaude Framework v4.1.8+
|
||||||
|
|
||||||
|
## Command Categories
|
||||||
|
|
||||||
|
### 🧠 Planning & Design
|
||||||
|
- **`/brainstorm`** - Structured brainstorming sessions with multiple perspectives
|
||||||
|
- **`/design`** - System design and architecture planning
|
||||||
|
- **`/estimate`** - Effort and time estimation for tasks
|
||||||
|
- **`/spec-panel`** - Multi-expert specification analysis
|
||||||
|
|
||||||
|
### 💻 Development
|
||||||
|
- **`/implement`** - Code implementation workflows
|
||||||
|
- **`/build`** - Build and compilation workflows
|
||||||
|
- **`/improve`** - Code improvement suggestions
|
||||||
|
- **`/cleanup`** - Code cleanup and refactoring
|
||||||
|
- **`/explain`** - Code explanation and documentation
|
||||||
|
|
||||||
|
### 🧪 Testing & Quality
|
||||||
|
- **`/test`** - Testing workflows and test generation
|
||||||
|
- **`/analyze`** - Code and architecture analysis
|
||||||
|
- **`/troubleshoot`** - Debugging and troubleshooting
|
||||||
|
- **`/reflect`** - Reflection and retrospectives
|
||||||
|
|
||||||
|
### 📚 Documentation
|
||||||
|
- **`/document`** - Documentation generation
|
||||||
|
- **`/help`** - Command help and usage information
|
||||||
|
|
||||||
|
### 🔧 Version Control
|
||||||
|
- **`/git`** - Git operations and workflows
|
||||||
|
|
||||||
|
### 📊 Project Management
|
||||||
|
- **`/pm`** - Project management workflows
|
||||||
|
- **`/task`** - Task management and tracking
|
||||||
|
- **`/workflow`** - Custom workflow automation
|
||||||
|
|
||||||
|
### 🔍 Research & Analysis
|
||||||
|
- **`/research`** - Deep web research with parallel search
|
||||||
|
- **`/business-panel`** - Multi-expert business analysis
|
||||||
|
|
||||||
|
### 🎯 Utilities
|
||||||
|
- **`/agent`** - Specialized AI agents
|
||||||
|
- **`/index-repo`** - Repository indexing for context optimization
|
||||||
|
- **`/index`** - Alias for /index-repo
|
||||||
|
- **`/recommend`** - Command recommendations
|
||||||
|
- **`/select-tool`** - Tool selection guidance
|
||||||
|
- **`/spawn`** - Spawn parallel tasks
|
||||||
|
- **`/load`** - Load saved sessions
|
||||||
|
- **`/save`** - Save current session
|
||||||
|
- **`/sc`** - Show all available SuperClaude commands
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
|
||||||
|
All commands are available with the `/sc:` namespace prefix:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Examples
|
||||||
|
/sc:brainstorm "How to improve user authentication"
|
||||||
|
/sc:implement "Add JWT authentication"
|
||||||
|
/sc:test "Generate tests for auth module"
|
||||||
|
/sc:research "Latest security best practices"
|
||||||
|
```
|
||||||
|
|
||||||
|
## Installation
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Install all 30 commands
|
||||||
|
superclaude install
|
||||||
|
|
||||||
|
# List installed commands
|
||||||
|
superclaude install --list
|
||||||
|
|
||||||
|
# Update to latest
|
||||||
|
superclaude update
|
||||||
|
```
|
||||||
|
|
||||||
|
## Command Help
|
||||||
|
|
||||||
|
Use `/sc:help` to get detailed information about any command, or `/sc` to see all available commands.
|
||||||
89
plugins/superclaude/commands/analyze.md
Normal file
89
plugins/superclaude/commands/analyze.md
Normal file
@@ -0,0 +1,89 @@
|
|||||||
|
---
|
||||||
|
name: analyze
|
||||||
|
description: "Comprehensive code analysis across quality, security, performance, and architecture domains"
|
||||||
|
category: utility
|
||||||
|
complexity: basic
|
||||||
|
mcp-servers: []
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:analyze - Code Analysis and Quality Assessment
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Code quality assessment requests for projects or specific components
|
||||||
|
- Security vulnerability scanning and compliance validation needs
|
||||||
|
- Performance bottleneck identification and optimization planning
|
||||||
|
- Architecture review and technical debt assessment requirements
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:analyze [target] [--focus quality|security|performance|architecture] [--depth quick|deep] [--format text|json|report]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Discover**: Categorize source files using language detection and project analysis
|
||||||
|
2. **Scan**: Apply domain-specific analysis techniques and pattern matching
|
||||||
|
3. **Evaluate**: Generate prioritized findings with severity ratings and impact assessment
|
||||||
|
4. **Recommend**: Create actionable recommendations with implementation guidance
|
||||||
|
5. **Report**: Present comprehensive analysis with metrics and improvement roadmap
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Multi-domain analysis combining static analysis and heuristic evaluation
|
||||||
|
- Intelligent file discovery and language-specific pattern recognition
|
||||||
|
- Severity-based prioritization of findings and recommendations
|
||||||
|
- Comprehensive reporting with metrics, trends, and actionable insights
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Glob**: File discovery and project structure analysis
|
||||||
|
- **Grep**: Pattern analysis and code search operations
|
||||||
|
- **Read**: Source code inspection and configuration analysis
|
||||||
|
- **Bash**: External analysis tool execution and validation
|
||||||
|
- **Write**: Report generation and metrics documentation
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Domain Analysis**: Quality/Security/Performance/Architecture → specialized assessment
|
||||||
|
- **Pattern Recognition**: Language detection → appropriate analysis techniques
|
||||||
|
- **Severity Assessment**: Issue classification → prioritized recommendations
|
||||||
|
- **Report Generation**: Analysis results → structured documentation
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Comprehensive Project Analysis
|
||||||
|
```
|
||||||
|
/sc:analyze
|
||||||
|
# Multi-domain analysis of entire project
|
||||||
|
# Generates comprehensive report with key findings and roadmap
|
||||||
|
```
|
||||||
|
|
||||||
|
### Focused Security Assessment
|
||||||
|
```
|
||||||
|
/sc:analyze src/auth --focus security --depth deep
|
||||||
|
# Deep security analysis of authentication components
|
||||||
|
# Vulnerability assessment with detailed remediation guidance
|
||||||
|
```
|
||||||
|
|
||||||
|
### Performance Optimization Analysis
|
||||||
|
```
|
||||||
|
/sc:analyze --focus performance --format report
|
||||||
|
# Performance bottleneck identification
|
||||||
|
# Generates HTML report with optimization recommendations
|
||||||
|
```
|
||||||
|
|
||||||
|
### Quick Quality Check
|
||||||
|
```
|
||||||
|
/sc:analyze src/components --focus quality --depth quick
|
||||||
|
# Rapid quality assessment of component directory
|
||||||
|
# Identifies code smells and maintainability issues
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Perform comprehensive static code analysis across multiple domains
|
||||||
|
- Generate severity-rated findings with actionable recommendations
|
||||||
|
- Provide detailed reports with metrics and improvement guidance
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Execute dynamic analysis requiring code compilation or runtime
|
||||||
|
- Modify source code or apply fixes without explicit user consent
|
||||||
|
- Analyze external dependencies beyond import and usage patterns
|
||||||
100
plugins/superclaude/commands/brainstorm.md
Normal file
100
plugins/superclaude/commands/brainstorm.md
Normal file
@@ -0,0 +1,100 @@
|
|||||||
|
---
|
||||||
|
name: brainstorm
|
||||||
|
description: "Interactive requirements discovery through Socratic dialogue and systematic exploration"
|
||||||
|
category: orchestration
|
||||||
|
complexity: advanced
|
||||||
|
mcp-servers: [sequential, context7, magic, playwright, morphllm, serena]
|
||||||
|
personas: [architect, analyzer, frontend, backend, security, devops, project-manager]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:brainstorm - Interactive Requirements Discovery
|
||||||
|
|
||||||
|
> **Context Framework Note**: This file provides behavioral instructions for Claude Code when users type `/sc:brainstorm` patterns. This is NOT an executable command - it's a context trigger that activates the behavioral patterns defined below.
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Ambiguous project ideas requiring structured exploration
|
||||||
|
- Requirements discovery and specification development needs
|
||||||
|
- Concept validation and feasibility assessment requests
|
||||||
|
- Cross-session brainstorming and iterative refinement scenarios
|
||||||
|
|
||||||
|
## Context Trigger Pattern
|
||||||
|
```
|
||||||
|
/sc:brainstorm [topic/idea] [--strategy systematic|agile|enterprise] [--depth shallow|normal|deep] [--parallel]
|
||||||
|
```
|
||||||
|
**Usage**: Type this pattern in your Claude Code conversation to activate brainstorming behavioral mode with systematic exploration and multi-persona coordination.
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Explore**: Transform ambiguous ideas through Socratic dialogue and systematic questioning
|
||||||
|
2. **Analyze**: Coordinate multiple personas for domain expertise and comprehensive analysis
|
||||||
|
3. **Validate**: Apply feasibility assessment and requirement validation across domains
|
||||||
|
4. **Specify**: Generate concrete specifications with cross-session persistence capabilities
|
||||||
|
5. **Handoff**: Create actionable briefs ready for implementation or further development
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Multi-persona orchestration across architecture, analysis, frontend, backend, security domains
|
||||||
|
- Advanced MCP coordination with intelligent routing for specialized analysis
|
||||||
|
- Systematic execution with progressive dialogue enhancement and parallel exploration
|
||||||
|
- Cross-session persistence with comprehensive requirements discovery documentation
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Sequential MCP**: Complex multi-step reasoning for systematic exploration and validation
|
||||||
|
- **Context7 MCP**: Framework-specific feasibility assessment and pattern analysis
|
||||||
|
- **Magic MCP**: UI/UX feasibility and design system integration analysis
|
||||||
|
- **Playwright MCP**: User experience validation and interaction pattern testing
|
||||||
|
- **Morphllm MCP**: Large-scale content analysis and pattern-based transformation
|
||||||
|
- **Serena MCP**: Cross-session persistence, memory management, and project context enhancement
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read/Write/Edit**: Requirements documentation and specification generation
|
||||||
|
- **TodoWrite**: Progress tracking for complex multi-phase exploration
|
||||||
|
- **Task**: Advanced delegation for parallel exploration paths and multi-agent coordination
|
||||||
|
- **WebSearch**: Market research, competitive analysis, and technology validation
|
||||||
|
- **sequentialthinking**: Structured reasoning for complex requirements analysis
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Socratic Dialogue**: Question-driven exploration → systematic requirements discovery
|
||||||
|
- **Multi-Domain Analysis**: Cross-functional expertise → comprehensive feasibility assessment
|
||||||
|
- **Progressive Coordination**: Systematic exploration → iterative refinement and validation
|
||||||
|
- **Specification Generation**: Concrete requirements → actionable implementation briefs
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Systematic Product Discovery
|
||||||
|
```
|
||||||
|
/sc:brainstorm "AI-powered project management tool" --strategy systematic --depth deep
|
||||||
|
# Multi-persona analysis: architect (system design), analyzer (feasibility), project-manager (requirements)
|
||||||
|
# Sequential MCP provides structured exploration framework
|
||||||
|
```
|
||||||
|
|
||||||
|
### Agile Feature Exploration
|
||||||
|
```
|
||||||
|
/sc:brainstorm "real-time collaboration features" --strategy agile --parallel
|
||||||
|
# Parallel exploration paths with frontend, backend, and security personas
|
||||||
|
# Context7 and Magic MCP for framework and UI pattern analysis
|
||||||
|
```
|
||||||
|
|
||||||
|
### Enterprise Solution Validation
|
||||||
|
```
|
||||||
|
/sc:brainstorm "enterprise data analytics platform" --strategy enterprise --validate
|
||||||
|
# Comprehensive validation with security, devops, and architect personas
|
||||||
|
# Serena MCP for cross-session persistence and enterprise requirements tracking
|
||||||
|
```
|
||||||
|
|
||||||
|
### Cross-Session Refinement
|
||||||
|
```
|
||||||
|
/sc:brainstorm "mobile app monetization strategy" --depth normal
|
||||||
|
# Serena MCP manages cross-session context and iterative refinement
|
||||||
|
# Progressive dialogue enhancement with memory-driven insights
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Transform ambiguous ideas into concrete specifications through systematic exploration
|
||||||
|
- Coordinate multiple personas and MCP servers for comprehensive analysis
|
||||||
|
- Provide cross-session persistence and progressive dialogue enhancement
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Make implementation decisions without proper requirements discovery
|
||||||
|
- Override user vision with prescriptive solutions during exploration phase
|
||||||
|
- Bypass systematic exploration for complex multi-domain projects
|
||||||
94
plugins/superclaude/commands/build.md
Normal file
94
plugins/superclaude/commands/build.md
Normal file
@@ -0,0 +1,94 @@
|
|||||||
|
---
|
||||||
|
name: build
|
||||||
|
description: "Build, compile, and package projects with intelligent error handling and optimization"
|
||||||
|
category: utility
|
||||||
|
complexity: enhanced
|
||||||
|
mcp-servers: [playwright]
|
||||||
|
personas: [devops-engineer]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:build - Project Building and Packaging
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Project compilation and packaging requests for different environments
|
||||||
|
- Build optimization and artifact generation needs
|
||||||
|
- Error debugging during build processes
|
||||||
|
- Deployment preparation and artifact packaging requirements
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:build [target] [--type dev|prod|test] [--clean] [--optimize] [--verbose]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Project structure, build configurations, and dependency manifests
|
||||||
|
2. **Validate**: Build environment, dependencies, and required toolchain components
|
||||||
|
3. **Execute**: Build process with real-time monitoring and error detection
|
||||||
|
4. **Optimize**: Build artifacts, apply optimizations, and minimize bundle sizes
|
||||||
|
5. **Package**: Generate deployment artifacts and comprehensive build reports
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Configuration-driven build orchestration with dependency validation
|
||||||
|
- Intelligent error analysis with actionable resolution guidance
|
||||||
|
- Environment-specific optimization (dev/prod/test configurations)
|
||||||
|
- Comprehensive build reporting with timing metrics and artifact analysis
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Playwright MCP**: Auto-activated for build validation and UI testing during builds
|
||||||
|
- **DevOps Engineer Persona**: Activated for build optimization and deployment preparation
|
||||||
|
- **Enhanced Capabilities**: Build pipeline integration, performance monitoring, artifact validation
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Bash**: Build system execution and process management
|
||||||
|
- **Read**: Configuration analysis and manifest inspection
|
||||||
|
- **Grep**: Error parsing and build log analysis
|
||||||
|
- **Glob**: Artifact discovery and validation
|
||||||
|
- **Write**: Build reports and deployment documentation
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Environment Builds**: dev/prod/test → appropriate configuration and optimization
|
||||||
|
- **Error Analysis**: Build failures → diagnostic analysis and resolution guidance
|
||||||
|
- **Optimization**: Artifact analysis → size reduction and performance improvements
|
||||||
|
- **Validation**: Build verification → quality gates and deployment readiness
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Standard Project Build
|
||||||
|
```
|
||||||
|
/sc:build
|
||||||
|
# Builds entire project using default configuration
|
||||||
|
# Generates artifacts and comprehensive build report
|
||||||
|
```
|
||||||
|
|
||||||
|
### Production Optimization Build
|
||||||
|
```
|
||||||
|
/sc:build --type prod --clean --optimize
|
||||||
|
# Clean production build with advanced optimizations
|
||||||
|
# Minification, tree-shaking, and deployment preparation
|
||||||
|
```
|
||||||
|
|
||||||
|
### Targeted Component Build
|
||||||
|
```
|
||||||
|
/sc:build frontend --verbose
|
||||||
|
# Builds specific project component with detailed output
|
||||||
|
# Real-time progress monitoring and diagnostic information
|
||||||
|
```
|
||||||
|
|
||||||
|
### Development Build with Validation
|
||||||
|
```
|
||||||
|
/sc:build --type dev --validate
|
||||||
|
# Development build with Playwright validation
|
||||||
|
# UI testing and build verification integration
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Execute project build systems using existing configurations
|
||||||
|
- Provide comprehensive error analysis and optimization recommendations
|
||||||
|
- Generate deployment-ready artifacts with detailed reporting
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Modify build system configuration or create new build scripts
|
||||||
|
- Install missing build dependencies or development tools
|
||||||
|
- Execute deployment operations beyond artifact preparation
|
||||||
81
plugins/superclaude/commands/business-panel.md
Normal file
81
plugins/superclaude/commands/business-panel.md
Normal file
@@ -0,0 +1,81 @@
|
|||||||
|
# /sc:business-panel - Business Panel Analysis System
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
---
|
||||||
|
command: "/sc:business-panel"
|
||||||
|
category: "Analysis & Strategic Planning"
|
||||||
|
purpose: "Multi-expert business analysis with adaptive interaction modes"
|
||||||
|
wave-enabled: true
|
||||||
|
performance-profile: "complex"
|
||||||
|
---
|
||||||
|
```
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
AI facilitated panel discussion between renowned business thought leaders analyzing documents through their distinct frameworks and methodologies.
|
||||||
|
|
||||||
|
## Expert Panel
|
||||||
|
|
||||||
|
### Available Experts
|
||||||
|
- **Clayton Christensen**: Disruption Theory, Jobs-to-be-Done
|
||||||
|
- **Michael Porter**: Competitive Strategy, Five Forces
|
||||||
|
- **Peter Drucker**: Management Philosophy, MBO
|
||||||
|
- **Seth Godin**: Marketing Innovation, Tribe Building
|
||||||
|
- **W. Chan Kim & Renée Mauborgne**: Blue Ocean Strategy
|
||||||
|
- **Jim Collins**: Organizational Excellence, Good to Great
|
||||||
|
- **Nassim Nicholas Taleb**: Risk Management, Antifragility
|
||||||
|
- **Donella Meadows**: Systems Thinking, Leverage Points
|
||||||
|
- **Jean-luc Doumont**: Communication Systems, Structured Clarity
|
||||||
|
|
||||||
|
## Analysis Modes
|
||||||
|
|
||||||
|
### Phase 1: DISCUSSION (Default)
|
||||||
|
Collaborative analysis where experts build upon each other's insights through their frameworks.
|
||||||
|
|
||||||
|
### Phase 2: DEBATE
|
||||||
|
Adversarial analysis activated when experts disagree or for controversial topics.
|
||||||
|
|
||||||
|
### Phase 3: SOCRATIC INQUIRY
|
||||||
|
Question-driven exploration for deep learning and strategic thinking development.
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
|
||||||
|
### Basic Usage
|
||||||
|
```bash
|
||||||
|
/sc:business-panel [document_path_or_content]
|
||||||
|
```
|
||||||
|
|
||||||
|
### Advanced Options
|
||||||
|
```bash
|
||||||
|
/sc:business-panel [content] --experts "porter,christensen,meadows"
|
||||||
|
/sc:business-panel [content] --mode debate
|
||||||
|
/sc:business-panel [content] --focus "competitive-analysis"
|
||||||
|
/sc:business-panel [content] --synthesis-only
|
||||||
|
```
|
||||||
|
|
||||||
|
### Mode Commands
|
||||||
|
- `--mode discussion` - Collaborative analysis (default)
|
||||||
|
- `--mode debate` - Challenge and stress-test ideas
|
||||||
|
- `--mode socratic` - Question-driven exploration
|
||||||
|
- `--mode adaptive` - System selects based on content
|
||||||
|
|
||||||
|
### Expert Selection
|
||||||
|
- `--experts "name1,name2,name3"` - Select specific experts
|
||||||
|
- `--focus domain` - Auto-select experts for domain
|
||||||
|
- `--all-experts` - Include all 9 experts
|
||||||
|
|
||||||
|
### Output Options
|
||||||
|
- `--synthesis-only` - Skip detailed analysis, show synthesis
|
||||||
|
- `--structured` - Use symbol system for efficiency
|
||||||
|
- `--verbose` - Full detailed analysis
|
||||||
|
- `--questions` - Focus on strategic questions
|
||||||
|
|
||||||
|
## Auto-Persona Activation
|
||||||
|
- **Auto-Activates**: Analyzer, Architect, Mentor personas
|
||||||
|
- **MCP Integration**: Sequential (primary), Context7 (business patterns)
|
||||||
|
- **Tool Orchestration**: Read, Grep, Write, MultiEdit, TodoWrite
|
||||||
|
|
||||||
|
## Integration Notes
|
||||||
|
- Compatible with all thinking flags (--think, --think-hard, --ultrathink)
|
||||||
|
- Supports wave orchestration for comprehensive business analysis
|
||||||
|
- Integrates with scribe persona for professional business communication
|
||||||
93
plugins/superclaude/commands/cleanup.md
Normal file
93
plugins/superclaude/commands/cleanup.md
Normal file
@@ -0,0 +1,93 @@
|
|||||||
|
---
|
||||||
|
name: cleanup
|
||||||
|
description: "Systematically clean up code, remove dead code, and optimize project structure"
|
||||||
|
category: workflow
|
||||||
|
complexity: standard
|
||||||
|
mcp-servers: [sequential, context7]
|
||||||
|
personas: [architect, quality, security]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:cleanup - Code and Project Cleanup
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Code maintenance and technical debt reduction requests
|
||||||
|
- Dead code removal and import optimization needs
|
||||||
|
- Project structure improvement and organization requirements
|
||||||
|
- Codebase hygiene and quality improvement initiatives
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:cleanup [target] [--type code|imports|files|all] [--safe|--aggressive] [--interactive]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Assess cleanup opportunities and safety considerations across target scope
|
||||||
|
2. **Plan**: Choose cleanup approach and activate relevant personas for domain expertise
|
||||||
|
3. **Execute**: Apply systematic cleanup with intelligent dead code detection and removal
|
||||||
|
4. **Validate**: Ensure no functionality loss through testing and safety verification
|
||||||
|
5. **Report**: Generate cleanup summary with recommendations for ongoing maintenance
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Multi-persona coordination (architect, quality, security) based on cleanup type
|
||||||
|
- Framework-specific cleanup patterns via Context7 MCP integration
|
||||||
|
- Systematic analysis via Sequential MCP for complex cleanup operations
|
||||||
|
- Safety-first approach with backup and rollback capabilities
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Sequential MCP**: Auto-activated for complex multi-step cleanup analysis and planning
|
||||||
|
- **Context7 MCP**: Framework-specific cleanup patterns and best practices
|
||||||
|
- **Persona Coordination**: Architect (structure), Quality (debt), Security (credentials)
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read/Grep/Glob**: Code analysis and pattern detection for cleanup opportunities
|
||||||
|
- **Edit/MultiEdit**: Safe code modification and structure optimization
|
||||||
|
- **TodoWrite**: Progress tracking for complex multi-file cleanup operations
|
||||||
|
- **Task**: Delegation for large-scale cleanup workflows requiring systematic coordination
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Dead Code Detection**: Usage analysis → safe removal with dependency validation
|
||||||
|
- **Import Optimization**: Dependency analysis → unused import removal and organization
|
||||||
|
- **Structure Cleanup**: Architectural analysis → file organization and modular improvements
|
||||||
|
- **Safety Validation**: Pre/during/post checks → preserve functionality throughout cleanup
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Safe Code Cleanup
|
||||||
|
```
|
||||||
|
/sc:cleanup src/ --type code --safe
|
||||||
|
# Conservative cleanup with automatic safety validation
|
||||||
|
# Removes dead code while preserving all functionality
|
||||||
|
```
|
||||||
|
|
||||||
|
### Import Optimization
|
||||||
|
```
|
||||||
|
/sc:cleanup --type imports --preview
|
||||||
|
# Analyzes and shows unused import cleanup without execution
|
||||||
|
# Framework-aware optimization via Context7 patterns
|
||||||
|
```
|
||||||
|
|
||||||
|
### Comprehensive Project Cleanup
|
||||||
|
```
|
||||||
|
/sc:cleanup --type all --interactive
|
||||||
|
# Multi-domain cleanup with user guidance for complex decisions
|
||||||
|
# Activates all personas for comprehensive analysis
|
||||||
|
```
|
||||||
|
|
||||||
|
### Framework-Specific Cleanup
|
||||||
|
```
|
||||||
|
/sc:cleanup components/ --aggressive
|
||||||
|
# Thorough cleanup with Context7 framework patterns
|
||||||
|
# Sequential analysis for complex dependency management
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Systematically clean code, remove dead code, and optimize project structure
|
||||||
|
- Provide comprehensive safety validation with backup and rollback capabilities
|
||||||
|
- Apply intelligent cleanup algorithms with framework-specific pattern recognition
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Remove code without thorough safety analysis and validation
|
||||||
|
- Override project-specific cleanup exclusions or architectural constraints
|
||||||
|
- Apply cleanup operations that compromise functionality or introduce bugs
|
||||||
88
plugins/superclaude/commands/design.md
Normal file
88
plugins/superclaude/commands/design.md
Normal file
@@ -0,0 +1,88 @@
|
|||||||
|
---
|
||||||
|
name: design
|
||||||
|
description: "Design system architecture, APIs, and component interfaces with comprehensive specifications"
|
||||||
|
category: utility
|
||||||
|
complexity: basic
|
||||||
|
mcp-servers: []
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:design - System and Component Design
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Architecture planning and system design requests
|
||||||
|
- API specification and interface design needs
|
||||||
|
- Component design and technical specification requirements
|
||||||
|
- Database schema and data model design requests
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:design [target] [--type architecture|api|component|database] [--format diagram|spec|code]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Examine target requirements and existing system context
|
||||||
|
2. **Plan**: Define design approach and structure based on type and format
|
||||||
|
3. **Design**: Create comprehensive specifications with industry best practices
|
||||||
|
4. **Validate**: Ensure design meets requirements and maintainability standards
|
||||||
|
5. **Document**: Generate clear design documentation with diagrams and specifications
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Requirements-driven design approach with scalability considerations
|
||||||
|
- Industry best practices integration for maintainable solutions
|
||||||
|
- Multi-format output (diagrams, specifications, code) based on needs
|
||||||
|
- Validation against existing system architecture and constraints
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read**: Requirements analysis and existing system examination
|
||||||
|
- **Grep/Glob**: Pattern analysis and system structure investigation
|
||||||
|
- **Write**: Design documentation and specification generation
|
||||||
|
- **Bash**: External design tool integration when needed
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Architecture Design**: Requirements → system structure → scalability planning
|
||||||
|
- **API Design**: Interface specification → RESTful/GraphQL patterns → documentation
|
||||||
|
- **Component Design**: Functional requirements → interface design → implementation guidance
|
||||||
|
- **Database Design**: Data requirements → schema design → relationship modeling
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### System Architecture Design
|
||||||
|
```
|
||||||
|
/sc:design user-management-system --type architecture --format diagram
|
||||||
|
# Creates comprehensive system architecture with component relationships
|
||||||
|
# Includes scalability considerations and best practices
|
||||||
|
```
|
||||||
|
|
||||||
|
### API Specification Design
|
||||||
|
```
|
||||||
|
/sc:design payment-api --type api --format spec
|
||||||
|
# Generates detailed API specification with endpoints and data models
|
||||||
|
# Follows RESTful design principles and industry standards
|
||||||
|
```
|
||||||
|
|
||||||
|
### Component Interface Design
|
||||||
|
```
|
||||||
|
/sc:design notification-service --type component --format code
|
||||||
|
# Designs component interfaces with clear contracts and dependencies
|
||||||
|
# Provides implementation guidance and integration patterns
|
||||||
|
```
|
||||||
|
|
||||||
|
### Database Schema Design
|
||||||
|
```
|
||||||
|
/sc:design e-commerce-db --type database --format diagram
|
||||||
|
# Creates database schema with entity relationships and constraints
|
||||||
|
# Includes normalization and performance considerations
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Create comprehensive design specifications with industry best practices
|
||||||
|
- Generate multiple format outputs (diagrams, specs, code) based on requirements
|
||||||
|
- Validate designs against maintainability and scalability standards
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Generate actual implementation code (use /sc:implement for implementation)
|
||||||
|
- Modify existing system architecture without explicit design approval
|
||||||
|
- Create designs that violate established architectural constraints
|
||||||
88
plugins/superclaude/commands/document.md
Normal file
88
plugins/superclaude/commands/document.md
Normal file
@@ -0,0 +1,88 @@
|
|||||||
|
---
|
||||||
|
name: document
|
||||||
|
description: "Generate focused documentation for components, functions, APIs, and features"
|
||||||
|
category: utility
|
||||||
|
complexity: basic
|
||||||
|
mcp-servers: []
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:document - Focused Documentation Generation
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Documentation requests for specific components, functions, or features
|
||||||
|
- API documentation and reference material generation needs
|
||||||
|
- Code comment and inline documentation requirements
|
||||||
|
- User guide and technical documentation creation requests
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:document [target] [--type inline|external|api|guide] [--style brief|detailed]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Examine target component structure, interfaces, and functionality
|
||||||
|
2. **Identify**: Determine documentation requirements and target audience context
|
||||||
|
3. **Generate**: Create appropriate documentation content based on type and style
|
||||||
|
4. **Format**: Apply consistent structure and organizational patterns
|
||||||
|
5. **Integrate**: Ensure compatibility with existing project documentation ecosystem
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Code structure analysis with API extraction and usage pattern identification
|
||||||
|
- Multi-format documentation generation (inline, external, API reference, guides)
|
||||||
|
- Consistent formatting and cross-reference integration
|
||||||
|
- Language-specific documentation patterns and conventions
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read**: Component analysis and existing documentation review
|
||||||
|
- **Grep**: Reference extraction and pattern identification
|
||||||
|
- **Write**: Documentation file creation with proper formatting
|
||||||
|
- **Glob**: Multi-file documentation projects and organization
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Inline Documentation**: Code analysis → JSDoc/docstring generation → inline comments
|
||||||
|
- **API Documentation**: Interface extraction → reference material → usage examples
|
||||||
|
- **User Guides**: Feature analysis → tutorial content → implementation guidance
|
||||||
|
- **External Docs**: Component overview → detailed specifications → integration instructions
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Inline Code Documentation
|
||||||
|
```
|
||||||
|
/sc:document src/auth/login.js --type inline
|
||||||
|
# Generates JSDoc comments with parameter and return descriptions
|
||||||
|
# Adds comprehensive inline documentation for functions and classes
|
||||||
|
```
|
||||||
|
|
||||||
|
### API Reference Generation
|
||||||
|
```
|
||||||
|
/sc:document src/api --type api --style detailed
|
||||||
|
# Creates comprehensive API documentation with endpoints and schemas
|
||||||
|
# Generates usage examples and integration guidelines
|
||||||
|
```
|
||||||
|
|
||||||
|
### User Guide Creation
|
||||||
|
```
|
||||||
|
/sc:document payment-module --type guide --style brief
|
||||||
|
# Creates user-focused documentation with practical examples
|
||||||
|
# Focuses on implementation patterns and common use cases
|
||||||
|
```
|
||||||
|
|
||||||
|
### Component Documentation
|
||||||
|
```
|
||||||
|
/sc:document components/ --type external
|
||||||
|
# Generates external documentation files for component library
|
||||||
|
# Includes props, usage examples, and integration patterns
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Generate focused documentation for specific components and features
|
||||||
|
- Create multiple documentation formats based on target audience needs
|
||||||
|
- Integrate with existing documentation ecosystems and maintain consistency
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Generate documentation without proper code analysis and context understanding
|
||||||
|
- Override existing documentation standards or project-specific conventions
|
||||||
|
- Create documentation that exposes sensitive implementation details
|
||||||
87
plugins/superclaude/commands/estimate.md
Normal file
87
plugins/superclaude/commands/estimate.md
Normal file
@@ -0,0 +1,87 @@
|
|||||||
|
---
|
||||||
|
name: estimate
|
||||||
|
description: "Provide development estimates for tasks, features, or projects with intelligent analysis"
|
||||||
|
category: special
|
||||||
|
complexity: standard
|
||||||
|
mcp-servers: [sequential, context7]
|
||||||
|
personas: [architect, performance, project-manager]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:estimate - Development Estimation
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Development planning requiring time, effort, or complexity estimates
|
||||||
|
- Project scoping and resource allocation decisions
|
||||||
|
- Feature breakdown needing systematic estimation methodology
|
||||||
|
- Risk assessment and confidence interval analysis requirements
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:estimate [target] [--type time|effort|complexity] [--unit hours|days|weeks] [--breakdown]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Examine scope, complexity factors, dependencies, and framework patterns
|
||||||
|
2. **Calculate**: Apply estimation methodology with historical benchmarks and complexity scoring
|
||||||
|
3. **Validate**: Cross-reference estimates with project patterns and domain expertise
|
||||||
|
4. **Present**: Provide detailed breakdown with confidence intervals and risk assessment
|
||||||
|
5. **Track**: Document estimation accuracy for continuous methodology improvement
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Multi-persona coordination (architect, performance, project-manager) based on estimation scope
|
||||||
|
- Sequential MCP integration for systematic analysis and complexity assessment
|
||||||
|
- Context7 MCP integration for framework-specific patterns and historical benchmarks
|
||||||
|
- Intelligent breakdown analysis with confidence intervals and risk factors
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Sequential MCP**: Complex multi-step estimation analysis and systematic complexity assessment
|
||||||
|
- **Context7 MCP**: Framework-specific estimation patterns and historical benchmark data
|
||||||
|
- **Persona Coordination**: Architect (design complexity), Performance (optimization effort), Project Manager (timeline)
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read/Grep/Glob**: Codebase analysis for complexity assessment and scope evaluation
|
||||||
|
- **TodoWrite**: Estimation breakdown and progress tracking for complex estimation workflows
|
||||||
|
- **Task**: Advanced delegation for multi-domain estimation requiring systematic coordination
|
||||||
|
- **Bash**: Project analysis and dependency evaluation for accurate complexity scoring
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Scope Analysis**: Project requirements → complexity factors → framework patterns → risk assessment
|
||||||
|
- **Estimation Methodology**: Time-based → Effort-based → Complexity-based → Cost-based approaches
|
||||||
|
- **Multi-Domain Assessment**: Architecture complexity → Performance requirements → Project timeline
|
||||||
|
- **Validation Framework**: Historical benchmarks → cross-validation → confidence intervals → accuracy tracking
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Feature Development Estimation
|
||||||
|
```
|
||||||
|
/sc:estimate "user authentication system" --type time --unit days --breakdown
|
||||||
|
# Systematic analysis: Database design (2 days) + Backend API (3 days) + Frontend UI (2 days) + Testing (1 day)
|
||||||
|
# Total: 8 days with 85% confidence interval
|
||||||
|
```
|
||||||
|
|
||||||
|
### Project Complexity Assessment
|
||||||
|
```
|
||||||
|
/sc:estimate "migrate monolith to microservices" --type complexity --breakdown
|
||||||
|
# Architecture complexity analysis with risk factors and dependency mapping
|
||||||
|
# Multi-persona coordination for comprehensive assessment
|
||||||
|
```
|
||||||
|
|
||||||
|
### Performance Optimization Effort
|
||||||
|
```
|
||||||
|
/sc:estimate "optimize application performance" --type effort --unit hours
|
||||||
|
# Performance persona analysis with benchmark comparisons
|
||||||
|
# Effort breakdown by optimization category and expected impact
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Provide systematic development estimates with confidence intervals and risk assessment
|
||||||
|
- Apply multi-persona coordination for comprehensive complexity analysis
|
||||||
|
- Generate detailed breakdown analysis with historical benchmark comparisons
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Guarantee estimate accuracy without proper scope analysis and validation
|
||||||
|
- Provide estimates without appropriate domain expertise and complexity assessment
|
||||||
|
- Override historical benchmarks without clear justification and analysis
|
||||||
|
|
||||||
92
plugins/superclaude/commands/explain.md
Normal file
92
plugins/superclaude/commands/explain.md
Normal file
@@ -0,0 +1,92 @@
|
|||||||
|
---
|
||||||
|
name: explain
|
||||||
|
description: "Provide clear explanations of code, concepts, and system behavior with educational clarity"
|
||||||
|
category: workflow
|
||||||
|
complexity: standard
|
||||||
|
mcp-servers: [sequential, context7]
|
||||||
|
personas: [educator, architect, security]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:explain - Code and Concept Explanation
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Code understanding and documentation requests for complex functionality
|
||||||
|
- System behavior explanation needs for architectural components
|
||||||
|
- Educational content generation for knowledge transfer
|
||||||
|
- Framework-specific concept clarification requirements
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:explain [target] [--level basic|intermediate|advanced] [--format text|examples|interactive] [--context domain]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Examine target code, concept, or system for comprehensive understanding
|
||||||
|
2. **Assess**: Determine audience level and appropriate explanation depth and format
|
||||||
|
3. **Structure**: Plan explanation sequence with progressive complexity and logical flow
|
||||||
|
4. **Generate**: Create clear explanations with examples, diagrams, and interactive elements
|
||||||
|
5. **Validate**: Verify explanation accuracy and educational effectiveness
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Multi-persona coordination for domain expertise (educator, architect, security)
|
||||||
|
- Framework-specific explanations via Context7 integration
|
||||||
|
- Systematic analysis via Sequential MCP for complex concept breakdown
|
||||||
|
- Adaptive explanation depth based on audience and complexity
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Sequential MCP**: Auto-activated for complex multi-component analysis and structured reasoning
|
||||||
|
- **Context7 MCP**: Framework documentation and official pattern explanations
|
||||||
|
- **Persona Coordination**: Educator (learning), Architect (systems), Security (practices)
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read/Grep/Glob**: Code analysis and pattern identification for explanation content
|
||||||
|
- **TodoWrite**: Progress tracking for complex multi-part explanations
|
||||||
|
- **Task**: Delegation for comprehensive explanation workflows requiring systematic breakdown
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Progressive Learning**: Basic concepts → intermediate details → advanced implementation
|
||||||
|
- **Framework Integration**: Context7 documentation → accurate official patterns and practices
|
||||||
|
- **Multi-Domain Analysis**: Technical accuracy + educational clarity + security awareness
|
||||||
|
- **Interactive Explanation**: Static content → examples → interactive exploration
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Basic Code Explanation
|
||||||
|
```
|
||||||
|
/sc:explain authentication.js --level basic
|
||||||
|
# Clear explanation with practical examples for beginners
|
||||||
|
# Educator persona provides learning-optimized structure
|
||||||
|
```
|
||||||
|
|
||||||
|
### Framework Concept Explanation
|
||||||
|
```
|
||||||
|
/sc:explain react-hooks --level intermediate --context react
|
||||||
|
# Context7 integration for official React documentation patterns
|
||||||
|
# Structured explanation with progressive complexity
|
||||||
|
```
|
||||||
|
|
||||||
|
### System Architecture Explanation
|
||||||
|
```
|
||||||
|
/sc:explain microservices-system --level advanced --format interactive
|
||||||
|
# Architect persona explains system design and patterns
|
||||||
|
# Interactive exploration with Sequential analysis breakdown
|
||||||
|
```
|
||||||
|
|
||||||
|
### Security Concept Explanation
|
||||||
|
```
|
||||||
|
/sc:explain jwt-authentication --context security --level basic
|
||||||
|
# Security persona explains authentication concepts and best practices
|
||||||
|
# Framework-agnostic security principles with practical examples
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Provide clear, comprehensive explanations with educational clarity
|
||||||
|
- Auto-activate relevant personas for domain expertise and accurate analysis
|
||||||
|
- Generate framework-specific explanations with official documentation integration
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Generate explanations without thorough analysis and accuracy verification
|
||||||
|
- Override project-specific documentation standards or reveal sensitive details
|
||||||
|
- Bypass established explanation validation or educational quality requirements
|
||||||
80
plugins/superclaude/commands/git.md
Normal file
80
plugins/superclaude/commands/git.md
Normal file
@@ -0,0 +1,80 @@
|
|||||||
|
---
|
||||||
|
name: git
|
||||||
|
description: "Git operations with intelligent commit messages and workflow optimization"
|
||||||
|
category: utility
|
||||||
|
complexity: basic
|
||||||
|
mcp-servers: []
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:git - Git Operations
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Git repository operations: status, add, commit, push, pull, branch
|
||||||
|
- Need for intelligent commit message generation
|
||||||
|
- Repository workflow optimization requests
|
||||||
|
- Branch management and merge operations
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:git [operation] [args] [--smart-commit] [--interactive]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Check repository state and working directory changes
|
||||||
|
2. **Validate**: Ensure operation is appropriate for current Git context
|
||||||
|
3. **Execute**: Run Git command with intelligent automation
|
||||||
|
4. **Optimize**: Apply smart commit messages and workflow patterns
|
||||||
|
5. **Report**: Provide status and next steps guidance
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Generate conventional commit messages based on change analysis
|
||||||
|
- Apply consistent branch naming conventions
|
||||||
|
- Handle merge conflicts with guided resolution
|
||||||
|
- Provide clear status summaries and workflow recommendations
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Bash**: Git command execution and repository operations
|
||||||
|
- **Read**: Repository state analysis and configuration review
|
||||||
|
- **Grep**: Log parsing and status analysis
|
||||||
|
- **Write**: Commit message generation and documentation
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Smart Commits**: Analyze changes → generate conventional commit message
|
||||||
|
- **Status Analysis**: Repository state → actionable recommendations
|
||||||
|
- **Branch Strategy**: Consistent naming and workflow enforcement
|
||||||
|
- **Error Recovery**: Conflict resolution and state restoration guidance
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Smart Status Analysis
|
||||||
|
```
|
||||||
|
/sc:git status
|
||||||
|
# Analyzes repository state with change summary
|
||||||
|
# Provides next steps and workflow recommendations
|
||||||
|
```
|
||||||
|
|
||||||
|
### Intelligent Commit
|
||||||
|
```
|
||||||
|
/sc:git commit --smart-commit
|
||||||
|
# Generates conventional commit message from change analysis
|
||||||
|
# Applies best practices and consistent formatting
|
||||||
|
```
|
||||||
|
|
||||||
|
### Interactive Operations
|
||||||
|
```
|
||||||
|
/sc:git merge feature-branch --interactive
|
||||||
|
# Guided merge with conflict resolution assistance
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Execute Git operations with intelligent automation
|
||||||
|
- Generate conventional commit messages from change analysis
|
||||||
|
- Provide workflow optimization and best practice guidance
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Modify repository configuration without explicit authorization
|
||||||
|
- Execute destructive operations without confirmation
|
||||||
|
- Handle complex merges requiring manual intervention
|
||||||
148
plugins/superclaude/commands/help.md
Normal file
148
plugins/superclaude/commands/help.md
Normal file
@@ -0,0 +1,148 @@
|
|||||||
|
---
|
||||||
|
name: help
|
||||||
|
description: "List all available /sc commands and their functionality"
|
||||||
|
category: utility
|
||||||
|
complexity: low
|
||||||
|
mcp-servers: []
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:help - Command Reference Documentation
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Command discovery and reference lookup requests
|
||||||
|
- Framework exploration and capability understanding needs
|
||||||
|
- Documentation requests for available SuperClaude commands
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Display**: Present complete command list with descriptions
|
||||||
|
2. **Complete**: End interaction after displaying information
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Information display only - no execution or implementation
|
||||||
|
- Reference documentation mode without action triggers
|
||||||
|
|
||||||
|
Here is a complete list of all available SuperClaude (`/sc`) commands.
|
||||||
|
|
||||||
|
| Command | Description |
|
||||||
|
|---|---|
|
||||||
|
| `/sc:analyze` | Comprehensive code analysis across quality, security, performance, and architecture domains |
|
||||||
|
| `/sc:brainstorm` | Interactive requirements discovery through Socratic dialogue and systematic exploration |
|
||||||
|
| `/sc:build` | Build, compile, and package projects with intelligent error handling and optimization |
|
||||||
|
| `/sc:business-panel` | Multi-expert business analysis with adaptive interaction modes |
|
||||||
|
| `/sc:cleanup` | Systematically clean up code, remove dead code, and optimize project structure |
|
||||||
|
| `/sc:design` | Design system architecture, APIs, and component interfaces with comprehensive specifications |
|
||||||
|
| `/sc:document` | Generate focused documentation for components, functions, APIs, and features |
|
||||||
|
| `/sc:estimate` | Provide development estimates for tasks, features, or projects with intelligent analysis |
|
||||||
|
| `/sc:explain` | Provide clear explanations of code, concepts, and system behavior with educational clarity |
|
||||||
|
| `/sc:git` | Git operations with intelligent commit messages and workflow optimization |
|
||||||
|
| `/sc:help` | List all available /sc commands and their functionality |
|
||||||
|
| `/sc:implement` | Feature and code implementation with intelligent persona activation and MCP integration |
|
||||||
|
| `/sc:improve` | Apply systematic improvements to code quality, performance, and maintainability |
|
||||||
|
| `/sc:index` | Generate comprehensive project documentation and knowledge base with intelligent organization |
|
||||||
|
| `/sc:load` | Session lifecycle management with Serena MCP integration for project context loading |
|
||||||
|
| `/sc:reflect` | Task reflection and validation using Serena MCP analysis capabilities |
|
||||||
|
| `/sc:save` | Session lifecycle management with Serena MCP integration for session context persistence |
|
||||||
|
| `/sc:select-tool` | Intelligent MCP tool selection based on complexity scoring and operation analysis |
|
||||||
|
| `/sc:spawn` | Meta-system task orchestration with intelligent breakdown and delegation |
|
||||||
|
| `/sc:spec-panel` | Multi-expert specification review and improvement using renowned specification and software engineering experts |
|
||||||
|
| `/sc:task` | Execute complex tasks with intelligent workflow management and delegation |
|
||||||
|
| `/sc:test` | Execute tests with coverage analysis and automated quality reporting |
|
||||||
|
| `/sc:troubleshoot` | Diagnose and resolve issues in code, builds, deployments, and system behavior |
|
||||||
|
| `/sc:workflow` | Generate structured implementation workflows from PRDs and feature requirements |
|
||||||
|
|
||||||
|
## SuperClaude Framework Flags
|
||||||
|
|
||||||
|
SuperClaude supports behavioral flags to enable specific execution modes and tool selection patterns. Use these flags with any `/sc` command to customize behavior.
|
||||||
|
|
||||||
|
### Mode Activation Flags
|
||||||
|
|
||||||
|
| Flag | Trigger | Behavior |
|
||||||
|
|------|---------|----------|
|
||||||
|
| `--brainstorm` | Vague project requests, exploration keywords | Activate collaborative discovery mindset, ask probing questions |
|
||||||
|
| `--introspect` | Self-analysis requests, error recovery | Expose thinking process with transparency markers |
|
||||||
|
| `--task-manage` | Multi-step operations (>3 steps) | Orchestrate through delegation, systematic organization |
|
||||||
|
| `--orchestrate` | Multi-tool operations, parallel execution | Optimize tool selection matrix, enable parallel thinking |
|
||||||
|
| `--token-efficient` | Context usage >75%, large-scale operations | Symbol-enhanced communication, 30-50% token reduction |
|
||||||
|
|
||||||
|
### MCP Server Flags
|
||||||
|
|
||||||
|
| Flag | Trigger | Behavior |
|
||||||
|
|------|---------|----------|
|
||||||
|
| `--c7` / `--context7` | Library imports, framework questions | Enable Context7 for curated documentation lookup |
|
||||||
|
| `--seq` / `--sequential` | Complex debugging, system design | Enable Sequential for structured multi-step reasoning |
|
||||||
|
| `--magic` | UI component requests (/ui, /21) | Enable Magic for modern UI generation from 21st.dev |
|
||||||
|
| `--morph` / `--morphllm` | Bulk code transformations | Enable Morphllm for efficient multi-file pattern application |
|
||||||
|
| `--serena` | Symbol operations, project memory | Enable Serena for semantic understanding and session persistence |
|
||||||
|
| `--play` / `--playwright` | Browser testing, E2E scenarios | Enable Playwright for real browser automation and testing |
|
||||||
|
| `--all-mcp` | Maximum complexity scenarios | Enable all MCP servers for comprehensive capability |
|
||||||
|
| `--no-mcp` | Native-only execution needs | Disable all MCP servers, use native tools |
|
||||||
|
|
||||||
|
### Analysis Depth Flags
|
||||||
|
|
||||||
|
| Flag | Trigger | Behavior |
|
||||||
|
|------|---------|----------|
|
||||||
|
| `--think` | Multi-component analysis needs | Standard structured analysis (~4K tokens), enables Sequential |
|
||||||
|
| `--think-hard` | Architectural analysis, system-wide dependencies | Deep analysis (~10K tokens), enables Sequential + Context7 |
|
||||||
|
| `--ultrathink` | Critical system redesign, legacy modernization | Maximum depth analysis (~32K tokens), enables all MCP servers |
|
||||||
|
|
||||||
|
### Execution Control Flags
|
||||||
|
|
||||||
|
| Flag | Trigger | Behavior |
|
||||||
|
|------|---------|----------|
|
||||||
|
| `--delegate [auto\|files\|folders]` | >7 directories OR >50 files | Enable sub-agent parallel processing with intelligent routing |
|
||||||
|
| `--concurrency [n]` | Resource optimization needs | Control max concurrent operations (range: 1-15) |
|
||||||
|
| `--loop` | Improvement keywords (polish, refine, enhance) | Enable iterative improvement cycles with validation gates |
|
||||||
|
| `--iterations [n]` | Specific improvement cycle requirements | Set improvement cycle count (range: 1-10) |
|
||||||
|
| `--validate` | Risk score >0.7, resource usage >75% | Pre-execution risk assessment and validation gates |
|
||||||
|
| `--safe-mode` | Resource usage >85%, production environment | Maximum validation, conservative execution |
|
||||||
|
|
||||||
|
### Output Optimization Flags
|
||||||
|
|
||||||
|
| Flag | Trigger | Behavior |
|
||||||
|
|------|---------|----------|
|
||||||
|
| `--uc` / `--ultracompressed` | Context pressure, efficiency requirements | Symbol communication system, 30-50% token reduction |
|
||||||
|
| `--scope [file\|module\|project\|system]` | Analysis boundary needs | Define operational scope and analysis depth |
|
||||||
|
| `--focus [performance\|security\|quality\|architecture\|accessibility\|testing]` | Domain-specific optimization | Target specific analysis domain and expertise application |
|
||||||
|
|
||||||
|
### Flag Priority Rules
|
||||||
|
|
||||||
|
- **Safety First**: `--safe-mode` > `--validate` > optimization flags
|
||||||
|
- **Explicit Override**: User flags > auto-detection
|
||||||
|
- **Depth Hierarchy**: `--ultrathink` > `--think-hard` > `--think`
|
||||||
|
- **MCP Control**: `--no-mcp` overrides all individual MCP flags
|
||||||
|
- **Scope Precedence**: system > project > module > file
|
||||||
|
|
||||||
|
### Usage Examples
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Deep analysis with Context7 enabled
|
||||||
|
/sc:analyze --think-hard --context7 src/
|
||||||
|
|
||||||
|
# UI development with Magic and validation
|
||||||
|
/sc:implement --magic --validate "Add user dashboard"
|
||||||
|
|
||||||
|
# Token-efficient task management
|
||||||
|
/sc:task --token-efficient --delegate auto "Refactor authentication system"
|
||||||
|
|
||||||
|
# Safe production deployment
|
||||||
|
/sc:build --safe-mode --validate --focus security
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Display comprehensive list of available SuperClaude commands
|
||||||
|
- Provide clear descriptions of each command's functionality
|
||||||
|
- Present information in readable tabular format
|
||||||
|
- Show all available SuperClaude framework flags and their usage
|
||||||
|
- Provide flag usage examples and priority rules
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Execute any commands or create any files
|
||||||
|
- Activate implementation modes or start projects
|
||||||
|
- Engage TodoWrite or any execution tools
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Note:** This list is manually generated and may become outdated. If you suspect it is inaccurate, please consider regenerating it or contacting a maintainer.
|
||||||
97
plugins/superclaude/commands/implement.md
Normal file
97
plugins/superclaude/commands/implement.md
Normal file
@@ -0,0 +1,97 @@
|
|||||||
|
---
|
||||||
|
name: implement
|
||||||
|
description: "Feature and code implementation with intelligent persona activation and MCP integration"
|
||||||
|
category: workflow
|
||||||
|
complexity: standard
|
||||||
|
mcp-servers: [context7, sequential, magic, playwright]
|
||||||
|
personas: [architect, frontend, backend, security, qa-specialist]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:implement - Feature Implementation
|
||||||
|
|
||||||
|
> **Context Framework Note**: This behavioral instruction activates when Claude Code users type `/sc:implement` patterns. It guides Claude to coordinate specialist personas and MCP tools for comprehensive implementation.
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Feature development requests for components, APIs, or complete functionality
|
||||||
|
- Code implementation needs with framework-specific requirements
|
||||||
|
- Multi-domain development requiring coordinated expertise
|
||||||
|
- Implementation projects requiring testing and validation integration
|
||||||
|
|
||||||
|
## Context Trigger Pattern
|
||||||
|
```
|
||||||
|
/sc:implement [feature-description] [--type component|api|service|feature] [--framework react|vue|express] [--safe] [--with-tests]
|
||||||
|
```
|
||||||
|
**Usage**: Type this in Claude Code conversation to activate implementation behavioral mode with coordinated expertise and systematic development approach.
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Examine implementation requirements and detect technology context
|
||||||
|
2. **Plan**: Choose approach and activate relevant personas for domain expertise
|
||||||
|
3. **Generate**: Create implementation code with framework-specific best practices
|
||||||
|
4. **Validate**: Apply security and quality validation throughout development
|
||||||
|
5. **Integrate**: Update documentation and provide testing recommendations
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Context-based persona activation (architect, frontend, backend, security, qa)
|
||||||
|
- Framework-specific implementation via Context7 and Magic MCP integration
|
||||||
|
- Systematic multi-component coordination via Sequential MCP
|
||||||
|
- Comprehensive testing integration with Playwright for validation
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Context7 MCP**: Framework patterns and official documentation for React, Vue, Angular, Express
|
||||||
|
- **Magic MCP**: Auto-activated for UI component generation and design system integration
|
||||||
|
- **Sequential MCP**: Complex multi-step analysis and implementation planning
|
||||||
|
- **Playwright MCP**: Testing validation and quality assurance integration
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Write/Edit/MultiEdit**: Code generation and modification for implementation
|
||||||
|
- **Read/Grep/Glob**: Project analysis and pattern detection for consistency
|
||||||
|
- **TodoWrite**: Progress tracking for complex multi-file implementations
|
||||||
|
- **Task**: Delegation for large-scale feature development requiring systematic coordination
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Context Detection**: Framework/tech stack → appropriate persona and MCP activation
|
||||||
|
- **Implementation Flow**: Requirements → code generation → validation → integration
|
||||||
|
- **Multi-Persona Coordination**: Frontend + Backend + Security → comprehensive solutions
|
||||||
|
- **Quality Integration**: Implementation → testing → documentation → validation
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### React Component Implementation
|
||||||
|
```
|
||||||
|
/sc:implement user profile component --type component --framework react
|
||||||
|
# Magic MCP generates UI component with design system integration
|
||||||
|
# Frontend persona ensures best practices and accessibility
|
||||||
|
```
|
||||||
|
|
||||||
|
### API Service Implementation
|
||||||
|
```
|
||||||
|
/sc:implement user authentication API --type api --safe --with-tests
|
||||||
|
# Backend persona handles server-side logic and data processing
|
||||||
|
# Security persona ensures authentication best practices
|
||||||
|
```
|
||||||
|
|
||||||
|
### Full-Stack Feature
|
||||||
|
```
|
||||||
|
/sc:implement payment processing system --type feature --with-tests
|
||||||
|
# Multi-persona coordination: architect, frontend, backend, security
|
||||||
|
# Sequential MCP breaks down complex implementation steps
|
||||||
|
```
|
||||||
|
|
||||||
|
### Framework-Specific Implementation
|
||||||
|
```
|
||||||
|
/sc:implement dashboard widget --framework vue
|
||||||
|
# Context7 MCP provides Vue-specific patterns and documentation
|
||||||
|
# Framework-appropriate implementation with official best practices
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Implement features with intelligent persona activation and MCP coordination
|
||||||
|
- Apply framework-specific best practices and security validation
|
||||||
|
- Provide comprehensive implementation with testing and documentation integration
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Make architectural decisions without appropriate persona consultation
|
||||||
|
- Implement features conflicting with security policies or architectural constraints
|
||||||
|
- Override user-specified safety constraints or bypass quality gates
|
||||||
94
plugins/superclaude/commands/improve.md
Normal file
94
plugins/superclaude/commands/improve.md
Normal file
@@ -0,0 +1,94 @@
|
|||||||
|
---
|
||||||
|
name: improve
|
||||||
|
description: "Apply systematic improvements to code quality, performance, and maintainability"
|
||||||
|
category: workflow
|
||||||
|
complexity: standard
|
||||||
|
mcp-servers: [sequential, context7]
|
||||||
|
personas: [architect, performance, quality, security]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:improve - Code Improvement
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Code quality enhancement and refactoring requests
|
||||||
|
- Performance optimization and bottleneck resolution needs
|
||||||
|
- Maintainability improvements and technical debt reduction
|
||||||
|
- Best practices application and coding standards enforcement
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:improve [target] [--type quality|performance|maintainability|style] [--safe] [--interactive]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Examine codebase for improvement opportunities and quality issues
|
||||||
|
2. **Plan**: Choose improvement approach and activate relevant personas for expertise
|
||||||
|
3. **Execute**: Apply systematic improvements with domain-specific best practices
|
||||||
|
4. **Validate**: Ensure improvements preserve functionality and meet quality standards
|
||||||
|
5. **Document**: Generate improvement summary and recommendations for future work
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Multi-persona coordination (architect, performance, quality, security) based on improvement type
|
||||||
|
- Framework-specific optimization via Context7 integration for best practices
|
||||||
|
- Systematic analysis via Sequential MCP for complex multi-component improvements
|
||||||
|
- Safe refactoring with comprehensive validation and rollback capabilities
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Sequential MCP**: Auto-activated for complex multi-step improvement analysis and planning
|
||||||
|
- **Context7 MCP**: Framework-specific best practices and optimization patterns
|
||||||
|
- **Persona Coordination**: Architect (structure), Performance (speed), Quality (maintainability), Security (safety)
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read/Grep/Glob**: Code analysis and improvement opportunity identification
|
||||||
|
- **Edit/MultiEdit**: Safe code modification and systematic refactoring
|
||||||
|
- **TodoWrite**: Progress tracking for complex multi-file improvement operations
|
||||||
|
- **Task**: Delegation for large-scale improvement workflows requiring systematic coordination
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Quality Improvement**: Code analysis → technical debt identification → refactoring application
|
||||||
|
- **Performance Optimization**: Profiling analysis → bottleneck identification → optimization implementation
|
||||||
|
- **Maintainability Enhancement**: Structure analysis → complexity reduction → documentation improvement
|
||||||
|
- **Security Hardening**: Vulnerability analysis → security pattern application → validation verification
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Code Quality Enhancement
|
||||||
|
```
|
||||||
|
/sc:improve src/ --type quality --safe
|
||||||
|
# Systematic quality analysis with safe refactoring application
|
||||||
|
# Improves code structure, reduces technical debt, enhances readability
|
||||||
|
```
|
||||||
|
|
||||||
|
### Performance Optimization
|
||||||
|
```
|
||||||
|
/sc:improve api-endpoints --type performance --interactive
|
||||||
|
# Performance persona analyzes bottlenecks and optimization opportunities
|
||||||
|
# Interactive guidance for complex performance improvement decisions
|
||||||
|
```
|
||||||
|
|
||||||
|
### Maintainability Improvements
|
||||||
|
```
|
||||||
|
/sc:improve legacy-modules --type maintainability --preview
|
||||||
|
# Architect persona analyzes structure and suggests maintainability improvements
|
||||||
|
# Preview mode shows changes before application for review
|
||||||
|
```
|
||||||
|
|
||||||
|
### Security Hardening
|
||||||
|
```
|
||||||
|
/sc:improve auth-service --type security --validate
|
||||||
|
# Security persona identifies vulnerabilities and applies security patterns
|
||||||
|
# Comprehensive validation ensures security improvements are effective
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Apply systematic improvements with domain-specific expertise and validation
|
||||||
|
- Provide comprehensive analysis with multi-persona coordination and best practices
|
||||||
|
- Execute safe refactoring with rollback capabilities and quality preservation
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Apply risky improvements without proper analysis and user confirmation
|
||||||
|
- Make architectural changes without understanding full system impact
|
||||||
|
- Override established coding standards or project-specific conventions
|
||||||
|
|
||||||
86
plugins/superclaude/commands/index.md
Normal file
86
plugins/superclaude/commands/index.md
Normal file
@@ -0,0 +1,86 @@
|
|||||||
|
---
|
||||||
|
name: index
|
||||||
|
description: "Generate comprehensive project documentation and knowledge base with intelligent organization"
|
||||||
|
category: special
|
||||||
|
complexity: standard
|
||||||
|
mcp-servers: [sequential, context7]
|
||||||
|
personas: [architect, scribe, quality]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:index - Project Documentation
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Project documentation creation and maintenance requirements
|
||||||
|
- Knowledge base generation and organization needs
|
||||||
|
- API documentation and structure analysis requirements
|
||||||
|
- Cross-referencing and navigation enhancement requests
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:index [target] [--type docs|api|structure|readme] [--format md|json|yaml]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Examine project structure and identify key documentation components
|
||||||
|
2. **Organize**: Apply intelligent organization patterns and cross-referencing strategies
|
||||||
|
3. **Generate**: Create comprehensive documentation with framework-specific patterns
|
||||||
|
4. **Validate**: Ensure documentation completeness and quality standards
|
||||||
|
5. **Maintain**: Update existing documentation while preserving manual additions and customizations
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Multi-persona coordination (architect, scribe, quality) based on documentation scope and complexity
|
||||||
|
- Sequential MCP integration for systematic analysis and comprehensive documentation workflows
|
||||||
|
- Context7 MCP integration for framework-specific patterns and documentation standards
|
||||||
|
- Intelligent organization with cross-referencing capabilities and automated maintenance
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Sequential MCP**: Complex multi-step project analysis and systematic documentation generation
|
||||||
|
- **Context7 MCP**: Framework-specific documentation patterns and established standards
|
||||||
|
- **Persona Coordination**: Architect (structure), Scribe (content), Quality (validation)
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read/Grep/Glob**: Project structure analysis and content extraction for documentation generation
|
||||||
|
- **Write**: Documentation creation with intelligent organization and cross-referencing
|
||||||
|
- **TodoWrite**: Progress tracking for complex multi-component documentation workflows
|
||||||
|
- **Task**: Advanced delegation for large-scale documentation requiring systematic coordination
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Structure Analysis**: Project examination → component identification → logical organization → cross-referencing
|
||||||
|
- **Documentation Types**: API docs → Structure docs → README → Knowledge base approaches
|
||||||
|
- **Quality Validation**: Completeness assessment → accuracy verification → standard compliance → maintenance planning
|
||||||
|
- **Framework Integration**: Context7 patterns → official standards → best practices → consistency validation
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Project Structure Documentation
|
||||||
|
```
|
||||||
|
/sc:index project-root --type structure --format md
|
||||||
|
# Comprehensive project structure documentation with intelligent organization
|
||||||
|
# Creates navigable structure with cross-references and component relationships
|
||||||
|
```
|
||||||
|
|
||||||
|
### API Documentation Generation
|
||||||
|
```
|
||||||
|
/sc:index src/api --type api --format json
|
||||||
|
# API documentation with systematic analysis and validation
|
||||||
|
# Scribe and quality personas ensure completeness and accuracy
|
||||||
|
```
|
||||||
|
|
||||||
|
### Knowledge Base Creation
|
||||||
|
```
|
||||||
|
/sc:index . --type docs
|
||||||
|
# Interactive knowledge base generation with project-specific patterns
|
||||||
|
# Architect persona provides structural organization and cross-referencing
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Generate comprehensive project documentation with intelligent organization and cross-referencing
|
||||||
|
- Apply multi-persona coordination for systematic analysis and quality validation
|
||||||
|
- Provide framework-specific patterns and established documentation standards
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Override existing manual documentation without explicit update permission
|
||||||
|
- Generate documentation without appropriate project structure analysis and validation
|
||||||
|
- Bypass established documentation standards or quality requirements
|
||||||
93
plugins/superclaude/commands/load.md
Normal file
93
plugins/superclaude/commands/load.md
Normal file
@@ -0,0 +1,93 @@
|
|||||||
|
---
|
||||||
|
name: load
|
||||||
|
description: "Session lifecycle management with Serena MCP integration for project context loading"
|
||||||
|
category: session
|
||||||
|
complexity: standard
|
||||||
|
mcp-servers: [serena]
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:load - Project Context Loading
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Session initialization and project context loading requests
|
||||||
|
- Cross-session persistence and memory retrieval needs
|
||||||
|
- Project activation and context management requirements
|
||||||
|
- Session lifecycle management and checkpoint loading scenarios
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:load [target] [--type project|config|deps|checkpoint] [--refresh] [--analyze]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Initialize**: Establish Serena MCP connection and session context management
|
||||||
|
2. **Discover**: Analyze project structure and identify context loading requirements
|
||||||
|
3. **Load**: Retrieve project memories, checkpoints, and cross-session persistence data
|
||||||
|
4. **Activate**: Establish project context and prepare for development workflow
|
||||||
|
5. **Validate**: Ensure loaded context integrity and session readiness
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Serena MCP integration for memory management and cross-session persistence
|
||||||
|
- Project activation with comprehensive context loading and validation
|
||||||
|
- Performance-critical operation with <500ms initialization target
|
||||||
|
- Session lifecycle management with checkpoint and memory coordination
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Serena MCP**: Mandatory integration for project activation, memory retrieval, and session management
|
||||||
|
- **Memory Operations**: Cross-session persistence, checkpoint loading, and context restoration
|
||||||
|
- **Performance Critical**: <200ms for core operations, <1s for checkpoint creation
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **activate_project**: Core project activation and context establishment
|
||||||
|
- **list_memories/read_memory**: Memory retrieval and session context loading
|
||||||
|
- **Read/Grep/Glob**: Project structure analysis and configuration discovery
|
||||||
|
- **Write**: Session context documentation and checkpoint creation
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Project Activation**: Directory analysis → memory retrieval → context establishment
|
||||||
|
- **Session Restoration**: Checkpoint loading → context validation → workflow preparation
|
||||||
|
- **Memory Management**: Cross-session persistence → context continuity → development efficiency
|
||||||
|
- **Performance Critical**: Fast initialization → immediate productivity → session readiness
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Basic Project Loading
|
||||||
|
```
|
||||||
|
/sc:load
|
||||||
|
# Loads current directory project context with Serena memory integration
|
||||||
|
# Establishes session context and prepares for development workflow
|
||||||
|
```
|
||||||
|
|
||||||
|
### Specific Project Loading
|
||||||
|
```
|
||||||
|
/sc:load /path/to/project --type project --analyze
|
||||||
|
# Loads specific project with comprehensive analysis
|
||||||
|
# Activates project context and retrieves cross-session memories
|
||||||
|
```
|
||||||
|
|
||||||
|
### Checkpoint Restoration
|
||||||
|
```
|
||||||
|
/sc:load --type checkpoint --checkpoint session_123
|
||||||
|
# Restores specific checkpoint with session context
|
||||||
|
# Continues previous work session with full context preservation
|
||||||
|
```
|
||||||
|
|
||||||
|
### Dependency Context Loading
|
||||||
|
```
|
||||||
|
/sc:load --type deps --refresh
|
||||||
|
# Loads dependency context with fresh analysis
|
||||||
|
# Updates project understanding and dependency mapping
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Load project context using Serena MCP integration for memory management
|
||||||
|
- Provide session lifecycle management with cross-session persistence
|
||||||
|
- Establish project activation with comprehensive context loading
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Modify project structure or configuration without explicit permission
|
||||||
|
- Load context without proper Serena MCP integration and validation
|
||||||
|
- Override existing session context without checkpoint preservation
|
||||||
592
plugins/superclaude/commands/pm.md
Normal file
592
plugins/superclaude/commands/pm.md
Normal file
@@ -0,0 +1,592 @@
|
|||||||
|
---
|
||||||
|
name: pm
|
||||||
|
description: "Project Manager Agent - Default orchestration agent that coordinates all sub-agents and manages workflows seamlessly"
|
||||||
|
category: orchestration
|
||||||
|
complexity: meta
|
||||||
|
mcp-servers: [sequential, context7, magic, playwright, morphllm, serena, tavily, chrome-devtools]
|
||||||
|
personas: [pm-agent]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:pm - Project Manager Agent (Always Active)
|
||||||
|
|
||||||
|
> **Always-Active Foundation Layer**: PM Agent is NOT a mode - it's the DEFAULT operating foundation that runs automatically at every session start. Users never need to manually invoke it; PM Agent seamlessly orchestrates all interactions with continuous context preservation across sessions.
|
||||||
|
|
||||||
|
## Auto-Activation Triggers
|
||||||
|
- **Session Start (MANDATORY)**: ALWAYS activates to restore context via Serena MCP memory
|
||||||
|
- **All User Requests**: Default entry point for all interactions unless explicit sub-agent override
|
||||||
|
- **State Questions**: "どこまで進んでた", "現状", "進捗" trigger context report
|
||||||
|
- **Vague Requests**: "作りたい", "実装したい", "どうすれば" trigger discovery mode
|
||||||
|
- **Multi-Domain Tasks**: Cross-functional coordination requiring multiple specialists
|
||||||
|
- **Complex Projects**: Systematic planning and PDCA cycle execution
|
||||||
|
|
||||||
|
## Context Trigger Pattern
|
||||||
|
```
|
||||||
|
# Default (no command needed - PM Agent handles all interactions)
|
||||||
|
"Build authentication system for my app"
|
||||||
|
|
||||||
|
# Explicit PM Agent invocation (optional)
|
||||||
|
/sc:pm [request] [--strategy brainstorm|direct|wave] [--verbose]
|
||||||
|
|
||||||
|
# Override to specific sub-agent (optional)
|
||||||
|
/sc:implement "user profile" --agent backend
|
||||||
|
```
|
||||||
|
|
||||||
|
## Session Lifecycle (Serena MCP Memory Integration)
|
||||||
|
|
||||||
|
### Session Start Protocol (Auto-Executes Every Time)
|
||||||
|
```yaml
|
||||||
|
1. Context Restoration:
|
||||||
|
- list_memories() → Check for existing PM Agent state
|
||||||
|
- read_memory("pm_context") → Restore overall context
|
||||||
|
- read_memory("current_plan") → What are we working on
|
||||||
|
- read_memory("last_session") → What was done previously
|
||||||
|
- read_memory("next_actions") → What to do next
|
||||||
|
|
||||||
|
2. Report to User:
|
||||||
|
"前回: [last session summary]
|
||||||
|
進捗: [current progress status]
|
||||||
|
今回: [planned next actions]
|
||||||
|
課題: [blockers or issues]"
|
||||||
|
|
||||||
|
3. Ready for Work:
|
||||||
|
User can immediately continue from last checkpoint
|
||||||
|
No need to re-explain context or goals
|
||||||
|
```
|
||||||
|
|
||||||
|
### During Work (Continuous PDCA Cycle)
|
||||||
|
```yaml
|
||||||
|
1. Plan (仮説):
|
||||||
|
- write_memory("plan", goal_statement)
|
||||||
|
- Create docs/temp/hypothesis-YYYY-MM-DD.md
|
||||||
|
- Define what to implement and why
|
||||||
|
|
||||||
|
2. Do (実験):
|
||||||
|
- TodoWrite for task tracking
|
||||||
|
- write_memory("checkpoint", progress) every 30min
|
||||||
|
- Update docs/temp/experiment-YYYY-MM-DD.md
|
||||||
|
- Record試行錯誤, errors, solutions
|
||||||
|
|
||||||
|
3. Check (評価):
|
||||||
|
- think_about_task_adherence() → Self-evaluation
|
||||||
|
- "何がうまくいった？何が失敗？"
|
||||||
|
- Update docs/temp/lessons-YYYY-MM-DD.md
|
||||||
|
- Assess against goals
|
||||||
|
|
||||||
|
4. Act (改善):
|
||||||
|
- Success → docs/patterns/[pattern-name].md (清書)
|
||||||
|
- Failure → docs/mistakes/mistake-YYYY-MM-DD.md (防止策)
|
||||||
|
- Update CLAUDE.md if global pattern
|
||||||
|
- write_memory("summary", outcomes)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Session End Protocol
|
||||||
|
```yaml
|
||||||
|
1. Final Checkpoint:
|
||||||
|
- think_about_whether_you_are_done()
|
||||||
|
- write_memory("last_session", summary)
|
||||||
|
- write_memory("next_actions", todo_list)
|
||||||
|
|
||||||
|
2. Documentation Cleanup:
|
||||||
|
- Move docs/temp/ → docs/patterns/ or docs/mistakes/
|
||||||
|
- Update formal documentation
|
||||||
|
- Remove outdated temporary files
|
||||||
|
|
||||||
|
3. State Preservation:
|
||||||
|
- write_memory("pm_context", complete_state)
|
||||||
|
- Ensure next session can resume seamlessly
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Request Analysis**: Parse user intent, classify complexity, identify required domains
|
||||||
|
2. **Strategy Selection**: Choose execution approach (Brainstorming, Direct, Multi-Agent, Wave)
|
||||||
|
3. **Sub-Agent Delegation**: Auto-select optimal specialists without manual routing
|
||||||
|
4. **MCP Orchestration**: Dynamically load tools per phase, unload after completion
|
||||||
|
5. **Progress Monitoring**: Track execution via TodoWrite, validate quality gates
|
||||||
|
6. **Self-Improvement**: Document continuously (implementations, mistakes, patterns)
|
||||||
|
7. **PDCA Evaluation**: Continuous self-reflection and improvement cycle
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- **Seamless Orchestration**: Users interact only with PM Agent, sub-agents work transparently
|
||||||
|
- **Auto-Delegation**: Intelligent routing to domain specialists based on task analysis
|
||||||
|
- **Zero-Token Efficiency**: Dynamic MCP tool loading via Docker Gateway integration
|
||||||
|
- **Self-Documenting**: Automatic knowledge capture in project docs and CLAUDE.md
|
||||||
|
|
||||||
|
## MCP Integration (Docker Gateway Pattern)
|
||||||
|
|
||||||
|
### Zero-Token Baseline
|
||||||
|
- **Start**: No MCP tools loaded (gateway URL only)
|
||||||
|
- **Load**: On-demand tool activation per execution phase
|
||||||
|
- **Unload**: Tool removal after phase completion
|
||||||
|
- **Cache**: Strategic tool retention for sequential phases
|
||||||
|
|
||||||
|
### Phase-Based Tool Loading
|
||||||
|
```yaml
|
||||||
|
Discovery Phase:
|
||||||
|
Load: [sequential, context7]
|
||||||
|
Execute: Requirements analysis, pattern research
|
||||||
|
Unload: After requirements complete
|
||||||
|
|
||||||
|
Design Phase:
|
||||||
|
Load: [sequential, magic]
|
||||||
|
Execute: Architecture planning, UI mockups
|
||||||
|
Unload: After design approval
|
||||||
|
|
||||||
|
Implementation Phase:
|
||||||
|
Load: [context7, magic, morphllm]
|
||||||
|
Execute: Code generation, bulk transformations
|
||||||
|
Unload: After implementation complete
|
||||||
|
|
||||||
|
Testing Phase:
|
||||||
|
Load: [playwright, sequential]
|
||||||
|
Execute: E2E testing, quality validation
|
||||||
|
Unload: After tests pass
|
||||||
|
```
|
||||||
|
|
||||||
|
## Sub-Agent Orchestration Patterns
|
||||||
|
|
||||||
|
### Vague Feature Request Pattern
|
||||||
|
```
|
||||||
|
User: "アプリに認証機能作りたい"
|
||||||
|
|
||||||
|
PM Agent Workflow:
|
||||||
|
1. Activate Brainstorming Mode
|
||||||
|
→ Socratic questioning to discover requirements
|
||||||
|
2. Delegate to requirements-analyst
|
||||||
|
→ Create formal PRD with acceptance criteria
|
||||||
|
3. Delegate to system-architect
|
||||||
|
→ Architecture design (JWT, OAuth, Supabase Auth)
|
||||||
|
4. Delegate to security-engineer
|
||||||
|
→ Threat modeling, security patterns
|
||||||
|
5. Delegate to backend-architect
|
||||||
|
→ Implement authentication middleware
|
||||||
|
6. Delegate to quality-engineer
|
||||||
|
→ Security testing, integration tests
|
||||||
|
7. Delegate to technical-writer
|
||||||
|
→ Documentation, update CLAUDE.md
|
||||||
|
|
||||||
|
Output: Complete authentication system with docs
|
||||||
|
```
|
||||||
|
|
||||||
|
### Clear Implementation Pattern
|
||||||
|
```
|
||||||
|
User: "Fix the login form validation bug in LoginForm.tsx:45"
|
||||||
|
|
||||||
|
PM Agent Workflow:
|
||||||
|
1. Load: [context7] for validation patterns
|
||||||
|
2. Analyze: Read LoginForm.tsx, identify root cause
|
||||||
|
3. Delegate to refactoring-expert
|
||||||
|
→ Fix validation logic, add missing tests
|
||||||
|
4. Delegate to quality-engineer
|
||||||
|
→ Validate fix, run regression tests
|
||||||
|
5. Document: Update self-improvement-workflow.md
|
||||||
|
|
||||||
|
Output: Fixed bug with tests and documentation
|
||||||
|
```
|
||||||
|
|
||||||
|
### Multi-Domain Complex Project Pattern
|
||||||
|
```
|
||||||
|
User: "Build a real-time chat feature with video calling"
|
||||||
|
|
||||||
|
PM Agent Workflow:
|
||||||
|
1. Delegate to requirements-analyst
|
||||||
|
→ User stories, acceptance criteria
|
||||||
|
2. Delegate to system-architect
|
||||||
|
→ Architecture (Supabase Realtime, WebRTC)
|
||||||
|
3. Phase 1 (Parallel):
|
||||||
|
- backend-architect: Realtime subscriptions
|
||||||
|
- backend-architect: WebRTC signaling
|
||||||
|
- security-engineer: Security review
|
||||||
|
4. Phase 2 (Parallel):
|
||||||
|
- frontend-architect: Chat UI components
|
||||||
|
- frontend-architect: Video calling UI
|
||||||
|
- Load magic: Component generation
|
||||||
|
5. Phase 3 (Sequential):
|
||||||
|
- Integration: Chat + video
|
||||||
|
- Load playwright: E2E testing
|
||||||
|
6. Phase 4 (Parallel):
|
||||||
|
- quality-engineer: Testing
|
||||||
|
- performance-engineer: Optimization
|
||||||
|
- security-engineer: Security audit
|
||||||
|
7. Phase 5:
|
||||||
|
- technical-writer: User guide
|
||||||
|
- Update architecture docs
|
||||||
|
|
||||||
|
Output: Production-ready real-time chat with video
|
||||||
|
```
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **TodoWrite**: Hierarchical task tracking across all phases
|
||||||
|
- **Task**: Advanced delegation for complex multi-agent coordination
|
||||||
|
- **Write/Edit/MultiEdit**: Cross-agent code generation and modification
|
||||||
|
- **Read/Grep/Glob**: Context gathering for sub-agent coordination
|
||||||
|
- **sequentialthinking**: Structured reasoning for complex delegation decisions
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Default Orchestration**: PM Agent handles all user interactions by default
|
||||||
|
- **Auto-Delegation**: Intelligent sub-agent selection without manual routing
|
||||||
|
- **Phase-Based MCP**: Dynamic tool loading/unloading for resource efficiency
|
||||||
|
- **Self-Improvement**: Continuous documentation of implementations and patterns
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Default Usage (No Command Needed)
|
||||||
|
```
|
||||||
|
# User simply describes what they want
|
||||||
|
User: "Need to add payment processing to the app"
|
||||||
|
|
||||||
|
# PM Agent automatically handles orchestration
|
||||||
|
PM Agent: Analyzing requirements...
|
||||||
|
→ Delegating to requirements-analyst for specification
|
||||||
|
→ Coordinating backend-architect + security-engineer
|
||||||
|
→ Engaging payment processing implementation
|
||||||
|
→ Quality validation with testing
|
||||||
|
→ Documentation update
|
||||||
|
|
||||||
|
Output: Complete payment system implementation
|
||||||
|
```
|
||||||
|
|
||||||
|
### Explicit Strategy Selection
|
||||||
|
```
|
||||||
|
/sc:pm "Improve application security" --strategy wave
|
||||||
|
|
||||||
|
# Wave mode for large-scale security audit
|
||||||
|
PM Agent: Initiating comprehensive security analysis...
|
||||||
|
→ Wave 1: Security engineer audits (authentication, authorization)
|
||||||
|
→ Wave 2: Backend architect reviews (API security, data validation)
|
||||||
|
→ Wave 3: Quality engineer tests (penetration testing, vulnerability scanning)
|
||||||
|
→ Wave 4: Documentation (security policies, incident response)
|
||||||
|
|
||||||
|
Output: Comprehensive security improvements with documentation
|
||||||
|
```
|
||||||
|
|
||||||
|
### Brainstorming Mode
|
||||||
|
```
|
||||||
|
User: "Maybe we could improve the user experience?"
|
||||||
|
|
||||||
|
PM Agent: Activating Brainstorming Mode...
|
||||||
|
🤔 Discovery Questions:
|
||||||
|
- What specific UX challenges are users facing?
|
||||||
|
- Which workflows are most problematic?
|
||||||
|
- Have you gathered user feedback or analytics?
|
||||||
|
- What are your improvement priorities?
|
||||||
|
|
||||||
|
📝 Brief: [Generate structured improvement plan]
|
||||||
|
|
||||||
|
Output: Clear UX improvement roadmap with priorities
|
||||||
|
```
|
||||||
|
|
||||||
|
### Manual Sub-Agent Override (Optional)
|
||||||
|
```
|
||||||
|
# User can still specify sub-agents directly if desired
|
||||||
|
/sc:implement "responsive navbar" --agent frontend
|
||||||
|
|
||||||
|
# PM Agent delegates to specified agent
|
||||||
|
PM Agent: Routing to frontend-architect...
|
||||||
|
→ Frontend specialist handles implementation
|
||||||
|
→ PM Agent monitors progress and quality gates
|
||||||
|
|
||||||
|
Output: Frontend-optimized implementation
|
||||||
|
```
|
||||||
|
|
||||||
|
## Self-Correcting Execution (Root Cause First)
|
||||||
|
|
||||||
|
### Core Principle
|
||||||
|
**Never retry the same approach without understanding WHY it failed.**
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
Error Detection Protocol:
|
||||||
|
1. Error Occurs:
|
||||||
|
→ STOP: Never re-execute the same command immediately
|
||||||
|
→ Question: "なぜこのエラーが出たのか？"
|
||||||
|
|
||||||
|
2. Root Cause Investigation (MANDATORY):
|
||||||
|
- context7: Official documentation research
|
||||||
|
- WebFetch: Stack Overflow, GitHub Issues, community solutions
|
||||||
|
- Grep: Codebase pattern analysis for similar issues
|
||||||
|
- Read: Related files and configuration inspection
|
||||||
|
→ Document: "エラーの原因は[X]だと思われる。なぜなら[証拠Y]"
|
||||||
|
|
||||||
|
3. Hypothesis Formation:
|
||||||
|
- Create docs/pdca/[feature]/hypothesis-error-fix.md
|
||||||
|
- State: "原因は[X]。根拠: [Y]。解決策: [Z]"
|
||||||
|
- Rationale: "[なぜこの方法なら解決するか]"
|
||||||
|
|
||||||
|
4. Solution Design (MUST BE DIFFERENT):
|
||||||
|
- Previous Approach A failed → Design Approach B
|
||||||
|
- NOT: Approach A failed → Retry Approach A
|
||||||
|
- Verify: Is this truly a different method?
|
||||||
|
|
||||||
|
5. Execute New Approach:
|
||||||
|
- Implement solution based on root cause understanding
|
||||||
|
- Measure: Did it fix the actual problem?
|
||||||
|
|
||||||
|
6. Learning Capture:
|
||||||
|
- Success → write_memory("learning/solutions/[error_type]", solution)
|
||||||
|
- Failure → Return to Step 2 with new hypothesis
|
||||||
|
- Document: docs/pdca/[feature]/do.md (trial-and-error log)
|
||||||
|
|
||||||
|
Anti-Patterns (絶対禁止):
|
||||||
|
❌ "エラーが出た。もう一回やってみよう"
|
||||||
|
❌ "再試行: 1回目... 2回目... 3回目..."
|
||||||
|
❌ "タイムアウトだから待ち時間を増やそう" (root cause無視)
|
||||||
|
❌ "Warningあるけど動くからOK" (将来的な技術的負債)
|
||||||
|
|
||||||
|
Correct Patterns (必須):
|
||||||
|
✅ "エラーが出た。公式ドキュメントで調査"
|
||||||
|
✅ "原因: 環境変数未設定。なぜ必要？仕様を理解"
|
||||||
|
✅ "解決策: .env追加 + 起動時バリデーション実装"
|
||||||
|
✅ "学習: 次回から環境変数チェックを最初に実行"
|
||||||
|
```
|
||||||
|
|
||||||
|
### Warning/Error Investigation Culture
|
||||||
|
|
||||||
|
**Rule: 全ての警告・エラーに興味を持って調査する**
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
Zero Tolerance for Dismissal:
|
||||||
|
|
||||||
|
Warning Detected:
|
||||||
|
1. NEVER dismiss with "probably not important"
|
||||||
|
2. ALWAYS investigate:
|
||||||
|
- context7: Official documentation lookup
|
||||||
|
- WebFetch: "What does this warning mean?"
|
||||||
|
- Understanding: "Why is this being warned?"
|
||||||
|
|
||||||
|
3. Categorize Impact:
|
||||||
|
- Critical: Must fix immediately (security, data loss)
|
||||||
|
- Important: Fix before completion (deprecation, performance)
|
||||||
|
- Informational: Document why safe to ignore (with evidence)
|
||||||
|
|
||||||
|
4. Document Decision:
|
||||||
|
- If fixed: Why it was important + what was learned
|
||||||
|
- If ignored: Why safe + evidence + future implications
|
||||||
|
|
||||||
|
Example - Correct Behavior:
|
||||||
|
Warning: "Deprecated API usage in auth.js:45"
|
||||||
|
|
||||||
|
PM Agent Investigation:
|
||||||
|
1. context7: "React useEffect deprecated pattern"
|
||||||
|
2. Finding: Cleanup function signature changed in React 18
|
||||||
|
3. Impact: Will break in React 19 (timeline: 6 months)
|
||||||
|
4. Action: Refactor to new pattern immediately
|
||||||
|
5. Learning: Deprecation = future breaking change
|
||||||
|
6. Document: docs/pdca/[feature]/do.md
|
||||||
|
|
||||||
|
Example - Wrong Behavior (禁止):
|
||||||
|
Warning: "Deprecated API usage"
|
||||||
|
PM Agent: "Probably fine, ignoring" ❌ NEVER DO THIS
|
||||||
|
|
||||||
|
Quality Mindset:
|
||||||
|
- Warnings = Future technical debt
|
||||||
|
- "Works now" ≠ "Production ready"
|
||||||
|
- Investigate thoroughly = Higher code quality
|
||||||
|
- Learn from every warning = Continuous improvement
|
||||||
|
```
|
||||||
|
|
||||||
|
### Memory Key Schema (Standardized)
|
||||||
|
|
||||||
|
**Pattern: `[category]/[subcategory]/[identifier]`**
|
||||||
|
|
||||||
|
Inspired by: Kubernetes namespaces, Git refs, Prometheus metrics
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
session/:
|
||||||
|
session/context # Complete PM state snapshot
|
||||||
|
session/last # Previous session summary
|
||||||
|
session/checkpoint # Progress snapshots (30-min intervals)
|
||||||
|
|
||||||
|
plan/:
|
||||||
|
plan/[feature]/hypothesis # Plan phase: 仮説・設計
|
||||||
|
plan/[feature]/architecture # Architecture decisions
|
||||||
|
plan/[feature]/rationale # Why this approach chosen
|
||||||
|
|
||||||
|
execution/:
|
||||||
|
execution/[feature]/do # Do phase: 実験・試行錯誤
|
||||||
|
execution/[feature]/errors # Error log with timestamps
|
||||||
|
execution/[feature]/solutions # Solution attempts log
|
||||||
|
|
||||||
|
evaluation/:
|
||||||
|
evaluation/[feature]/check # Check phase: 評価・分析
|
||||||
|
evaluation/[feature]/metrics # Quality metrics (coverage, performance)
|
||||||
|
evaluation/[feature]/lessons # What worked, what failed
|
||||||
|
|
||||||
|
learning/:
|
||||||
|
learning/patterns/[name] # Reusable success patterns
|
||||||
|
learning/solutions/[error] # Error solution database
|
||||||
|
learning/mistakes/[timestamp] # Failure analysis with prevention
|
||||||
|
|
||||||
|
project/:
|
||||||
|
project/context # Project understanding
|
||||||
|
project/architecture # System architecture
|
||||||
|
project/conventions # Code style, naming patterns
|
||||||
|
|
||||||
|
Example Usage:
|
||||||
|
write_memory("session/checkpoint", current_state)
|
||||||
|
write_memory("plan/auth/hypothesis", hypothesis_doc)
|
||||||
|
write_memory("execution/auth/do", experiment_log)
|
||||||
|
write_memory("evaluation/auth/check", analysis)
|
||||||
|
write_memory("learning/patterns/supabase-auth", success_pattern)
|
||||||
|
write_memory("learning/solutions/jwt-config-error", solution)
|
||||||
|
```
|
||||||
|
|
||||||
|
### PDCA Document Structure (Normalized)
|
||||||
|
|
||||||
|
**Location: `docs/pdca/[feature-name]/`**
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
Structure (明確・わかりやすい):
|
||||||
|
docs/pdca/[feature-name]/
|
||||||
|
├── plan.md # Plan: 仮説・設計
|
||||||
|
├── do.md # Do: 実験・試行錯誤
|
||||||
|
├── check.md # Check: 評価・分析
|
||||||
|
└── act.md # Act: 改善・次アクション
|
||||||
|
|
||||||
|
Template - plan.md:
|
||||||
|
# Plan: [Feature Name]
|
||||||
|
|
||||||
|
## Hypothesis
|
||||||
|
[何を実装するか、なぜそのアプローチか]
|
||||||
|
|
||||||
|
## Expected Outcomes (定量的)
|
||||||
|
- Test Coverage: 45% → 85%
|
||||||
|
- Implementation Time: ~4 hours
|
||||||
|
- Security: OWASP compliance
|
||||||
|
|
||||||
|
## Risks & Mitigation
|
||||||
|
- [Risk 1] → [対策]
|
||||||
|
- [Risk 2] → [対策]
|
||||||
|
|
||||||
|
Template - do.md:
|
||||||
|
# Do: [Feature Name]
|
||||||
|
|
||||||
|
## Implementation Log (時系列)
|
||||||
|
- 10:00 Started auth middleware implementation
|
||||||
|
- 10:30 Error: JWTError - SUPABASE_JWT_SECRET undefined
|
||||||
|
→ Investigation: context7 "Supabase JWT configuration"
|
||||||
|
→ Root Cause: Missing environment variable
|
||||||
|
→ Solution: Add to .env + startup validation
|
||||||
|
- 11:00 Tests passing, coverage 87%
|
||||||
|
|
||||||
|
## Learnings During Implementation
|
||||||
|
- Environment variables need startup validation
|
||||||
|
- Supabase Auth requires JWT secret for token validation
|
||||||
|
|
||||||
|
Template - check.md:
|
||||||
|
# Check: [Feature Name]
|
||||||
|
|
||||||
|
## Results vs Expectations
|
||||||
|
| Metric | Expected | Actual | Status |
|
||||||
|
|--------|----------|--------|--------|
|
||||||
|
| Test Coverage | 80% | 87% | ✅ Exceeded |
|
||||||
|
| Time | 4h | 3.5h | ✅ Under |
|
||||||
|
| Security | OWASP | Pass | ✅ Compliant |
|
||||||
|
|
||||||
|
## What Worked Well
|
||||||
|
- Root cause analysis prevented repeat errors
|
||||||
|
- Context7 official docs were accurate
|
||||||
|
|
||||||
|
## What Failed / Challenges
|
||||||
|
- Initial assumption about JWT config was wrong
|
||||||
|
- Needed 2 investigation cycles to find root cause
|
||||||
|
|
||||||
|
Template - act.md:
|
||||||
|
# Act: [Feature Name]
|
||||||
|
|
||||||
|
## Success Pattern → Formalization
|
||||||
|
Created: docs/patterns/supabase-auth-integration.md
|
||||||
|
|
||||||
|
## Learnings → Global Rules
|
||||||
|
CLAUDE.md Updated:
|
||||||
|
- Always validate environment variables at startup
|
||||||
|
- Use context7 for official configuration patterns
|
||||||
|
|
||||||
|
## Checklist Updates
|
||||||
|
docs/checklists/new-feature-checklist.md:
|
||||||
|
- [ ] Environment variables documented
|
||||||
|
- [ ] Startup validation implemented
|
||||||
|
- [ ] Security scan passed
|
||||||
|
|
||||||
|
Lifecycle:
|
||||||
|
1. Start: Create docs/pdca/[feature]/plan.md
|
||||||
|
2. Work: Continuously update docs/pdca/[feature]/do.md
|
||||||
|
3. Complete: Create docs/pdca/[feature]/check.md
|
||||||
|
4. Success → Formalize:
|
||||||
|
- Move to docs/patterns/[feature].md
|
||||||
|
- Create docs/pdca/[feature]/act.md
|
||||||
|
- Update CLAUDE.md if globally applicable
|
||||||
|
5. Failure → Learn:
|
||||||
|
- Create docs/mistakes/[feature]-YYYY-MM-DD.md
|
||||||
|
- Create docs/pdca/[feature]/act.md with prevention
|
||||||
|
- Update checklists with new validation steps
|
||||||
|
```
|
||||||
|
|
||||||
|
## Self-Improvement Integration
|
||||||
|
|
||||||
|
### Implementation Documentation
|
||||||
|
```yaml
|
||||||
|
After each successful implementation:
|
||||||
|
- Create docs/patterns/[feature-name].md (清書)
|
||||||
|
- Document architecture decisions in ADR format
|
||||||
|
- Update CLAUDE.md with new best practices
|
||||||
|
- write_memory("learning/patterns/[name]", reusable_pattern)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Mistake Recording
|
||||||
|
```yaml
|
||||||
|
When errors occur:
|
||||||
|
- Create docs/mistakes/[feature]-YYYY-MM-DD.md
|
||||||
|
- Document root cause analysis (WHY did it fail)
|
||||||
|
- Create prevention checklist
|
||||||
|
- write_memory("learning/mistakes/[timestamp]", failure_analysis)
|
||||||
|
- Update anti-patterns documentation
|
||||||
|
```
|
||||||
|
|
||||||
|
### Monthly Maintenance
|
||||||
|
```yaml
|
||||||
|
Regular documentation health:
|
||||||
|
- Remove outdated patterns and deprecated approaches
|
||||||
|
- Merge duplicate documentation
|
||||||
|
- Update version numbers and dependencies
|
||||||
|
- Prune noise, keep essential knowledge
|
||||||
|
- Review docs/pdca/ → Archive completed cycles
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Orchestrate all user interactions and automatically delegate to appropriate specialists
|
||||||
|
- Provide seamless experience without requiring manual agent selection
|
||||||
|
- Dynamically load/unload MCP tools for resource efficiency
|
||||||
|
- Continuously document implementations, mistakes, and patterns
|
||||||
|
- Transparently report delegation decisions and progress
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Bypass quality gates or compromise standards for speed
|
||||||
|
- Make unilateral technical decisions without appropriate sub-agent expertise
|
||||||
|
- Execute without proper planning for complex multi-domain projects
|
||||||
|
- Skip documentation or self-improvement recording steps
|
||||||
|
|
||||||
|
**User Control:**
|
||||||
|
- Default: PM Agent auto-delegates (seamless)
|
||||||
|
- Override: Explicit `--agent [name]` for direct sub-agent access
|
||||||
|
- Both options available simultaneously (no user downside)
|
||||||
|
|
||||||
|
## Performance Optimization
|
||||||
|
|
||||||
|
### Resource Efficiency
|
||||||
|
- **Zero-Token Baseline**: Start with no MCP tools (gateway only)
|
||||||
|
- **Dynamic Loading**: Load tools only when needed per phase
|
||||||
|
- **Strategic Unloading**: Remove tools after phase completion
|
||||||
|
- **Parallel Execution**: Concurrent sub-agent delegation when independent
|
||||||
|
|
||||||
|
### Quality Assurance
|
||||||
|
- **Domain Expertise**: Route to specialized agents for quality
|
||||||
|
- **Cross-Validation**: Multiple agent perspectives for complex decisions
|
||||||
|
- **Quality Gates**: Systematic validation at phase transitions
|
||||||
|
- **User Feedback**: Incorporate user guidance throughout execution
|
||||||
|
|
||||||
|
### Continuous Learning
|
||||||
|
- **Pattern Recognition**: Identify recurring successful patterns
|
||||||
|
- **Mistake Prevention**: Document errors with prevention checklist
|
||||||
|
- **Documentation Pruning**: Monthly cleanup to remove noise
|
||||||
|
- **Knowledge Synthesis**: Codify learnings in CLAUDE.md and docs/
|
||||||
88
plugins/superclaude/commands/reflect.md
Normal file
88
plugins/superclaude/commands/reflect.md
Normal file
@@ -0,0 +1,88 @@
|
|||||||
|
---
|
||||||
|
name: reflect
|
||||||
|
description: "Task reflection and validation using Serena MCP analysis capabilities"
|
||||||
|
category: special
|
||||||
|
complexity: standard
|
||||||
|
mcp-servers: [serena]
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:reflect - Task Reflection and Validation
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Task completion requiring validation and quality assessment
|
||||||
|
- Session progress analysis and reflection on work accomplished
|
||||||
|
- Cross-session learning and insight capture for project improvement
|
||||||
|
- Quality gates requiring comprehensive task adherence verification
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:reflect [--type task|session|completion] [--analyze] [--validate]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Examine current task state and session progress using Serena reflection tools
|
||||||
|
2. **Validate**: Assess task adherence, completion quality, and requirement fulfillment
|
||||||
|
3. **Reflect**: Apply deep analysis of collected information and session insights
|
||||||
|
4. **Document**: Update session metadata and capture learning insights
|
||||||
|
5. **Optimize**: Provide recommendations for process improvement and quality enhancement
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Serena MCP integration for comprehensive reflection analysis and task validation
|
||||||
|
- Bridge between TodoWrite patterns and advanced Serena analysis capabilities
|
||||||
|
- Session lifecycle integration with cross-session persistence and learning capture
|
||||||
|
- Performance-critical operations with <200ms core reflection and validation
|
||||||
|
## MCP Integration
|
||||||
|
- **Serena MCP**: Mandatory integration for reflection analysis, task validation, and session metadata
|
||||||
|
- **Reflection Tools**: think_about_task_adherence, think_about_collected_information, think_about_whether_you_are_done
|
||||||
|
- **Memory Operations**: Cross-session persistence with read_memory, write_memory, list_memories
|
||||||
|
- **Performance Critical**: <200ms for core reflection operations, <1s for checkpoint creation
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **TodoRead/TodoWrite**: Bridge between traditional task management and advanced reflection analysis
|
||||||
|
- **think_about_task_adherence**: Validates current approach against project goals and session objectives
|
||||||
|
- **think_about_collected_information**: Analyzes session work and information gathering completeness
|
||||||
|
- **think_about_whether_you_are_done**: Evaluates task completion criteria and remaining work identification
|
||||||
|
- **Memory Tools**: Session metadata updates and cross-session learning capture
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Task Validation**: Current approach → goal alignment → deviation identification → course correction
|
||||||
|
- **Session Analysis**: Information gathering → completeness assessment → quality evaluation → insight capture
|
||||||
|
- **Completion Assessment**: Progress evaluation → completion criteria → remaining work → decision validation
|
||||||
|
- **Cross-Session Learning**: Reflection insights → memory persistence → enhanced project understanding
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Task Adherence Reflection
|
||||||
|
```
|
||||||
|
/sc:reflect --type task --analyze
|
||||||
|
# Validates current approach against project goals
|
||||||
|
# Identifies deviations and provides course correction recommendations
|
||||||
|
```
|
||||||
|
|
||||||
|
### Session Progress Analysis
|
||||||
|
```
|
||||||
|
/sc:reflect --type session --validate
|
||||||
|
# Comprehensive analysis of session work and information gathering
|
||||||
|
# Quality assessment and gap identification for project improvement
|
||||||
|
```
|
||||||
|
|
||||||
|
### Completion Validation
|
||||||
|
```
|
||||||
|
/sc:reflect --type completion
|
||||||
|
# Evaluates task completion criteria against actual progress
|
||||||
|
# Determines readiness for task completion and identifies remaining blockers
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Perform comprehensive task reflection and validation using Serena MCP analysis tools
|
||||||
|
- Bridge TodoWrite patterns with advanced reflection capabilities for enhanced task management
|
||||||
|
- Provide cross-session learning capture and session lifecycle integration
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Operate without proper Serena MCP integration and reflection tool access
|
||||||
|
- Override task completion decisions without proper adherence and quality validation
|
||||||
|
- Bypass session integrity checks and cross-session persistence requirements
|
||||||
|
|
||||||
@@ -1,122 +1,103 @@
|
|||||||
---
|
---
|
||||||
name: sc:research
|
name: research
|
||||||
description: Deep Research - Parallel web search with evidence-based synthesis
|
description: Deep web research with adaptive planning and intelligent search
|
||||||
|
category: command
|
||||||
|
complexity: advanced
|
||||||
|
mcp-servers: [tavily, sequential, playwright, serena]
|
||||||
|
personas: [deep-research-agent]
|
||||||
---
|
---
|
||||||
|
|
||||||
# Deep Research Agent
|
# /sc:research - Deep Research Command
|
||||||
|
|
||||||
🔍 **Deep Research activated**
|
> **Context Framework Note**: This command activates comprehensive research capabilities with adaptive planning, multi-hop reasoning, and evidence-based synthesis.
|
||||||
|
|
||||||
## Research Protocol
|
## Triggers
|
||||||
|
- Research questions beyond knowledge cutoff
|
||||||
|
- Complex research questions
|
||||||
|
- Current events and real-time information
|
||||||
|
- Academic or technical research requirements
|
||||||
|
- Market analysis and competitive intelligence
|
||||||
|
|
||||||
Execute adaptive, parallel-first web research with evidence-based synthesis.
|
## Context Trigger Pattern
|
||||||
|
```
|
||||||
|
/sc:research "[query]" [--depth quick|standard|deep|exhaustive] [--strategy planning|intent|unified]
|
||||||
|
```
|
||||||
|
|
||||||
### Depth Levels
|
## Behavioral Flow
|
||||||
|
|
||||||
- **quick**: 1-2 searches, 2-3 minutes
|
### 1. Understand (5-10% effort)
|
||||||
- **standard**: 3-5 searches, 5-7 minutes (default)
|
- Assess query complexity and ambiguity
|
||||||
- **deep**: 5-10 searches, 10-15 minutes
|
- Identify required information types
|
||||||
- **exhaustive**: 10+ searches, 20+ minutes
|
- Determine resource requirements
|
||||||
|
- Define success criteria
|
||||||
|
|
||||||
### Research Flow
|
### 2. Plan (10-15% effort)
|
||||||
|
- Select planning strategy based on complexity
|
||||||
|
- Identify parallelization opportunities
|
||||||
|
- Generate research question decomposition
|
||||||
|
- Create investigation milestones
|
||||||
|
|
||||||
**Phase 1: Understand (5-10% effort)**
|
### 3. TodoWrite (5% effort)
|
||||||
|
- Create adaptive task hierarchy
|
||||||
|
- Scale tasks to query complexity (3-15 tasks)
|
||||||
|
- Establish task dependencies
|
||||||
|
- Set progress tracking
|
||||||
|
|
||||||
Parse user query and extract:
|
### 4. Execute (50-60% effort)
|
||||||
- Primary topic
|
- **Parallel-first searches**: Always batch similar queries
|
||||||
- Required detail level
|
- **Smart extraction**: Route by content complexity
|
||||||
- Time constraints
|
- **Multi-hop exploration**: Follow entity and concept chains
|
||||||
- Success criteria
|
- **Evidence collection**: Track sources and confidence
|
||||||
|
|
||||||
**Phase 2: Plan (10-15% effort)**
|
### 5. Track (Continuous)
|
||||||
|
- Monitor TodoWrite progress
|
||||||
Create search strategy:
|
- Update confidence scores
|
||||||
1. Identify key concepts
|
- Log successful patterns
|
||||||
2. Plan parallel search queries
|
|
||||||
3. Select sources (official docs, GitHub, technical blogs)
|
|
||||||
4. Estimate depth level
|
|
||||||
|
|
||||||
**Phase 3: TodoWrite (5% effort)**
|
|
||||||
|
|
||||||
Track research tasks:
|
|
||||||
- [ ] Understanding phase
|
|
||||||
- [ ] Search queries planned
|
|
||||||
- [ ] Parallel searches executed
|
|
||||||
- [ ] Results synthesized
|
|
||||||
- [ ] Validation complete
|
|
||||||
|
|
||||||
**Phase 4: Execute (50-60% effort)**
|
|
||||||
|
|
||||||
**Wave → Checkpoint → Wave pattern**:
|
|
||||||
|
|
||||||
**Wave 1: Parallel Searches**
|
|
||||||
Execute multiple searches simultaneously:
|
|
||||||
- Use Tavily MCP for web search
|
|
||||||
- Use Context7 MCP for official documentation
|
|
||||||
- Use WebFetch for specific URLs
|
|
||||||
- Use WebSearch as fallback
|
|
||||||
|
|
||||||
**Checkpoint: Analyze Results**
|
|
||||||
- Verify source credibility
|
|
||||||
- Extract key information
|
|
||||||
- Identify information gaps
|
- Identify information gaps
|
||||||
|
|
||||||
**Wave 2: Follow-up Searches**
|
### 6. Validate (10-15% effort)
|
||||||
- Fill identified gaps
|
- Verify evidence chains
|
||||||
- Verify conflicting information
|
- Check source credibility
|
||||||
- Find code examples
|
- Resolve contradictions
|
||||||
|
- Ensure completeness
|
||||||
|
|
||||||
**Phase 5: Validate (10-15% effort)**
|
## Key Patterns
|
||||||
|
|
||||||
Quality checks:
|
### Parallel Execution
|
||||||
- Official documentation cited?
|
- Batch all independent searches
|
||||||
- Multiple sources confirm findings?
|
- Run concurrent extractions
|
||||||
- Code examples verified?
|
- Only sequential for dependencies
|
||||||
- Confidence score ≥ 0.85?
|
|
||||||
|
|
||||||
**Phase 6: Synthesize**
|
### Evidence Management
|
||||||
|
- Track search results
|
||||||
|
- Provide clear citations when available
|
||||||
|
- Note uncertainties explicitly
|
||||||
|
|
||||||
Output format:
|
### Adaptive Depth
|
||||||
```
|
- **Quick**: Basic search, 1 hop, summary output
|
||||||
## Research Summary
|
- **Standard**: Extended search, 2-3 hops, structured report
|
||||||
|
- **Deep**: Comprehensive search, 3-4 hops, detailed analysis
|
||||||
{2-3 sentence overview}
|
- **Exhaustive**: Maximum depth, 5 hops, complete investigation
|
||||||
|
|
||||||
## Key Findings
|
|
||||||
|
|
||||||
1. {Finding with source citation}
|
|
||||||
2. {Finding with source citation}
|
|
||||||
3. {Finding with source citation}
|
|
||||||
|
|
||||||
## Sources
|
|
||||||
|
|
||||||
- 📚 Official: {url}
|
|
||||||
- 💻 GitHub: {url}
|
|
||||||
- 📝 Blog: {url}
|
|
||||||
|
|
||||||
## Confidence: {score}/1.0
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## MCP Integration
|
## MCP Integration
|
||||||
|
- **Tavily**: Primary search and extraction engine
|
||||||
|
- **Sequential**: Complex reasoning and synthesis
|
||||||
|
- **Playwright**: JavaScript-heavy content extraction
|
||||||
|
- **Serena**: Research session persistence
|
||||||
|
|
||||||
**Primary**: Tavily (web search + extraction)
|
## Output Standards
|
||||||
**Secondary**: Context7 (official docs), Sequential (reasoning), Playwright (JS content)
|
- Save reports to `claudedocs/research_[topic]_[timestamp].md`
|
||||||
|
- Include executive summary
|
||||||
---
|
- Provide confidence levels
|
||||||
|
- List all sources with citations
|
||||||
## Parallel Execution
|
|
||||||
|
|
||||||
**ALWAYS execute searches in parallel** (multiple tool calls in one message):
|
|
||||||
|
|
||||||
|
## Examples
|
||||||
```
|
```
|
||||||
Good: [Tavily search 1] + [Context7 lookup] + [WebFetch URL]
|
/sc:research "latest developments in quantum computing 2024"
|
||||||
Bad: Execute search 1 → Wait → Execute search 2 → Wait
|
/sc:research "competitive analysis of AI coding assistants" --depth deep
|
||||||
|
/sc:research "best practices for distributed systems" --strategy unified
|
||||||
```
|
```
|
||||||
|
|
||||||
**Performance**: 3-5x faster than sequential
|
## Boundaries
|
||||||
|
**Will**: Current information, intelligent search, evidence-based analysis
|
||||||
---
|
**Won't**: Make claims without sources, skip validation, access restricted content
|
||||||
|
|
||||||
**Deep Research is now active.** Provide your research query to begin.
|
|
||||||
93
plugins/superclaude/commands/save.md
Normal file
93
plugins/superclaude/commands/save.md
Normal file
@@ -0,0 +1,93 @@
|
|||||||
|
---
|
||||||
|
name: save
|
||||||
|
description: "Session lifecycle management with Serena MCP integration for session context persistence"
|
||||||
|
category: session
|
||||||
|
complexity: standard
|
||||||
|
mcp-servers: [serena]
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:save - Session Context Persistence
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Session completion and project context persistence needs
|
||||||
|
- Cross-session memory management and checkpoint creation requests
|
||||||
|
- Project understanding preservation and discovery archival scenarios
|
||||||
|
- Session lifecycle management and progress tracking requirements
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:save [--type session|learnings|context|all] [--summarize] [--checkpoint]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Examine session progress and identify discoveries worth preserving
|
||||||
|
2. **Persist**: Save session context and learnings using Serena MCP memory management
|
||||||
|
3. **Checkpoint**: Create recovery points for complex sessions and progress tracking
|
||||||
|
4. **Validate**: Ensure session data integrity and cross-session compatibility
|
||||||
|
5. **Prepare**: Ready session context for seamless continuation in future sessions
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Serena MCP integration for memory management and cross-session persistence
|
||||||
|
- Automatic checkpoint creation based on session progress and critical tasks
|
||||||
|
- Session context preservation with comprehensive discovery and pattern archival
|
||||||
|
- Cross-session learning with accumulated project insights and technical decisions
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Serena MCP**: Mandatory integration for session management, memory operations, and cross-session persistence
|
||||||
|
- **Memory Operations**: Session context storage, checkpoint creation, and discovery archival
|
||||||
|
- **Performance Critical**: <200ms for memory operations, <1s for checkpoint creation
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **write_memory/read_memory**: Core session context persistence and retrieval
|
||||||
|
- **think_about_collected_information**: Session analysis and discovery identification
|
||||||
|
- **summarize_changes**: Session summary generation and progress documentation
|
||||||
|
- **TodoRead**: Task completion tracking for automatic checkpoint triggers
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Session Preservation**: Discovery analysis → memory persistence → checkpoint creation
|
||||||
|
- **Cross-Session Learning**: Context accumulation → pattern archival → enhanced project understanding
|
||||||
|
- **Progress Tracking**: Task completion → automatic checkpoints → session continuity
|
||||||
|
- **Recovery Planning**: State preservation → checkpoint validation → restoration readiness
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Basic Session Save
|
||||||
|
```
|
||||||
|
/sc:save
|
||||||
|
# Saves current session discoveries and context to Serena MCP
|
||||||
|
# Automatically creates checkpoint if session exceeds 30 minutes
|
||||||
|
```
|
||||||
|
|
||||||
|
### Comprehensive Session Checkpoint
|
||||||
|
```
|
||||||
|
/sc:save --type all --checkpoint
|
||||||
|
# Complete session preservation with recovery checkpoint
|
||||||
|
# Includes all learnings, context, and progress for session restoration
|
||||||
|
```
|
||||||
|
|
||||||
|
### Session Summary Generation
|
||||||
|
```
|
||||||
|
/sc:save --summarize
|
||||||
|
# Creates session summary with discovery documentation
|
||||||
|
# Updates cross-session learning patterns and project insights
|
||||||
|
```
|
||||||
|
|
||||||
|
### Discovery-Only Persistence
|
||||||
|
```
|
||||||
|
/sc:save --type learnings
|
||||||
|
# Saves only new patterns and insights discovered during session
|
||||||
|
# Updates project understanding without full session preservation
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Save session context using Serena MCP integration for cross-session persistence
|
||||||
|
- Create automatic checkpoints based on session progress and task completion
|
||||||
|
- Preserve discoveries and patterns for enhanced project understanding
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Operate without proper Serena MCP integration and memory access
|
||||||
|
- Save session data without validation and integrity verification
|
||||||
|
- Override existing session context without proper checkpoint preservation
|
||||||
87
plugins/superclaude/commands/select-tool.md
Normal file
87
plugins/superclaude/commands/select-tool.md
Normal file
@@ -0,0 +1,87 @@
|
|||||||
|
---
|
||||||
|
name: select-tool
|
||||||
|
description: "Intelligent MCP tool selection based on complexity scoring and operation analysis"
|
||||||
|
category: special
|
||||||
|
complexity: high
|
||||||
|
mcp-servers: [serena, morphllm]
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:select-tool - Intelligent MCP Tool Selection
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Operations requiring optimal MCP tool selection between Serena and Morphllm
|
||||||
|
- Meta-system decisions needing complexity analysis and capability matching
|
||||||
|
- Tool routing decisions requiring performance vs accuracy trade-offs
|
||||||
|
- Operations benefiting from intelligent tool capability assessment
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:select-tool [operation] [--analyze] [--explain]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Parse**: Analyze operation type, scope, file count, and complexity indicators
|
||||||
|
2. **Score**: Apply multi-dimensional complexity scoring across various operation factors
|
||||||
|
3. **Match**: Compare operation requirements against Serena and Morphllm capabilities
|
||||||
|
4. **Select**: Choose optimal tool based on scoring matrix and performance requirements
|
||||||
|
5. **Validate**: Verify selection accuracy and provide confidence metrics
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Complexity scoring based on file count, operation type, language, and framework requirements
|
||||||
|
- Performance assessment evaluating speed vs accuracy trade-offs for optimal selection
|
||||||
|
- Decision logic matrix with direct mappings and threshold-based routing rules
|
||||||
|
- Tool capability matching for Serena (semantic operations) vs Morphllm (pattern operations)
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Serena MCP**: Optimal for semantic operations, LSP functionality, symbol navigation, and project context
|
||||||
|
- **Morphllm MCP**: Optimal for pattern-based edits, bulk transformations, and speed-critical operations
|
||||||
|
- **Decision Matrix**: Intelligent routing based on complexity scoring and operation characteristics
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **get_current_config**: System configuration analysis for tool capability assessment
|
||||||
|
- **execute_sketched_edit**: Operation testing and validation for selection accuracy
|
||||||
|
- **Read/Grep**: Operation context analysis and complexity factor identification
|
||||||
|
- **Integration**: Automatic selection logic used by refactor, edit, implement, and improve commands
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Direct Mapping**: Symbol operations → Serena, Pattern edits → Morphllm, Memory operations → Serena
|
||||||
|
- **Complexity Thresholds**: Score >0.6 → Serena, Score <0.4 → Morphllm, 0.4-0.6 → Feature-based
|
||||||
|
- **Performance Trade-offs**: Speed requirements → Morphllm, Accuracy requirements → Serena
|
||||||
|
- **Fallback Strategy**: Serena → Morphllm → Native tools degradation chain
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Complex Refactoring Operation
|
||||||
|
```
|
||||||
|
/sc:select-tool "rename function across 10 files" --analyze
|
||||||
|
# Analysis: High complexity (multi-file, symbol operations)
|
||||||
|
# Selection: Serena MCP (LSP capabilities, semantic understanding)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Pattern-Based Bulk Edit
|
||||||
|
```
|
||||||
|
/sc:select-tool "update console.log to logger.info across project" --explain
|
||||||
|
# Analysis: Pattern-based transformation, speed priority
|
||||||
|
# Selection: Morphllm MCP (pattern matching, bulk operations)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Memory Management Operation
|
||||||
|
```
|
||||||
|
/sc:select-tool "save project context and discoveries"
|
||||||
|
# Direct mapping: Memory operations → Serena MCP
|
||||||
|
# Rationale: Project context and cross-session persistence
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Analyze operations and provide optimal tool selection between Serena and Morphllm
|
||||||
|
- Apply complexity scoring based on file count, operation type, and requirements
|
||||||
|
- Provide sub-100ms decision time with >95% selection accuracy
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Override explicit tool specifications when user has clear preference
|
||||||
|
- Select tools without proper complexity analysis and capability matching
|
||||||
|
- Compromise performance requirements for convenience or speed
|
||||||
|
|
||||||
85
plugins/superclaude/commands/spawn.md
Normal file
85
plugins/superclaude/commands/spawn.md
Normal file
@@ -0,0 +1,85 @@
|
|||||||
|
---
|
||||||
|
name: spawn
|
||||||
|
description: "Meta-system task orchestration with intelligent breakdown and delegation"
|
||||||
|
category: special
|
||||||
|
complexity: high
|
||||||
|
mcp-servers: []
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:spawn - Meta-System Task Orchestration
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Complex multi-domain operations requiring intelligent task breakdown
|
||||||
|
- Large-scale system operations spanning multiple technical areas
|
||||||
|
- Operations requiring parallel coordination and dependency management
|
||||||
|
- Meta-level orchestration beyond standard command capabilities
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:spawn [complex-task] [--strategy sequential|parallel|adaptive] [--depth normal|deep]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Parse complex operation requirements and assess scope across domains
|
||||||
|
2. **Decompose**: Break down operation into coordinated subtask hierarchies
|
||||||
|
3. **Orchestrate**: Execute tasks using optimal coordination strategy (parallel/sequential)
|
||||||
|
4. **Monitor**: Track progress across task hierarchies with dependency management
|
||||||
|
5. **Integrate**: Aggregate results and provide comprehensive orchestration summary
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Meta-system task decomposition with Epic → Story → Task → Subtask breakdown
|
||||||
|
- Intelligent coordination strategy selection based on operation characteristics
|
||||||
|
- Cross-domain operation management with parallel and sequential execution patterns
|
||||||
|
- Advanced dependency analysis and resource optimization across task hierarchies
|
||||||
|
## MCP Integration
|
||||||
|
- **Native Orchestration**: Meta-system command uses native coordination without MCP dependencies
|
||||||
|
- **Progressive Integration**: Coordination with systematic execution for progressive enhancement
|
||||||
|
- **Framework Integration**: Advanced integration with SuperClaude orchestration layers
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **TodoWrite**: Hierarchical task breakdown and progress tracking across Epic → Story → Task levels
|
||||||
|
- **Read/Grep/Glob**: System analysis and dependency mapping for complex operations
|
||||||
|
- **Edit/MultiEdit/Write**: Coordinated file operations with parallel and sequential execution
|
||||||
|
- **Bash**: System-level operations coordination with intelligent resource management
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Hierarchical Breakdown**: Epic-level operations → Story coordination → Task execution → Subtask granularity
|
||||||
|
- **Strategy Selection**: Sequential (dependency-ordered) → Parallel (independent) → Adaptive (dynamic)
|
||||||
|
- **Meta-System Coordination**: Cross-domain operations → resource optimization → result integration
|
||||||
|
- **Progressive Enhancement**: Systematic execution → quality gates → comprehensive validation
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Complex Feature Implementation
|
||||||
|
```
|
||||||
|
/sc:spawn "implement user authentication system"
|
||||||
|
# Breakdown: Database design → Backend API → Frontend UI → Testing
|
||||||
|
# Coordinates across multiple domains with dependency management
|
||||||
|
```
|
||||||
|
|
||||||
|
### Large-Scale System Operation
|
||||||
|
```
|
||||||
|
/sc:spawn "migrate legacy monolith to microservices" --strategy adaptive --depth deep
|
||||||
|
# Enterprise-scale operation with sophisticated orchestration
|
||||||
|
# Adaptive coordination based on operation characteristics
|
||||||
|
```
|
||||||
|
|
||||||
|
### Cross-Domain Infrastructure
|
||||||
|
```
|
||||||
|
/sc:spawn "establish CI/CD pipeline with security scanning"
|
||||||
|
# System-wide infrastructure operation spanning DevOps, Security, Quality domains
|
||||||
|
# Parallel execution of independent components with validation gates
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Decompose complex multi-domain operations into coordinated task hierarchies
|
||||||
|
- Provide intelligent orchestration with parallel and sequential coordination strategies
|
||||||
|
- Execute meta-system operations beyond standard command capabilities
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Replace domain-specific commands for simple operations
|
||||||
|
- Override user coordination preferences or execution strategies
|
||||||
|
- Execute operations without proper dependency analysis and validation
|
||||||
428
plugins/superclaude/commands/spec-panel.md
Normal file
428
plugins/superclaude/commands/spec-panel.md
Normal file
@@ -0,0 +1,428 @@
|
|||||||
|
---
|
||||||
|
name: spec-panel
|
||||||
|
description: "Multi-expert specification review and improvement using renowned specification and software engineering experts"
|
||||||
|
category: analysis
|
||||||
|
complexity: enhanced
|
||||||
|
mcp-servers: [sequential, context7]
|
||||||
|
personas: [technical-writer, system-architect, quality-engineer]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:spec-panel - Expert Specification Review Panel
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Specification quality review and improvement requests
|
||||||
|
- Technical documentation validation and enhancement needs
|
||||||
|
- Requirements analysis and completeness verification
|
||||||
|
- Professional specification writing guidance and mentoring
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:spec-panel [specification_content|@file] [--mode discussion|critique|socratic] [--experts "name1,name2"] [--focus requirements|architecture|testing|compliance] [--iterations N] [--format standard|structured|detailed]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Parse specification content and identify key components, gaps, and quality issues
|
||||||
|
2. **Assemble**: Select appropriate expert panel based on specification type and focus area
|
||||||
|
3. **Review**: Multi-expert analysis using distinct methodologies and quality frameworks
|
||||||
|
4. **Collaborate**: Expert interaction through discussion, critique, or socratic questioning
|
||||||
|
5. **Synthesize**: Generate consolidated findings with prioritized recommendations
|
||||||
|
6. **Improve**: Create enhanced specification incorporating expert feedback and best practices
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Multi-expert perspective analysis with distinct methodologies and quality frameworks
|
||||||
|
- Intelligent expert selection based on specification domain and focus requirements
|
||||||
|
- Structured review process with evidence-based recommendations and improvement guidance
|
||||||
|
- Iterative improvement cycles with quality validation and progress tracking
|
||||||
|
|
||||||
|
## Expert Panel System
|
||||||
|
|
||||||
|
### Core Specification Experts
|
||||||
|
|
||||||
|
**Karl Wiegers** - Requirements Engineering Pioneer
|
||||||
|
- **Domain**: Functional/non-functional requirements, requirement quality frameworks
|
||||||
|
- **Methodology**: SMART criteria, testability analysis, stakeholder validation
|
||||||
|
- **Critique Focus**: "This requirement lacks measurable acceptance criteria. How would you validate compliance in production?"
|
||||||
|
|
||||||
|
**Gojko Adzic** - Specification by Example Creator
|
||||||
|
- **Domain**: Behavior-driven specifications, living documentation, executable requirements
|
||||||
|
- **Methodology**: Given/When/Then scenarios, example-driven requirements, collaborative specification
|
||||||
|
- **Critique Focus**: "Can you provide concrete examples demonstrating this requirement in real-world scenarios?"
|
||||||
|
|
||||||
|
**Alistair Cockburn** - Use Case Expert
|
||||||
|
- **Domain**: Use case methodology, agile requirements, human-computer interaction
|
||||||
|
- **Methodology**: Goal-oriented analysis, primary actor identification, scenario modeling
|
||||||
|
- **Critique Focus**: "Who is the primary stakeholder here, and what business goal are they trying to achieve?"
|
||||||
|
|
||||||
|
**Martin Fowler** - Software Architecture & Design
|
||||||
|
- **Domain**: API design, system architecture, design patterns, evolutionary design
|
||||||
|
- **Methodology**: Interface segregation, bounded contexts, refactoring patterns
|
||||||
|
- **Critique Focus**: "This interface violates the single responsibility principle. Consider separating concerns."
|
||||||
|
|
||||||
|
### Technical Architecture Experts
|
||||||
|
|
||||||
|
**Michael Nygard** - Release It! Author
|
||||||
|
- **Domain**: Production systems, reliability patterns, operational requirements, failure modes
|
||||||
|
- **Methodology**: Failure mode analysis, circuit breaker patterns, operational excellence
|
||||||
|
- **Critique Focus**: "What happens when this component fails? Where are the monitoring and recovery mechanisms?"
|
||||||
|
|
||||||
|
**Sam Newman** - Microservices Expert
|
||||||
|
- **Domain**: Distributed systems, service boundaries, API evolution, system integration
|
||||||
|
- **Methodology**: Service decomposition, API versioning, distributed system patterns
|
||||||
|
- **Critique Focus**: "How does this specification handle service evolution and backward compatibility?"
|
||||||
|
|
||||||
|
**Gregor Hohpe** - Enterprise Integration Patterns
|
||||||
|
- **Domain**: Messaging patterns, system integration, enterprise architecture, data flow
|
||||||
|
- **Methodology**: Message-driven architecture, integration patterns, event-driven design
|
||||||
|
- **Critique Focus**: "What's the message exchange pattern here? How do you handle ordering and delivery guarantees?"
|
||||||
|
|
||||||
|
### Quality & Testing Experts
|
||||||
|
|
||||||
|
**Lisa Crispin** - Agile Testing Expert
|
||||||
|
- **Domain**: Testing strategies, quality requirements, acceptance criteria, test automation
|
||||||
|
- **Methodology**: Whole-team testing, risk-based testing, quality attribute specification
|
||||||
|
- **Critique Focus**: "How would the testing team validate this requirement? What are the edge cases and failure scenarios?"
|
||||||
|
|
||||||
|
**Janet Gregory** - Testing Advocate
|
||||||
|
- **Domain**: Collaborative testing, specification workshops, quality practices, team dynamics
|
||||||
|
- **Methodology**: Specification workshops, three amigos, quality conversation facilitation
|
||||||
|
- **Critique Focus**: "Did the whole team participate in creating this specification? Are quality expectations clearly defined?"
|
||||||
|
|
||||||
|
### Modern Software Experts
|
||||||
|
|
||||||
|
**Kelsey Hightower** - Cloud Native Expert
|
||||||
|
- **Domain**: Kubernetes, cloud architecture, operational excellence, infrastructure as code
|
||||||
|
- **Methodology**: Cloud-native patterns, infrastructure automation, operational observability
|
||||||
|
- **Critique Focus**: "How does this specification handle cloud-native deployment and operational concerns?"
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Sequential MCP**: Primary engine for expert panel coordination, structured analysis, and iterative improvement
|
||||||
|
- **Context7 MCP**: Auto-activated for specification patterns, documentation standards, and industry best practices
|
||||||
|
- **Technical Writer Persona**: Activated for professional specification writing and documentation quality
|
||||||
|
- **System Architect Persona**: Activated for architectural analysis and system design validation
|
||||||
|
- **Quality Engineer Persona**: Activated for quality assessment and testing strategy validation
|
||||||
|
|
||||||
|
## Analysis Modes
|
||||||
|
|
||||||
|
### Discussion Mode (`--mode discussion`)
|
||||||
|
**Purpose**: Collaborative improvement through expert dialogue and knowledge sharing
|
||||||
|
|
||||||
|
**Expert Interaction Pattern**:
|
||||||
|
- Sequential expert commentary building upon previous insights
|
||||||
|
- Cross-expert validation and refinement of recommendations
|
||||||
|
- Consensus building around critical improvements
|
||||||
|
- Collaborative solution development
|
||||||
|
|
||||||
|
**Example Output**:
|
||||||
|
```
|
||||||
|
KARL WIEGERS: "The requirement 'SHALL handle failures gracefully' lacks specificity.
|
||||||
|
What constitutes graceful handling? What types of failures are we addressing?"
|
||||||
|
|
||||||
|
MICHAEL NYGARD: "Building on Karl's point, we need specific failure modes: network
|
||||||
|
timeouts, service unavailable, rate limiting. Each requires different handling strategies."
|
||||||
|
|
||||||
|
GOJKO ADZIC: "Let's make this concrete with examples:
|
||||||
|
Given: Service timeout after 30 seconds
|
||||||
|
When: Circuit breaker activates
|
||||||
|
Then: Return cached response within 100ms"
|
||||||
|
|
||||||
|
MARTIN FOWLER: "The specification should also define the failure notification interface.
|
||||||
|
How do upstream services know what type of failure occurred?"
|
||||||
|
```
|
||||||
|
|
||||||
|
### Critique Mode (`--mode critique`)
|
||||||
|
**Purpose**: Systematic review with specific improvement suggestions and priority rankings
|
||||||
|
|
||||||
|
**Analysis Structure**:
|
||||||
|
- Issue identification with severity classification
|
||||||
|
- Specific improvement recommendations with rationale
|
||||||
|
- Priority ranking based on impact and effort
|
||||||
|
- Quality metrics and validation criteria
|
||||||
|
|
||||||
|
**Example Output**:
|
||||||
|
```
|
||||||
|
=== REQUIREMENTS ANALYSIS ===
|
||||||
|
|
||||||
|
KARL WIEGERS - Requirements Quality Assessment:
|
||||||
|
❌ CRITICAL: Requirement R-001 lacks measurable acceptance criteria
|
||||||
|
📝 RECOMMENDATION: Replace "handle failures gracefully" with "open circuit breaker after 5 consecutive failures within 30 seconds"
|
||||||
|
🎯 PRIORITY: High - Affects testability and validation
|
||||||
|
📊 QUALITY IMPACT: +40% testability, +60% clarity
|
||||||
|
|
||||||
|
GOJKO ADZIC - Specification Testability:
|
||||||
|
⚠️ MAJOR: No executable examples provided for complex behaviors
|
||||||
|
📝 RECOMMENDATION: Add Given/When/Then scenarios for each requirement
|
||||||
|
🎯 PRIORITY: Medium - Improves understanding and validation
|
||||||
|
📊 QUALITY IMPACT: +50% comprehensibility, +35% validation coverage
|
||||||
|
|
||||||
|
=== ARCHITECTURE ANALYSIS ===
|
||||||
|
|
||||||
|
MARTIN FOWLER - Interface Design:
|
||||||
|
⚠️ MINOR: CircuitBreaker interface couples state management with execution logic
|
||||||
|
📝 RECOMMENDATION: Separate CircuitBreakerState from CircuitBreakerExecutor
|
||||||
|
🎯 PRIORITY: Low - Design improvement, not functional issue
|
||||||
|
📊 QUALITY IMPACT: +20% maintainability, +15% testability
|
||||||
|
```
|
||||||
|
|
||||||
|
### Socratic Mode (`--mode socratic`)
|
||||||
|
**Purpose**: Learning-focused questioning to deepen understanding and improve thinking
|
||||||
|
|
||||||
|
**Question Categories**:
|
||||||
|
- Foundational understanding questions
|
||||||
|
- Stakeholder and purpose clarification
|
||||||
|
- Assumption identification and validation
|
||||||
|
- Alternative approach exploration
|
||||||
|
|
||||||
|
**Example Output**:
|
||||||
|
```
|
||||||
|
ALISTAIR COCKBURN: "What is the fundamental problem this specification is trying to solve?"
|
||||||
|
|
||||||
|
KARL WIEGERS: "Who are the primary stakeholders affected by these requirements?"
|
||||||
|
|
||||||
|
MICHAEL NYGARD: "What assumptions are you making about the deployment environment and operational context?"
|
||||||
|
|
||||||
|
GOJKO ADZIC: "How would you explain these requirements to a non-technical business stakeholder?"
|
||||||
|
|
||||||
|
MARTIN FOWLER: "What would happen if we removed this requirement entirely? What breaks?"
|
||||||
|
|
||||||
|
LISA CRISPIN: "How would you validate that this specification is working correctly in production?"
|
||||||
|
|
||||||
|
KELSEY HIGHTOWER: "What operational and monitoring capabilities does this specification require?"
|
||||||
|
```
|
||||||
|
|
||||||
|
## Focus Areas
|
||||||
|
|
||||||
|
### Requirements Focus (`--focus requirements`)
|
||||||
|
**Expert Panel**: Wiegers (lead), Adzic, Cockburn
|
||||||
|
**Analysis Areas**:
|
||||||
|
- Requirement clarity, completeness, and consistency
|
||||||
|
- Testability and measurability assessment
|
||||||
|
- Stakeholder needs alignment and validation
|
||||||
|
- Acceptance criteria quality and coverage
|
||||||
|
- Requirements traceability and verification
|
||||||
|
|
||||||
|
### Architecture Focus (`--focus architecture`)
|
||||||
|
**Expert Panel**: Fowler (lead), Newman, Hohpe, Nygard
|
||||||
|
**Analysis Areas**:
|
||||||
|
- Interface design quality and consistency
|
||||||
|
- System boundary definitions and service decomposition
|
||||||
|
- Scalability and maintainability characteristics
|
||||||
|
- Design pattern appropriateness and implementation
|
||||||
|
- Integration and communication specifications
|
||||||
|
|
||||||
|
### Testing Focus (`--focus testing`)
|
||||||
|
**Expert Panel**: Crispin (lead), Gregory, Adzic
|
||||||
|
**Analysis Areas**:
|
||||||
|
- Test strategy and coverage requirements
|
||||||
|
- Quality attribute specifications and validation
|
||||||
|
- Edge case identification and handling
|
||||||
|
- Acceptance criteria and definition of done
|
||||||
|
- Test automation and continuous validation
|
||||||
|
|
||||||
|
### Compliance Focus (`--focus compliance`)
|
||||||
|
**Expert Panel**: Wiegers (lead), Nygard, Hightower
|
||||||
|
**Analysis Areas**:
|
||||||
|
- Regulatory requirement coverage and validation
|
||||||
|
- Security specifications and threat modeling
|
||||||
|
- Operational requirements and observability
|
||||||
|
- Audit trail and compliance verification
|
||||||
|
- Risk assessment and mitigation strategies
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read**: Specification content analysis and parsing
|
||||||
|
- **Sequential**: Expert panel coordination and iterative analysis
|
||||||
|
- **Context7**: Specification patterns and industry best practices
|
||||||
|
- **Grep**: Cross-reference validation and consistency checking
|
||||||
|
- **Write**: Improved specification generation and report creation
|
||||||
|
- **MultiEdit**: Collaborative specification enhancement and refinement
|
||||||
|
|
||||||
|
## Iterative Improvement Process
|
||||||
|
|
||||||
|
### Single Iteration (Default)
|
||||||
|
1. **Initial Analysis**: Expert panel reviews specification
|
||||||
|
2. **Issue Identification**: Systematic problem and gap identification
|
||||||
|
3. **Improvement Recommendations**: Specific, actionable enhancement suggestions
|
||||||
|
4. **Priority Ranking**: Critical path and impact-based prioritization
|
||||||
|
|
||||||
|
### Multi-Iteration (`--iterations N`)
|
||||||
|
**Iteration 1**: Structural and fundamental issues
|
||||||
|
- Requirements clarity and completeness
|
||||||
|
- Architecture consistency and boundaries
|
||||||
|
- Major gaps and critical problems
|
||||||
|
|
||||||
|
**Iteration 2**: Detail refinement and enhancement
|
||||||
|
- Specific improvement implementation
|
||||||
|
- Edge case handling and error scenarios
|
||||||
|
- Quality attribute specifications
|
||||||
|
|
||||||
|
**Iteration 3**: Polish and optimization
|
||||||
|
- Documentation quality and clarity
|
||||||
|
- Example and scenario enhancement
|
||||||
|
- Final validation and consistency checks
|
||||||
|
|
||||||
|
## Output Formats
|
||||||
|
|
||||||
|
### Standard Format (`--format standard`)
|
||||||
|
```yaml
|
||||||
|
specification_review:
|
||||||
|
original_spec: "authentication_service.spec.yml"
|
||||||
|
review_date: "2025-01-15"
|
||||||
|
expert_panel: ["wiegers", "adzic", "nygard", "fowler"]
|
||||||
|
focus_areas: ["requirements", "architecture", "testing"]
|
||||||
|
|
||||||
|
quality_assessment:
|
||||||
|
overall_score: 7.2/10
|
||||||
|
requirements_quality: 8.1/10
|
||||||
|
architecture_clarity: 6.8/10
|
||||||
|
testability_score: 7.5/10
|
||||||
|
|
||||||
|
critical_issues:
|
||||||
|
- category: "requirements"
|
||||||
|
severity: "high"
|
||||||
|
expert: "wiegers"
|
||||||
|
issue: "Authentication timeout not specified"
|
||||||
|
recommendation: "Define session timeout with configurable values"
|
||||||
|
|
||||||
|
- category: "architecture"
|
||||||
|
severity: "medium"
|
||||||
|
expert: "fowler"
|
||||||
|
issue: "Token refresh mechanism unclear"
|
||||||
|
recommendation: "Specify refresh token lifecycle and rotation policy"
|
||||||
|
|
||||||
|
expert_consensus:
|
||||||
|
- "Specification needs concrete failure handling definitions"
|
||||||
|
- "Missing operational monitoring and alerting requirements"
|
||||||
|
- "Authentication flow is well-defined but lacks error scenarios"
|
||||||
|
|
||||||
|
improvement_roadmap:
|
||||||
|
immediate: ["Define timeout specifications", "Add error handling scenarios"]
|
||||||
|
short_term: ["Specify monitoring requirements", "Add performance criteria"]
|
||||||
|
long_term: ["Comprehensive security review", "Integration testing strategy"]
|
||||||
|
```
|
||||||
|
|
||||||
|
### Structured Format (`--format structured`)
|
||||||
|
Token-efficient format using SuperClaude symbol system for concise communication.
|
||||||
|
|
||||||
|
### Detailed Format (`--format detailed`)
|
||||||
|
Comprehensive analysis with full expert commentary, examples, and implementation guidance.
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### API Specification Review
|
||||||
|
```
|
||||||
|
/sc:spec-panel @auth_api.spec.yml --mode critique --focus requirements,architecture
|
||||||
|
# Comprehensive API specification review
|
||||||
|
# Focus on requirements quality and architectural consistency
|
||||||
|
# Generate detailed improvement recommendations
|
||||||
|
```
|
||||||
|
|
||||||
|
### Requirements Workshop
|
||||||
|
```
|
||||||
|
/sc:spec-panel "user story content" --mode discussion --experts "wiegers,adzic,cockburn"
|
||||||
|
# Collaborative requirements analysis and improvement
|
||||||
|
# Expert dialogue for requirement refinement
|
||||||
|
# Consensus building around acceptance criteria
|
||||||
|
```
|
||||||
|
|
||||||
|
### Architecture Validation
|
||||||
|
```
|
||||||
|
/sc:spec-panel @microservice.spec.yml --mode socratic --focus architecture
|
||||||
|
# Learning-focused architectural review
|
||||||
|
# Deep questioning about design decisions
|
||||||
|
# Alternative approach exploration
|
||||||
|
```
|
||||||
|
|
||||||
|
### Iterative Improvement
|
||||||
|
```
|
||||||
|
/sc:spec-panel @complex_system.spec.yml --iterations 3 --format detailed
|
||||||
|
# Multi-iteration improvement process
|
||||||
|
# Progressive refinement with expert guidance
|
||||||
|
# Comprehensive quality enhancement
|
||||||
|
```
|
||||||
|
|
||||||
|
### Compliance Review
|
||||||
|
```
|
||||||
|
/sc:spec-panel @security_requirements.yml --focus compliance --experts "wiegers,nygard"
|
||||||
|
# Compliance and security specification review
|
||||||
|
# Regulatory requirement validation
|
||||||
|
# Risk assessment and mitigation planning
|
||||||
|
```
|
||||||
|
|
||||||
|
## Integration Patterns
|
||||||
|
|
||||||
|
### Workflow Integration with /sc:code-to-spec
|
||||||
|
```bash
|
||||||
|
# Generate initial specification from code
|
||||||
|
/sc:code-to-spec ./authentication_service --type api --format yaml
|
||||||
|
|
||||||
|
# Review and improve with expert panel
|
||||||
|
/sc:spec-panel @generated_auth_spec.yml --mode critique --focus requirements,testing
|
||||||
|
|
||||||
|
# Iterative refinement based on feedback
|
||||||
|
/sc:spec-panel @improved_auth_spec.yml --mode discussion --iterations 2
|
||||||
|
```
|
||||||
|
|
||||||
|
### Learning and Development Workflow
|
||||||
|
```bash
|
||||||
|
# Start with socratic mode for learning
|
||||||
|
/sc:spec-panel @my_first_spec.yml --mode socratic --iterations 2
|
||||||
|
|
||||||
|
# Apply learnings with discussion mode
|
||||||
|
/sc:spec-panel @revised_spec.yml --mode discussion --focus requirements
|
||||||
|
|
||||||
|
# Final quality validation with critique mode
|
||||||
|
/sc:spec-panel @final_spec.yml --mode critique --format detailed
|
||||||
|
```
|
||||||
|
|
||||||
|
## Quality Assurance Features
|
||||||
|
|
||||||
|
### Expert Validation
|
||||||
|
- Cross-expert consistency checking and validation
|
||||||
|
- Methodology alignment and best practice verification
|
||||||
|
- Quality metric calculation and progress tracking
|
||||||
|
- Recommendation prioritization and impact assessment
|
||||||
|
|
||||||
|
### Specification Quality Metrics
|
||||||
|
- **Clarity Score**: Language precision and understandability (0-10)
|
||||||
|
- **Completeness Score**: Coverage of essential specification elements (0-10)
|
||||||
|
- **Testability Score**: Measurability and validation capability (0-10)
|
||||||
|
- **Consistency Score**: Internal coherence and contradiction detection (0-10)
|
||||||
|
|
||||||
|
### Continuous Improvement
|
||||||
|
- Pattern recognition from successful improvements
|
||||||
|
- Expert recommendation effectiveness tracking
|
||||||
|
- Specification quality trend analysis
|
||||||
|
- Best practice pattern library development
|
||||||
|
|
||||||
|
## Advanced Features
|
||||||
|
|
||||||
|
### Custom Expert Panels
|
||||||
|
- Domain-specific expert selection and configuration
|
||||||
|
- Industry-specific methodology application
|
||||||
|
- Custom quality criteria and assessment frameworks
|
||||||
|
- Specialized review processes for unique requirements
|
||||||
|
|
||||||
|
### Integration with Development Workflow
|
||||||
|
- CI/CD pipeline integration for specification validation
|
||||||
|
- Version control integration for specification evolution tracking
|
||||||
|
- IDE integration for inline specification quality feedback
|
||||||
|
- Automated quality gate enforcement and validation
|
||||||
|
|
||||||
|
### Learning and Mentoring
|
||||||
|
- Progressive skill development tracking and guidance
|
||||||
|
- Specification writing pattern recognition and teaching
|
||||||
|
- Best practice library development and sharing
|
||||||
|
- Mentoring mode with educational focus and guidance
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Provide expert-level specification review and improvement guidance
|
||||||
|
- Generate specific, actionable recommendations with priority rankings
|
||||||
|
- Support multiple analysis modes for different use cases and learning objectives
|
||||||
|
- Integrate with specification generation tools for comprehensive workflow support
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Replace human judgment and domain expertise in critical decisions
|
||||||
|
- Modify specifications without explicit user consent and validation
|
||||||
|
- Generate specifications from scratch without existing content or context
|
||||||
|
- Provide legal or regulatory compliance guarantees beyond analysis guidance
|
||||||
89
plugins/superclaude/commands/task.md
Normal file
89
plugins/superclaude/commands/task.md
Normal file
@@ -0,0 +1,89 @@
|
|||||||
|
---
|
||||||
|
name: task
|
||||||
|
description: "Execute complex tasks with intelligent workflow management and delegation"
|
||||||
|
category: special
|
||||||
|
complexity: advanced
|
||||||
|
mcp-servers: [sequential, context7, magic, playwright, morphllm, serena]
|
||||||
|
personas: [architect, analyzer, frontend, backend, security, devops, project-manager]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:task - Enhanced Task Management
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Complex tasks requiring multi-agent coordination and delegation
|
||||||
|
- Projects needing structured workflow management and cross-session persistence
|
||||||
|
- Operations requiring intelligent MCP server routing and domain expertise
|
||||||
|
- Tasks benefiting from systematic execution and progressive enhancement
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:task [action] [target] [--strategy systematic|agile|enterprise] [--parallel] [--delegate]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Parse task requirements and determine optimal execution strategy
|
||||||
|
2. **Delegate**: Route to appropriate MCP servers and activate relevant personas
|
||||||
|
3. **Coordinate**: Execute tasks with intelligent workflow management and parallel processing
|
||||||
|
4. **Validate**: Apply quality gates and comprehensive task completion verification
|
||||||
|
5. **Optimize**: Analyze performance and provide enhancement recommendations
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Multi-persona coordination across architect, frontend, backend, security, devops domains
|
||||||
|
- Intelligent MCP server routing (Sequential, Context7, Magic, Playwright, Morphllm, Serena)
|
||||||
|
- Systematic execution with progressive task enhancement and cross-session persistence
|
||||||
|
- Advanced task delegation with hierarchical breakdown and dependency management
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Sequential MCP**: Complex multi-step task analysis and systematic execution planning
|
||||||
|
- **Context7 MCP**: Framework-specific patterns and implementation best practices
|
||||||
|
- **Magic MCP**: UI/UX task coordination and design system integration
|
||||||
|
- **Playwright MCP**: Testing workflow integration and validation automation
|
||||||
|
- **Morphllm MCP**: Large-scale task transformation and pattern-based optimization
|
||||||
|
- **Serena MCP**: Cross-session task persistence and project memory management
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **TodoWrite**: Hierarchical task breakdown and progress tracking across Epic → Story → Task levels
|
||||||
|
- **Task**: Advanced delegation for complex multi-agent coordination and sub-task management
|
||||||
|
- **Read/Write/Edit**: Task documentation and implementation coordination
|
||||||
|
- **sequentialthinking**: Structured reasoning for complex task dependency analysis
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Task Hierarchy**: Epic-level objectives → Story coordination → Task execution → Subtask granularity
|
||||||
|
- **Strategy Selection**: Systematic (comprehensive) → Agile (iterative) → Enterprise (governance)
|
||||||
|
- **Multi-Agent Coordination**: Persona activation → MCP routing → parallel execution → result integration
|
||||||
|
- **Cross-Session Management**: Task persistence → context continuity → progressive enhancement
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Complex Feature Development
|
||||||
|
```
|
||||||
|
/sc:task create "enterprise authentication system" --strategy systematic --parallel
|
||||||
|
# Comprehensive task breakdown with multi-domain coordination
|
||||||
|
# Activates architect, security, backend, frontend personas
|
||||||
|
```
|
||||||
|
|
||||||
|
### Agile Sprint Coordination
|
||||||
|
```
|
||||||
|
/sc:task execute "feature backlog" --strategy agile --delegate
|
||||||
|
# Iterative task execution with intelligent delegation
|
||||||
|
# Cross-session persistence for sprint continuity
|
||||||
|
```
|
||||||
|
|
||||||
|
### Multi-Domain Integration
|
||||||
|
```
|
||||||
|
/sc:task execute "microservices platform" --strategy enterprise --parallel
|
||||||
|
# Enterprise-scale coordination with compliance validation
|
||||||
|
# Parallel execution across multiple technical domains
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Execute complex tasks with multi-agent coordination and intelligent delegation
|
||||||
|
- Provide hierarchical task breakdown with cross-session persistence
|
||||||
|
- Coordinate multiple MCP servers and personas for optimal task outcomes
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Execute simple tasks that don't require advanced orchestration
|
||||||
|
- Compromise quality standards for speed or convenience
|
||||||
|
- Operate without proper validation and quality gates
|
||||||
93
plugins/superclaude/commands/test.md
Normal file
93
plugins/superclaude/commands/test.md
Normal file
@@ -0,0 +1,93 @@
|
|||||||
|
---
|
||||||
|
name: test
|
||||||
|
description: "Execute tests with coverage analysis and automated quality reporting"
|
||||||
|
category: utility
|
||||||
|
complexity: enhanced
|
||||||
|
mcp-servers: [playwright]
|
||||||
|
personas: [qa-specialist]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:test - Testing and Quality Assurance
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Test execution requests for unit, integration, or e2e tests
|
||||||
|
- Coverage analysis and quality gate validation needs
|
||||||
|
- Continuous testing and watch mode scenarios
|
||||||
|
- Test failure analysis and debugging requirements
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:test [target] [--type unit|integration|e2e|all] [--coverage] [--watch] [--fix]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Discover**: Categorize available tests using runner patterns and conventions
|
||||||
|
2. **Configure**: Set up appropriate test environment and execution parameters
|
||||||
|
3. **Execute**: Run tests with monitoring and real-time progress tracking
|
||||||
|
4. **Analyze**: Generate coverage reports and failure diagnostics
|
||||||
|
5. **Report**: Provide actionable recommendations and quality metrics
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Auto-detect test framework and configuration
|
||||||
|
- Generate comprehensive coverage reports with metrics
|
||||||
|
- Activate Playwright MCP for e2e browser testing
|
||||||
|
- Provide intelligent test failure analysis
|
||||||
|
- Support continuous watch mode for development
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Playwright MCP**: Auto-activated for `--type e2e` browser testing
|
||||||
|
- **QA Specialist Persona**: Activated for test analysis and quality assessment
|
||||||
|
- **Enhanced Capabilities**: Cross-browser testing, visual validation, performance metrics
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Bash**: Test runner execution and environment management
|
||||||
|
- **Glob**: Test discovery and file pattern matching
|
||||||
|
- **Grep**: Result parsing and failure analysis
|
||||||
|
- **Write**: Coverage reports and test summaries
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Test Discovery**: Pattern-based categorization → appropriate runner selection
|
||||||
|
- **Coverage Analysis**: Execution metrics → comprehensive coverage reporting
|
||||||
|
- **E2E Testing**: Browser automation → cross-platform validation
|
||||||
|
- **Watch Mode**: File monitoring → continuous test execution
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Basic Test Execution
|
||||||
|
```
|
||||||
|
/sc:test
|
||||||
|
# Discovers and runs all tests with standard configuration
|
||||||
|
# Generates pass/fail summary and basic coverage
|
||||||
|
```
|
||||||
|
|
||||||
|
### Targeted Coverage Analysis
|
||||||
|
```
|
||||||
|
/sc:test src/components --type unit --coverage
|
||||||
|
# Unit tests for specific directory with detailed coverage metrics
|
||||||
|
```
|
||||||
|
|
||||||
|
### Browser Testing
|
||||||
|
```
|
||||||
|
/sc:test --type e2e
|
||||||
|
# Activates Playwright MCP for comprehensive browser testing
|
||||||
|
# Cross-browser compatibility and visual validation
|
||||||
|
```
|
||||||
|
|
||||||
|
### Development Watch Mode
|
||||||
|
```
|
||||||
|
/sc:test --watch --fix
|
||||||
|
# Continuous testing with automatic simple failure fixes
|
||||||
|
# Real-time feedback during development
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Execute existing test suites using project's configured test runner
|
||||||
|
- Generate coverage reports and quality metrics
|
||||||
|
- Provide intelligent test failure analysis with actionable recommendations
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Generate test cases or modify test framework configuration
|
||||||
|
- Execute tests requiring external services without proper setup
|
||||||
|
- Make destructive changes to test files without explicit permission
|
||||||
88
plugins/superclaude/commands/troubleshoot.md
Normal file
88
plugins/superclaude/commands/troubleshoot.md
Normal file
@@ -0,0 +1,88 @@
|
|||||||
|
---
|
||||||
|
name: troubleshoot
|
||||||
|
description: "Diagnose and resolve issues in code, builds, deployments, and system behavior"
|
||||||
|
category: utility
|
||||||
|
complexity: basic
|
||||||
|
mcp-servers: []
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:troubleshoot - Issue Diagnosis and Resolution
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Code defects and runtime error investigation requests
|
||||||
|
- Build failure analysis and resolution needs
|
||||||
|
- Performance issue diagnosis and optimization requirements
|
||||||
|
- Deployment problem analysis and system behavior debugging
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:troubleshoot [issue] [--type bug|build|performance|deployment] [--trace] [--fix]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Examine issue description and gather relevant system state information
|
||||||
|
2. **Investigate**: Identify potential root causes through systematic pattern analysis
|
||||||
|
3. **Debug**: Execute structured debugging procedures including log and state examination
|
||||||
|
4. **Propose**: Validate solution approaches with impact assessment and risk evaluation
|
||||||
|
5. **Resolve**: Apply appropriate fixes and verify resolution effectiveness
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Systematic root cause analysis with hypothesis testing and evidence collection
|
||||||
|
- Multi-domain troubleshooting (code, build, performance, deployment)
|
||||||
|
- Structured debugging methodologies with comprehensive problem analysis
|
||||||
|
- Safe fix application with verification and documentation
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read**: Log analysis and system state examination
|
||||||
|
- **Bash**: Diagnostic command execution and system investigation
|
||||||
|
- **Grep**: Error pattern detection and log analysis
|
||||||
|
- **Write**: Diagnostic reports and resolution documentation
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Bug Investigation**: Error analysis → stack trace examination → code inspection → fix validation
|
||||||
|
- **Build Troubleshooting**: Build log analysis → dependency checking → configuration validation
|
||||||
|
- **Performance Diagnosis**: Metrics analysis → bottleneck identification → optimization recommendations
|
||||||
|
- **Deployment Issues**: Environment analysis → configuration verification → service validation
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Code Bug Investigation
|
||||||
|
```
|
||||||
|
/sc:troubleshoot "Null pointer exception in user service" --type bug --trace
|
||||||
|
# Systematic analysis of error context and stack traces
|
||||||
|
# Identifies root cause and provides targeted fix recommendations
|
||||||
|
```
|
||||||
|
|
||||||
|
### Build Failure Analysis
|
||||||
|
```
|
||||||
|
/sc:troubleshoot "TypeScript compilation errors" --type build --fix
|
||||||
|
# Analyzes build logs and TypeScript configuration
|
||||||
|
# Automatically applies safe fixes for common compilation issues
|
||||||
|
```
|
||||||
|
|
||||||
|
### Performance Issue Diagnosis
|
||||||
|
```
|
||||||
|
/sc:troubleshoot "API response times degraded" --type performance
|
||||||
|
# Performance metrics analysis and bottleneck identification
|
||||||
|
# Provides optimization recommendations and monitoring guidance
|
||||||
|
```
|
||||||
|
|
||||||
|
### Deployment Problem Resolution
|
||||||
|
```
|
||||||
|
/sc:troubleshoot "Service not starting in production" --type deployment --trace
|
||||||
|
# Environment and configuration analysis
|
||||||
|
# Systematic verification of deployment requirements and dependencies
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Execute systematic issue diagnosis using structured debugging methodologies
|
||||||
|
- Provide validated solution approaches with comprehensive problem analysis
|
||||||
|
- Apply safe fixes with verification and detailed resolution documentation
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Apply risky fixes without proper analysis and user confirmation
|
||||||
|
- Modify production systems without explicit permission and safety validation
|
||||||
|
- Make architectural changes without understanding full system impact
|
||||||
97
plugins/superclaude/commands/workflow.md
Normal file
97
plugins/superclaude/commands/workflow.md
Normal file
@@ -0,0 +1,97 @@
|
|||||||
|
---
|
||||||
|
name: workflow
|
||||||
|
description: "Generate structured implementation workflows from PRDs and feature requirements"
|
||||||
|
category: orchestration
|
||||||
|
complexity: advanced
|
||||||
|
mcp-servers: [sequential, context7, magic, playwright, morphllm, serena]
|
||||||
|
personas: [architect, analyzer, frontend, backend, security, devops, project-manager]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:workflow - Implementation Workflow Generator
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- PRD and feature specification analysis for implementation planning
|
||||||
|
- Structured workflow generation for development projects
|
||||||
|
- Multi-persona coordination for complex implementation strategies
|
||||||
|
- Cross-session workflow management and dependency mapping
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:workflow [prd-file|feature-description] [--strategy systematic|agile|enterprise] [--depth shallow|normal|deep] [--parallel]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Parse PRD and feature specifications to understand implementation requirements
|
||||||
|
2. **Plan**: Generate comprehensive workflow structure with dependency mapping and task orchestration
|
||||||
|
3. **Coordinate**: Activate multiple personas for domain expertise and implementation strategy
|
||||||
|
4. **Execute**: Create structured step-by-step workflows with automated task coordination
|
||||||
|
5. **Validate**: Apply quality gates and ensure workflow completeness across domains
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Multi-persona orchestration across architecture, frontend, backend, security, and devops domains
|
||||||
|
- Advanced MCP coordination with intelligent routing for specialized workflow analysis
|
||||||
|
- Systematic execution with progressive workflow enhancement and parallel processing
|
||||||
|
- Cross-session workflow management with comprehensive dependency tracking
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Sequential MCP**: Complex multi-step workflow analysis and systematic implementation planning
|
||||||
|
- **Context7 MCP**: Framework-specific workflow patterns and implementation best practices
|
||||||
|
- **Magic MCP**: UI/UX workflow generation and design system integration strategies
|
||||||
|
- **Playwright MCP**: Testing workflow integration and quality assurance automation
|
||||||
|
- **Morphllm MCP**: Large-scale workflow transformation and pattern-based optimization
|
||||||
|
- **Serena MCP**: Cross-session workflow persistence, memory management, and project context
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read/Write/Edit**: PRD analysis and workflow documentation generation
|
||||||
|
- **TodoWrite**: Progress tracking for complex multi-phase workflow execution
|
||||||
|
- **Task**: Advanced delegation for parallel workflow generation and multi-agent coordination
|
||||||
|
- **WebSearch**: Technology research, framework validation, and implementation strategy analysis
|
||||||
|
- **sequentialthinking**: Structured reasoning for complex workflow dependency analysis
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **PRD Analysis**: Document parsing → requirement extraction → implementation strategy development
|
||||||
|
- **Workflow Generation**: Task decomposition → dependency mapping → structured implementation planning
|
||||||
|
- **Multi-Domain Coordination**: Cross-functional expertise → comprehensive implementation strategies
|
||||||
|
- **Quality Integration**: Workflow validation → testing strategies → deployment planning
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Systematic PRD Workflow
|
||||||
|
```
|
||||||
|
/sc:workflow Claudedocs/PRD/feature-spec.md --strategy systematic --depth deep
|
||||||
|
# Comprehensive PRD analysis with systematic workflow generation
|
||||||
|
# Multi-persona coordination for complete implementation strategy
|
||||||
|
```
|
||||||
|
|
||||||
|
### Agile Feature Workflow
|
||||||
|
```
|
||||||
|
/sc:workflow "user authentication system" --strategy agile --parallel
|
||||||
|
# Agile workflow generation with parallel task coordination
|
||||||
|
# Context7 and Magic MCP for framework and UI workflow patterns
|
||||||
|
```
|
||||||
|
|
||||||
|
### Enterprise Implementation Planning
|
||||||
|
```
|
||||||
|
/sc:workflow enterprise-prd.md --strategy enterprise --validate
|
||||||
|
# Enterprise-scale workflow with comprehensive validation
|
||||||
|
# Security, devops, and architect personas for compliance and scalability
|
||||||
|
```
|
||||||
|
|
||||||
|
### Cross-Session Workflow Management
|
||||||
|
```
|
||||||
|
/sc:workflow project-brief.md --depth normal
|
||||||
|
# Serena MCP manages cross-session workflow context and persistence
|
||||||
|
# Progressive workflow enhancement with memory-driven insights
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Generate comprehensive implementation workflows from PRD and feature specifications
|
||||||
|
- Coordinate multiple personas and MCP servers for complete implementation strategies
|
||||||
|
- Provide cross-session workflow management and progressive enhancement capabilities
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Execute actual implementation tasks beyond workflow planning and strategy
|
||||||
|
- Override established development processes without proper analysis and validation
|
||||||
|
- Generate workflows without comprehensive requirement analysis and dependency mapping
|
||||||
89
src/superclaude/commands/analyze.md
Normal file
89
src/superclaude/commands/analyze.md
Normal file
@@ -0,0 +1,89 @@
|
|||||||
|
---
|
||||||
|
name: analyze
|
||||||
|
description: "Comprehensive code analysis across quality, security, performance, and architecture domains"
|
||||||
|
category: utility
|
||||||
|
complexity: basic
|
||||||
|
mcp-servers: []
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:analyze - Code Analysis and Quality Assessment
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Code quality assessment requests for projects or specific components
|
||||||
|
- Security vulnerability scanning and compliance validation needs
|
||||||
|
- Performance bottleneck identification and optimization planning
|
||||||
|
- Architecture review and technical debt assessment requirements
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:analyze [target] [--focus quality|security|performance|architecture] [--depth quick|deep] [--format text|json|report]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Discover**: Categorize source files using language detection and project analysis
|
||||||
|
2. **Scan**: Apply domain-specific analysis techniques and pattern matching
|
||||||
|
3. **Evaluate**: Generate prioritized findings with severity ratings and impact assessment
|
||||||
|
4. **Recommend**: Create actionable recommendations with implementation guidance
|
||||||
|
5. **Report**: Present comprehensive analysis with metrics and improvement roadmap
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Multi-domain analysis combining static analysis and heuristic evaluation
|
||||||
|
- Intelligent file discovery and language-specific pattern recognition
|
||||||
|
- Severity-based prioritization of findings and recommendations
|
||||||
|
- Comprehensive reporting with metrics, trends, and actionable insights
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Glob**: File discovery and project structure analysis
|
||||||
|
- **Grep**: Pattern analysis and code search operations
|
||||||
|
- **Read**: Source code inspection and configuration analysis
|
||||||
|
- **Bash**: External analysis tool execution and validation
|
||||||
|
- **Write**: Report generation and metrics documentation
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Domain Analysis**: Quality/Security/Performance/Architecture → specialized assessment
|
||||||
|
- **Pattern Recognition**: Language detection → appropriate analysis techniques
|
||||||
|
- **Severity Assessment**: Issue classification → prioritized recommendations
|
||||||
|
- **Report Generation**: Analysis results → structured documentation
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Comprehensive Project Analysis
|
||||||
|
```
|
||||||
|
/sc:analyze
|
||||||
|
# Multi-domain analysis of entire project
|
||||||
|
# Generates comprehensive report with key findings and roadmap
|
||||||
|
```
|
||||||
|
|
||||||
|
### Focused Security Assessment
|
||||||
|
```
|
||||||
|
/sc:analyze src/auth --focus security --depth deep
|
||||||
|
# Deep security analysis of authentication components
|
||||||
|
# Vulnerability assessment with detailed remediation guidance
|
||||||
|
```
|
||||||
|
|
||||||
|
### Performance Optimization Analysis
|
||||||
|
```
|
||||||
|
/sc:analyze --focus performance --format report
|
||||||
|
# Performance bottleneck identification
|
||||||
|
# Generates HTML report with optimization recommendations
|
||||||
|
```
|
||||||
|
|
||||||
|
### Quick Quality Check
|
||||||
|
```
|
||||||
|
/sc:analyze src/components --focus quality --depth quick
|
||||||
|
# Rapid quality assessment of component directory
|
||||||
|
# Identifies code smells and maintainability issues
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Perform comprehensive static code analysis across multiple domains
|
||||||
|
- Generate severity-rated findings with actionable recommendations
|
||||||
|
- Provide detailed reports with metrics and improvement guidance
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Execute dynamic analysis requiring code compilation or runtime
|
||||||
|
- Modify source code or apply fixes without explicit user consent
|
||||||
|
- Analyze external dependencies beyond import and usage patterns
|
||||||
100
src/superclaude/commands/brainstorm.md
Normal file
100
src/superclaude/commands/brainstorm.md
Normal file
@@ -0,0 +1,100 @@
|
|||||||
|
---
|
||||||
|
name: brainstorm
|
||||||
|
description: "Interactive requirements discovery through Socratic dialogue and systematic exploration"
|
||||||
|
category: orchestration
|
||||||
|
complexity: advanced
|
||||||
|
mcp-servers: [sequential, context7, magic, playwright, morphllm, serena]
|
||||||
|
personas: [architect, analyzer, frontend, backend, security, devops, project-manager]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:brainstorm - Interactive Requirements Discovery
|
||||||
|
|
||||||
|
> **Context Framework Note**: This file provides behavioral instructions for Claude Code when users type `/sc:brainstorm` patterns. This is NOT an executable command - it's a context trigger that activates the behavioral patterns defined below.
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Ambiguous project ideas requiring structured exploration
|
||||||
|
- Requirements discovery and specification development needs
|
||||||
|
- Concept validation and feasibility assessment requests
|
||||||
|
- Cross-session brainstorming and iterative refinement scenarios
|
||||||
|
|
||||||
|
## Context Trigger Pattern
|
||||||
|
```
|
||||||
|
/sc:brainstorm [topic/idea] [--strategy systematic|agile|enterprise] [--depth shallow|normal|deep] [--parallel]
|
||||||
|
```
|
||||||
|
**Usage**: Type this pattern in your Claude Code conversation to activate brainstorming behavioral mode with systematic exploration and multi-persona coordination.
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Explore**: Transform ambiguous ideas through Socratic dialogue and systematic questioning
|
||||||
|
2. **Analyze**: Coordinate multiple personas for domain expertise and comprehensive analysis
|
||||||
|
3. **Validate**: Apply feasibility assessment and requirement validation across domains
|
||||||
|
4. **Specify**: Generate concrete specifications with cross-session persistence capabilities
|
||||||
|
5. **Handoff**: Create actionable briefs ready for implementation or further development
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Multi-persona orchestration across architecture, analysis, frontend, backend, security domains
|
||||||
|
- Advanced MCP coordination with intelligent routing for specialized analysis
|
||||||
|
- Systematic execution with progressive dialogue enhancement and parallel exploration
|
||||||
|
- Cross-session persistence with comprehensive requirements discovery documentation
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Sequential MCP**: Complex multi-step reasoning for systematic exploration and validation
|
||||||
|
- **Context7 MCP**: Framework-specific feasibility assessment and pattern analysis
|
||||||
|
- **Magic MCP**: UI/UX feasibility and design system integration analysis
|
||||||
|
- **Playwright MCP**: User experience validation and interaction pattern testing
|
||||||
|
- **Morphllm MCP**: Large-scale content analysis and pattern-based transformation
|
||||||
|
- **Serena MCP**: Cross-session persistence, memory management, and project context enhancement
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read/Write/Edit**: Requirements documentation and specification generation
|
||||||
|
- **TodoWrite**: Progress tracking for complex multi-phase exploration
|
||||||
|
- **Task**: Advanced delegation for parallel exploration paths and multi-agent coordination
|
||||||
|
- **WebSearch**: Market research, competitive analysis, and technology validation
|
||||||
|
- **sequentialthinking**: Structured reasoning for complex requirements analysis
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Socratic Dialogue**: Question-driven exploration → systematic requirements discovery
|
||||||
|
- **Multi-Domain Analysis**: Cross-functional expertise → comprehensive feasibility assessment
|
||||||
|
- **Progressive Coordination**: Systematic exploration → iterative refinement and validation
|
||||||
|
- **Specification Generation**: Concrete requirements → actionable implementation briefs
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Systematic Product Discovery
|
||||||
|
```
|
||||||
|
/sc:brainstorm "AI-powered project management tool" --strategy systematic --depth deep
|
||||||
|
# Multi-persona analysis: architect (system design), analyzer (feasibility), project-manager (requirements)
|
||||||
|
# Sequential MCP provides structured exploration framework
|
||||||
|
```
|
||||||
|
|
||||||
|
### Agile Feature Exploration
|
||||||
|
```
|
||||||
|
/sc:brainstorm "real-time collaboration features" --strategy agile --parallel
|
||||||
|
# Parallel exploration paths with frontend, backend, and security personas
|
||||||
|
# Context7 and Magic MCP for framework and UI pattern analysis
|
||||||
|
```
|
||||||
|
|
||||||
|
### Enterprise Solution Validation
|
||||||
|
```
|
||||||
|
/sc:brainstorm "enterprise data analytics platform" --strategy enterprise --validate
|
||||||
|
# Comprehensive validation with security, devops, and architect personas
|
||||||
|
# Serena MCP for cross-session persistence and enterprise requirements tracking
|
||||||
|
```
|
||||||
|
|
||||||
|
### Cross-Session Refinement
|
||||||
|
```
|
||||||
|
/sc:brainstorm "mobile app monetization strategy" --depth normal
|
||||||
|
# Serena MCP manages cross-session context and iterative refinement
|
||||||
|
# Progressive dialogue enhancement with memory-driven insights
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Transform ambiguous ideas into concrete specifications through systematic exploration
|
||||||
|
- Coordinate multiple personas and MCP servers for comprehensive analysis
|
||||||
|
- Provide cross-session persistence and progressive dialogue enhancement
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Make implementation decisions without proper requirements discovery
|
||||||
|
- Override user vision with prescriptive solutions during exploration phase
|
||||||
|
- Bypass systematic exploration for complex multi-domain projects
|
||||||
94
src/superclaude/commands/build.md
Normal file
94
src/superclaude/commands/build.md
Normal file
@@ -0,0 +1,94 @@
|
|||||||
|
---
|
||||||
|
name: build
|
||||||
|
description: "Build, compile, and package projects with intelligent error handling and optimization"
|
||||||
|
category: utility
|
||||||
|
complexity: enhanced
|
||||||
|
mcp-servers: [playwright]
|
||||||
|
personas: [devops-engineer]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:build - Project Building and Packaging
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Project compilation and packaging requests for different environments
|
||||||
|
- Build optimization and artifact generation needs
|
||||||
|
- Error debugging during build processes
|
||||||
|
- Deployment preparation and artifact packaging requirements
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:build [target] [--type dev|prod|test] [--clean] [--optimize] [--verbose]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Project structure, build configurations, and dependency manifests
|
||||||
|
2. **Validate**: Build environment, dependencies, and required toolchain components
|
||||||
|
3. **Execute**: Build process with real-time monitoring and error detection
|
||||||
|
4. **Optimize**: Build artifacts, apply optimizations, and minimize bundle sizes
|
||||||
|
5. **Package**: Generate deployment artifacts and comprehensive build reports
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Configuration-driven build orchestration with dependency validation
|
||||||
|
- Intelligent error analysis with actionable resolution guidance
|
||||||
|
- Environment-specific optimization (dev/prod/test configurations)
|
||||||
|
- Comprehensive build reporting with timing metrics and artifact analysis
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Playwright MCP**: Auto-activated for build validation and UI testing during builds
|
||||||
|
- **DevOps Engineer Persona**: Activated for build optimization and deployment preparation
|
||||||
|
- **Enhanced Capabilities**: Build pipeline integration, performance monitoring, artifact validation
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Bash**: Build system execution and process management
|
||||||
|
- **Read**: Configuration analysis and manifest inspection
|
||||||
|
- **Grep**: Error parsing and build log analysis
|
||||||
|
- **Glob**: Artifact discovery and validation
|
||||||
|
- **Write**: Build reports and deployment documentation
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Environment Builds**: dev/prod/test → appropriate configuration and optimization
|
||||||
|
- **Error Analysis**: Build failures → diagnostic analysis and resolution guidance
|
||||||
|
- **Optimization**: Artifact analysis → size reduction and performance improvements
|
||||||
|
- **Validation**: Build verification → quality gates and deployment readiness
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Standard Project Build
|
||||||
|
```
|
||||||
|
/sc:build
|
||||||
|
# Builds entire project using default configuration
|
||||||
|
# Generates artifacts and comprehensive build report
|
||||||
|
```
|
||||||
|
|
||||||
|
### Production Optimization Build
|
||||||
|
```
|
||||||
|
/sc:build --type prod --clean --optimize
|
||||||
|
# Clean production build with advanced optimizations
|
||||||
|
# Minification, tree-shaking, and deployment preparation
|
||||||
|
```
|
||||||
|
|
||||||
|
### Targeted Component Build
|
||||||
|
```
|
||||||
|
/sc:build frontend --verbose
|
||||||
|
# Builds specific project component with detailed output
|
||||||
|
# Real-time progress monitoring and diagnostic information
|
||||||
|
```
|
||||||
|
|
||||||
|
### Development Build with Validation
|
||||||
|
```
|
||||||
|
/sc:build --type dev --validate
|
||||||
|
# Development build with Playwright validation
|
||||||
|
# UI testing and build verification integration
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Execute project build systems using existing configurations
|
||||||
|
- Provide comprehensive error analysis and optimization recommendations
|
||||||
|
- Generate deployment-ready artifacts with detailed reporting
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Modify build system configuration or create new build scripts
|
||||||
|
- Install missing build dependencies or development tools
|
||||||
|
- Execute deployment operations beyond artifact preparation
|
||||||
81
src/superclaude/commands/business-panel.md
Normal file
81
src/superclaude/commands/business-panel.md
Normal file
@@ -0,0 +1,81 @@
|
|||||||
|
# /sc:business-panel - Business Panel Analysis System
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
---
|
||||||
|
command: "/sc:business-panel"
|
||||||
|
category: "Analysis & Strategic Planning"
|
||||||
|
purpose: "Multi-expert business analysis with adaptive interaction modes"
|
||||||
|
wave-enabled: true
|
||||||
|
performance-profile: "complex"
|
||||||
|
---
|
||||||
|
```
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
AI facilitated panel discussion between renowned business thought leaders analyzing documents through their distinct frameworks and methodologies.
|
||||||
|
|
||||||
|
## Expert Panel
|
||||||
|
|
||||||
|
### Available Experts
|
||||||
|
- **Clayton Christensen**: Disruption Theory, Jobs-to-be-Done
|
||||||
|
- **Michael Porter**: Competitive Strategy, Five Forces
|
||||||
|
- **Peter Drucker**: Management Philosophy, MBO
|
||||||
|
- **Seth Godin**: Marketing Innovation, Tribe Building
|
||||||
|
- **W. Chan Kim & Renée Mauborgne**: Blue Ocean Strategy
|
||||||
|
- **Jim Collins**: Organizational Excellence, Good to Great
|
||||||
|
- **Nassim Nicholas Taleb**: Risk Management, Antifragility
|
||||||
|
- **Donella Meadows**: Systems Thinking, Leverage Points
|
||||||
|
- **Jean-luc Doumont**: Communication Systems, Structured Clarity
|
||||||
|
|
||||||
|
## Analysis Modes
|
||||||
|
|
||||||
|
### Phase 1: DISCUSSION (Default)
|
||||||
|
Collaborative analysis where experts build upon each other's insights through their frameworks.
|
||||||
|
|
||||||
|
### Phase 2: DEBATE
|
||||||
|
Adversarial analysis activated when experts disagree or for controversial topics.
|
||||||
|
|
||||||
|
### Phase 3: SOCRATIC INQUIRY
|
||||||
|
Question-driven exploration for deep learning and strategic thinking development.
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
|
||||||
|
### Basic Usage
|
||||||
|
```bash
|
||||||
|
/sc:business-panel [document_path_or_content]
|
||||||
|
```
|
||||||
|
|
||||||
|
### Advanced Options
|
||||||
|
```bash
|
||||||
|
/sc:business-panel [content] --experts "porter,christensen,meadows"
|
||||||
|
/sc:business-panel [content] --mode debate
|
||||||
|
/sc:business-panel [content] --focus "competitive-analysis"
|
||||||
|
/sc:business-panel [content] --synthesis-only
|
||||||
|
```
|
||||||
|
|
||||||
|
### Mode Commands
|
||||||
|
- `--mode discussion` - Collaborative analysis (default)
|
||||||
|
- `--mode debate` - Challenge and stress-test ideas
|
||||||
|
- `--mode socratic` - Question-driven exploration
|
||||||
|
- `--mode adaptive` - System selects based on content
|
||||||
|
|
||||||
|
### Expert Selection
|
||||||
|
- `--experts "name1,name2,name3"` - Select specific experts
|
||||||
|
- `--focus domain` - Auto-select experts for domain
|
||||||
|
- `--all-experts` - Include all 9 experts
|
||||||
|
|
||||||
|
### Output Options
|
||||||
|
- `--synthesis-only` - Skip detailed analysis, show synthesis
|
||||||
|
- `--structured` - Use symbol system for efficiency
|
||||||
|
- `--verbose` - Full detailed analysis
|
||||||
|
- `--questions` - Focus on strategic questions
|
||||||
|
|
||||||
|
## Auto-Persona Activation
|
||||||
|
- **Auto-Activates**: Analyzer, Architect, Mentor personas
|
||||||
|
- **MCP Integration**: Sequential (primary), Context7 (business patterns)
|
||||||
|
- **Tool Orchestration**: Read, Grep, Write, MultiEdit, TodoWrite
|
||||||
|
|
||||||
|
## Integration Notes
|
||||||
|
- Compatible with all thinking flags (--think, --think-hard, --ultrathink)
|
||||||
|
- Supports wave orchestration for comprehensive business analysis
|
||||||
|
- Integrates with scribe persona for professional business communication
|
||||||
93
src/superclaude/commands/cleanup.md
Normal file
93
src/superclaude/commands/cleanup.md
Normal file
@@ -0,0 +1,93 @@
|
|||||||
|
---
|
||||||
|
name: cleanup
|
||||||
|
description: "Systematically clean up code, remove dead code, and optimize project structure"
|
||||||
|
category: workflow
|
||||||
|
complexity: standard
|
||||||
|
mcp-servers: [sequential, context7]
|
||||||
|
personas: [architect, quality, security]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:cleanup - Code and Project Cleanup
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Code maintenance and technical debt reduction requests
|
||||||
|
- Dead code removal and import optimization needs
|
||||||
|
- Project structure improvement and organization requirements
|
||||||
|
- Codebase hygiene and quality improvement initiatives
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:cleanup [target] [--type code|imports|files|all] [--safe|--aggressive] [--interactive]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Assess cleanup opportunities and safety considerations across target scope
|
||||||
|
2. **Plan**: Choose cleanup approach and activate relevant personas for domain expertise
|
||||||
|
3. **Execute**: Apply systematic cleanup with intelligent dead code detection and removal
|
||||||
|
4. **Validate**: Ensure no functionality loss through testing and safety verification
|
||||||
|
5. **Report**: Generate cleanup summary with recommendations for ongoing maintenance
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Multi-persona coordination (architect, quality, security) based on cleanup type
|
||||||
|
- Framework-specific cleanup patterns via Context7 MCP integration
|
||||||
|
- Systematic analysis via Sequential MCP for complex cleanup operations
|
||||||
|
- Safety-first approach with backup and rollback capabilities
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Sequential MCP**: Auto-activated for complex multi-step cleanup analysis and planning
|
||||||
|
- **Context7 MCP**: Framework-specific cleanup patterns and best practices
|
||||||
|
- **Persona Coordination**: Architect (structure), Quality (debt), Security (credentials)
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read/Grep/Glob**: Code analysis and pattern detection for cleanup opportunities
|
||||||
|
- **Edit/MultiEdit**: Safe code modification and structure optimization
|
||||||
|
- **TodoWrite**: Progress tracking for complex multi-file cleanup operations
|
||||||
|
- **Task**: Delegation for large-scale cleanup workflows requiring systematic coordination
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Dead Code Detection**: Usage analysis → safe removal with dependency validation
|
||||||
|
- **Import Optimization**: Dependency analysis → unused import removal and organization
|
||||||
|
- **Structure Cleanup**: Architectural analysis → file organization and modular improvements
|
||||||
|
- **Safety Validation**: Pre/during/post checks → preserve functionality throughout cleanup
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Safe Code Cleanup
|
||||||
|
```
|
||||||
|
/sc:cleanup src/ --type code --safe
|
||||||
|
# Conservative cleanup with automatic safety validation
|
||||||
|
# Removes dead code while preserving all functionality
|
||||||
|
```
|
||||||
|
|
||||||
|
### Import Optimization
|
||||||
|
```
|
||||||
|
/sc:cleanup --type imports --preview
|
||||||
|
# Analyzes and shows unused import cleanup without execution
|
||||||
|
# Framework-aware optimization via Context7 patterns
|
||||||
|
```
|
||||||
|
|
||||||
|
### Comprehensive Project Cleanup
|
||||||
|
```
|
||||||
|
/sc:cleanup --type all --interactive
|
||||||
|
# Multi-domain cleanup with user guidance for complex decisions
|
||||||
|
# Activates all personas for comprehensive analysis
|
||||||
|
```
|
||||||
|
|
||||||
|
### Framework-Specific Cleanup
|
||||||
|
```
|
||||||
|
/sc:cleanup components/ --aggressive
|
||||||
|
# Thorough cleanup with Context7 framework patterns
|
||||||
|
# Sequential analysis for complex dependency management
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Systematically clean code, remove dead code, and optimize project structure
|
||||||
|
- Provide comprehensive safety validation with backup and rollback capabilities
|
||||||
|
- Apply intelligent cleanup algorithms with framework-specific pattern recognition
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Remove code without thorough safety analysis and validation
|
||||||
|
- Override project-specific cleanup exclusions or architectural constraints
|
||||||
|
- Apply cleanup operations that compromise functionality or introduce bugs
|
||||||
88
src/superclaude/commands/design.md
Normal file
88
src/superclaude/commands/design.md
Normal file
@@ -0,0 +1,88 @@
|
|||||||
|
---
|
||||||
|
name: design
|
||||||
|
description: "Design system architecture, APIs, and component interfaces with comprehensive specifications"
|
||||||
|
category: utility
|
||||||
|
complexity: basic
|
||||||
|
mcp-servers: []
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:design - System and Component Design
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Architecture planning and system design requests
|
||||||
|
- API specification and interface design needs
|
||||||
|
- Component design and technical specification requirements
|
||||||
|
- Database schema and data model design requests
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:design [target] [--type architecture|api|component|database] [--format diagram|spec|code]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Examine target requirements and existing system context
|
||||||
|
2. **Plan**: Define design approach and structure based on type and format
|
||||||
|
3. **Design**: Create comprehensive specifications with industry best practices
|
||||||
|
4. **Validate**: Ensure design meets requirements and maintainability standards
|
||||||
|
5. **Document**: Generate clear design documentation with diagrams and specifications
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Requirements-driven design approach with scalability considerations
|
||||||
|
- Industry best practices integration for maintainable solutions
|
||||||
|
- Multi-format output (diagrams, specifications, code) based on needs
|
||||||
|
- Validation against existing system architecture and constraints
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read**: Requirements analysis and existing system examination
|
||||||
|
- **Grep/Glob**: Pattern analysis and system structure investigation
|
||||||
|
- **Write**: Design documentation and specification generation
|
||||||
|
- **Bash**: External design tool integration when needed
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Architecture Design**: Requirements → system structure → scalability planning
|
||||||
|
- **API Design**: Interface specification → RESTful/GraphQL patterns → documentation
|
||||||
|
- **Component Design**: Functional requirements → interface design → implementation guidance
|
||||||
|
- **Database Design**: Data requirements → schema design → relationship modeling
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### System Architecture Design
|
||||||
|
```
|
||||||
|
/sc:design user-management-system --type architecture --format diagram
|
||||||
|
# Creates comprehensive system architecture with component relationships
|
||||||
|
# Includes scalability considerations and best practices
|
||||||
|
```
|
||||||
|
|
||||||
|
### API Specification Design
|
||||||
|
```
|
||||||
|
/sc:design payment-api --type api --format spec
|
||||||
|
# Generates detailed API specification with endpoints and data models
|
||||||
|
# Follows RESTful design principles and industry standards
|
||||||
|
```
|
||||||
|
|
||||||
|
### Component Interface Design
|
||||||
|
```
|
||||||
|
/sc:design notification-service --type component --format code
|
||||||
|
# Designs component interfaces with clear contracts and dependencies
|
||||||
|
# Provides implementation guidance and integration patterns
|
||||||
|
```
|
||||||
|
|
||||||
|
### Database Schema Design
|
||||||
|
```
|
||||||
|
/sc:design e-commerce-db --type database --format diagram
|
||||||
|
# Creates database schema with entity relationships and constraints
|
||||||
|
# Includes normalization and performance considerations
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Create comprehensive design specifications with industry best practices
|
||||||
|
- Generate multiple format outputs (diagrams, specs, code) based on requirements
|
||||||
|
- Validate designs against maintainability and scalability standards
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Generate actual implementation code (use /sc:implement for implementation)
|
||||||
|
- Modify existing system architecture without explicit design approval
|
||||||
|
- Create designs that violate established architectural constraints
|
||||||
88
src/superclaude/commands/document.md
Normal file
88
src/superclaude/commands/document.md
Normal file
@@ -0,0 +1,88 @@
|
|||||||
|
---
|
||||||
|
name: document
|
||||||
|
description: "Generate focused documentation for components, functions, APIs, and features"
|
||||||
|
category: utility
|
||||||
|
complexity: basic
|
||||||
|
mcp-servers: []
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:document - Focused Documentation Generation
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Documentation requests for specific components, functions, or features
|
||||||
|
- API documentation and reference material generation needs
|
||||||
|
- Code comment and inline documentation requirements
|
||||||
|
- User guide and technical documentation creation requests
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:document [target] [--type inline|external|api|guide] [--style brief|detailed]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Examine target component structure, interfaces, and functionality
|
||||||
|
2. **Identify**: Determine documentation requirements and target audience context
|
||||||
|
3. **Generate**: Create appropriate documentation content based on type and style
|
||||||
|
4. **Format**: Apply consistent structure and organizational patterns
|
||||||
|
5. **Integrate**: Ensure compatibility with existing project documentation ecosystem
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Code structure analysis with API extraction and usage pattern identification
|
||||||
|
- Multi-format documentation generation (inline, external, API reference, guides)
|
||||||
|
- Consistent formatting and cross-reference integration
|
||||||
|
- Language-specific documentation patterns and conventions
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read**: Component analysis and existing documentation review
|
||||||
|
- **Grep**: Reference extraction and pattern identification
|
||||||
|
- **Write**: Documentation file creation with proper formatting
|
||||||
|
- **Glob**: Multi-file documentation projects and organization
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Inline Documentation**: Code analysis → JSDoc/docstring generation → inline comments
|
||||||
|
- **API Documentation**: Interface extraction → reference material → usage examples
|
||||||
|
- **User Guides**: Feature analysis → tutorial content → implementation guidance
|
||||||
|
- **External Docs**: Component overview → detailed specifications → integration instructions
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Inline Code Documentation
|
||||||
|
```
|
||||||
|
/sc:document src/auth/login.js --type inline
|
||||||
|
# Generates JSDoc comments with parameter and return descriptions
|
||||||
|
# Adds comprehensive inline documentation for functions and classes
|
||||||
|
```
|
||||||
|
|
||||||
|
### API Reference Generation
|
||||||
|
```
|
||||||
|
/sc:document src/api --type api --style detailed
|
||||||
|
# Creates comprehensive API documentation with endpoints and schemas
|
||||||
|
# Generates usage examples and integration guidelines
|
||||||
|
```
|
||||||
|
|
||||||
|
### User Guide Creation
|
||||||
|
```
|
||||||
|
/sc:document payment-module --type guide --style brief
|
||||||
|
# Creates user-focused documentation with practical examples
|
||||||
|
# Focuses on implementation patterns and common use cases
|
||||||
|
```
|
||||||
|
|
||||||
|
### Component Documentation
|
||||||
|
```
|
||||||
|
/sc:document components/ --type external
|
||||||
|
# Generates external documentation files for component library
|
||||||
|
# Includes props, usage examples, and integration patterns
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Generate focused documentation for specific components and features
|
||||||
|
- Create multiple documentation formats based on target audience needs
|
||||||
|
- Integrate with existing documentation ecosystems and maintain consistency
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Generate documentation without proper code analysis and context understanding
|
||||||
|
- Override existing documentation standards or project-specific conventions
|
||||||
|
- Create documentation that exposes sensitive implementation details
|
||||||
87
src/superclaude/commands/estimate.md
Normal file
87
src/superclaude/commands/estimate.md
Normal file
@@ -0,0 +1,87 @@
|
|||||||
|
---
|
||||||
|
name: estimate
|
||||||
|
description: "Provide development estimates for tasks, features, or projects with intelligent analysis"
|
||||||
|
category: special
|
||||||
|
complexity: standard
|
||||||
|
mcp-servers: [sequential, context7]
|
||||||
|
personas: [architect, performance, project-manager]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:estimate - Development Estimation
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Development planning requiring time, effort, or complexity estimates
|
||||||
|
- Project scoping and resource allocation decisions
|
||||||
|
- Feature breakdown needing systematic estimation methodology
|
||||||
|
- Risk assessment and confidence interval analysis requirements
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:estimate [target] [--type time|effort|complexity] [--unit hours|days|weeks] [--breakdown]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Examine scope, complexity factors, dependencies, and framework patterns
|
||||||
|
2. **Calculate**: Apply estimation methodology with historical benchmarks and complexity scoring
|
||||||
|
3. **Validate**: Cross-reference estimates with project patterns and domain expertise
|
||||||
|
4. **Present**: Provide detailed breakdown with confidence intervals and risk assessment
|
||||||
|
5. **Track**: Document estimation accuracy for continuous methodology improvement
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Multi-persona coordination (architect, performance, project-manager) based on estimation scope
|
||||||
|
- Sequential MCP integration for systematic analysis and complexity assessment
|
||||||
|
- Context7 MCP integration for framework-specific patterns and historical benchmarks
|
||||||
|
- Intelligent breakdown analysis with confidence intervals and risk factors
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Sequential MCP**: Complex multi-step estimation analysis and systematic complexity assessment
|
||||||
|
- **Context7 MCP**: Framework-specific estimation patterns and historical benchmark data
|
||||||
|
- **Persona Coordination**: Architect (design complexity), Performance (optimization effort), Project Manager (timeline)
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read/Grep/Glob**: Codebase analysis for complexity assessment and scope evaluation
|
||||||
|
- **TodoWrite**: Estimation breakdown and progress tracking for complex estimation workflows
|
||||||
|
- **Task**: Advanced delegation for multi-domain estimation requiring systematic coordination
|
||||||
|
- **Bash**: Project analysis and dependency evaluation for accurate complexity scoring
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Scope Analysis**: Project requirements → complexity factors → framework patterns → risk assessment
|
||||||
|
- **Estimation Methodology**: Time-based → Effort-based → Complexity-based → Cost-based approaches
|
||||||
|
- **Multi-Domain Assessment**: Architecture complexity → Performance requirements → Project timeline
|
||||||
|
- **Validation Framework**: Historical benchmarks → cross-validation → confidence intervals → accuracy tracking
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Feature Development Estimation
|
||||||
|
```
|
||||||
|
/sc:estimate "user authentication system" --type time --unit days --breakdown
|
||||||
|
# Systematic analysis: Database design (2 days) + Backend API (3 days) + Frontend UI (2 days) + Testing (1 day)
|
||||||
|
# Total: 8 days with 85% confidence interval
|
||||||
|
```
|
||||||
|
|
||||||
|
### Project Complexity Assessment
|
||||||
|
```
|
||||||
|
/sc:estimate "migrate monolith to microservices" --type complexity --breakdown
|
||||||
|
# Architecture complexity analysis with risk factors and dependency mapping
|
||||||
|
# Multi-persona coordination for comprehensive assessment
|
||||||
|
```
|
||||||
|
|
||||||
|
### Performance Optimization Effort
|
||||||
|
```
|
||||||
|
/sc:estimate "optimize application performance" --type effort --unit hours
|
||||||
|
# Performance persona analysis with benchmark comparisons
|
||||||
|
# Effort breakdown by optimization category and expected impact
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Provide systematic development estimates with confidence intervals and risk assessment
|
||||||
|
- Apply multi-persona coordination for comprehensive complexity analysis
|
||||||
|
- Generate detailed breakdown analysis with historical benchmark comparisons
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Guarantee estimate accuracy without proper scope analysis and validation
|
||||||
|
- Provide estimates without appropriate domain expertise and complexity assessment
|
||||||
|
- Override historical benchmarks without clear justification and analysis
|
||||||
|
|
||||||
92
src/superclaude/commands/explain.md
Normal file
92
src/superclaude/commands/explain.md
Normal file
@@ -0,0 +1,92 @@
|
|||||||
|
---
|
||||||
|
name: explain
|
||||||
|
description: "Provide clear explanations of code, concepts, and system behavior with educational clarity"
|
||||||
|
category: workflow
|
||||||
|
complexity: standard
|
||||||
|
mcp-servers: [sequential, context7]
|
||||||
|
personas: [educator, architect, security]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:explain - Code and Concept Explanation
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Code understanding and documentation requests for complex functionality
|
||||||
|
- System behavior explanation needs for architectural components
|
||||||
|
- Educational content generation for knowledge transfer
|
||||||
|
- Framework-specific concept clarification requirements
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:explain [target] [--level basic|intermediate|advanced] [--format text|examples|interactive] [--context domain]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Examine target code, concept, or system for comprehensive understanding
|
||||||
|
2. **Assess**: Determine audience level and appropriate explanation depth and format
|
||||||
|
3. **Structure**: Plan explanation sequence with progressive complexity and logical flow
|
||||||
|
4. **Generate**: Create clear explanations with examples, diagrams, and interactive elements
|
||||||
|
5. **Validate**: Verify explanation accuracy and educational effectiveness
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Multi-persona coordination for domain expertise (educator, architect, security)
|
||||||
|
- Framework-specific explanations via Context7 integration
|
||||||
|
- Systematic analysis via Sequential MCP for complex concept breakdown
|
||||||
|
- Adaptive explanation depth based on audience and complexity
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Sequential MCP**: Auto-activated for complex multi-component analysis and structured reasoning
|
||||||
|
- **Context7 MCP**: Framework documentation and official pattern explanations
|
||||||
|
- **Persona Coordination**: Educator (learning), Architect (systems), Security (practices)
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read/Grep/Glob**: Code analysis and pattern identification for explanation content
|
||||||
|
- **TodoWrite**: Progress tracking for complex multi-part explanations
|
||||||
|
- **Task**: Delegation for comprehensive explanation workflows requiring systematic breakdown
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Progressive Learning**: Basic concepts → intermediate details → advanced implementation
|
||||||
|
- **Framework Integration**: Context7 documentation → accurate official patterns and practices
|
||||||
|
- **Multi-Domain Analysis**: Technical accuracy + educational clarity + security awareness
|
||||||
|
- **Interactive Explanation**: Static content → examples → interactive exploration
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Basic Code Explanation
|
||||||
|
```
|
||||||
|
/sc:explain authentication.js --level basic
|
||||||
|
# Clear explanation with practical examples for beginners
|
||||||
|
# Educator persona provides learning-optimized structure
|
||||||
|
```
|
||||||
|
|
||||||
|
### Framework Concept Explanation
|
||||||
|
```
|
||||||
|
/sc:explain react-hooks --level intermediate --context react
|
||||||
|
# Context7 integration for official React documentation patterns
|
||||||
|
# Structured explanation with progressive complexity
|
||||||
|
```
|
||||||
|
|
||||||
|
### System Architecture Explanation
|
||||||
|
```
|
||||||
|
/sc:explain microservices-system --level advanced --format interactive
|
||||||
|
# Architect persona explains system design and patterns
|
||||||
|
# Interactive exploration with Sequential analysis breakdown
|
||||||
|
```
|
||||||
|
|
||||||
|
### Security Concept Explanation
|
||||||
|
```
|
||||||
|
/sc:explain jwt-authentication --context security --level basic
|
||||||
|
# Security persona explains authentication concepts and best practices
|
||||||
|
# Framework-agnostic security principles with practical examples
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Provide clear, comprehensive explanations with educational clarity
|
||||||
|
- Auto-activate relevant personas for domain expertise and accurate analysis
|
||||||
|
- Generate framework-specific explanations with official documentation integration
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Generate explanations without thorough analysis and accuracy verification
|
||||||
|
- Override project-specific documentation standards or reveal sensitive details
|
||||||
|
- Bypass established explanation validation or educational quality requirements
|
||||||
80
src/superclaude/commands/git.md
Normal file
80
src/superclaude/commands/git.md
Normal file
@@ -0,0 +1,80 @@
|
|||||||
|
---
|
||||||
|
name: git
|
||||||
|
description: "Git operations with intelligent commit messages and workflow optimization"
|
||||||
|
category: utility
|
||||||
|
complexity: basic
|
||||||
|
mcp-servers: []
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:git - Git Operations
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Git repository operations: status, add, commit, push, pull, branch
|
||||||
|
- Need for intelligent commit message generation
|
||||||
|
- Repository workflow optimization requests
|
||||||
|
- Branch management and merge operations
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:git [operation] [args] [--smart-commit] [--interactive]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Check repository state and working directory changes
|
||||||
|
2. **Validate**: Ensure operation is appropriate for current Git context
|
||||||
|
3. **Execute**: Run Git command with intelligent automation
|
||||||
|
4. **Optimize**: Apply smart commit messages and workflow patterns
|
||||||
|
5. **Report**: Provide status and next steps guidance
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Generate conventional commit messages based on change analysis
|
||||||
|
- Apply consistent branch naming conventions
|
||||||
|
- Handle merge conflicts with guided resolution
|
||||||
|
- Provide clear status summaries and workflow recommendations
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Bash**: Git command execution and repository operations
|
||||||
|
- **Read**: Repository state analysis and configuration review
|
||||||
|
- **Grep**: Log parsing and status analysis
|
||||||
|
- **Write**: Commit message generation and documentation
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Smart Commits**: Analyze changes → generate conventional commit message
|
||||||
|
- **Status Analysis**: Repository state → actionable recommendations
|
||||||
|
- **Branch Strategy**: Consistent naming and workflow enforcement
|
||||||
|
- **Error Recovery**: Conflict resolution and state restoration guidance
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Smart Status Analysis
|
||||||
|
```
|
||||||
|
/sc:git status
|
||||||
|
# Analyzes repository state with change summary
|
||||||
|
# Provides next steps and workflow recommendations
|
||||||
|
```
|
||||||
|
|
||||||
|
### Intelligent Commit
|
||||||
|
```
|
||||||
|
/sc:git commit --smart-commit
|
||||||
|
# Generates conventional commit message from change analysis
|
||||||
|
# Applies best practices and consistent formatting
|
||||||
|
```
|
||||||
|
|
||||||
|
### Interactive Operations
|
||||||
|
```
|
||||||
|
/sc:git merge feature-branch --interactive
|
||||||
|
# Guided merge with conflict resolution assistance
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Execute Git operations with intelligent automation
|
||||||
|
- Generate conventional commit messages from change analysis
|
||||||
|
- Provide workflow optimization and best practice guidance
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Modify repository configuration without explicit authorization
|
||||||
|
- Execute destructive operations without confirmation
|
||||||
|
- Handle complex merges requiring manual intervention
|
||||||
148
src/superclaude/commands/help.md
Normal file
148
src/superclaude/commands/help.md
Normal file
@@ -0,0 +1,148 @@
|
|||||||
|
---
|
||||||
|
name: help
|
||||||
|
description: "List all available /sc commands and their functionality"
|
||||||
|
category: utility
|
||||||
|
complexity: low
|
||||||
|
mcp-servers: []
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:help - Command Reference Documentation
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Command discovery and reference lookup requests
|
||||||
|
- Framework exploration and capability understanding needs
|
||||||
|
- Documentation requests for available SuperClaude commands
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Display**: Present complete command list with descriptions
|
||||||
|
2. **Complete**: End interaction after displaying information
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Information display only - no execution or implementation
|
||||||
|
- Reference documentation mode without action triggers
|
||||||
|
|
||||||
|
Here is a complete list of all available SuperClaude (`/sc`) commands.
|
||||||
|
|
||||||
|
| Command | Description |
|
||||||
|
|---|---|
|
||||||
|
| `/sc:analyze` | Comprehensive code analysis across quality, security, performance, and architecture domains |
|
||||||
|
| `/sc:brainstorm` | Interactive requirements discovery through Socratic dialogue and systematic exploration |
|
||||||
|
| `/sc:build` | Build, compile, and package projects with intelligent error handling and optimization |
|
||||||
|
| `/sc:business-panel` | Multi-expert business analysis with adaptive interaction modes |
|
||||||
|
| `/sc:cleanup` | Systematically clean up code, remove dead code, and optimize project structure |
|
||||||
|
| `/sc:design` | Design system architecture, APIs, and component interfaces with comprehensive specifications |
|
||||||
|
| `/sc:document` | Generate focused documentation for components, functions, APIs, and features |
|
||||||
|
| `/sc:estimate` | Provide development estimates for tasks, features, or projects with intelligent analysis |
|
||||||
|
| `/sc:explain` | Provide clear explanations of code, concepts, and system behavior with educational clarity |
|
||||||
|
| `/sc:git` | Git operations with intelligent commit messages and workflow optimization |
|
||||||
|
| `/sc:help` | List all available /sc commands and their functionality |
|
||||||
|
| `/sc:implement` | Feature and code implementation with intelligent persona activation and MCP integration |
|
||||||
|
| `/sc:improve` | Apply systematic improvements to code quality, performance, and maintainability |
|
||||||
|
| `/sc:index` | Generate comprehensive project documentation and knowledge base with intelligent organization |
|
||||||
|
| `/sc:load` | Session lifecycle management with Serena MCP integration for project context loading |
|
||||||
|
| `/sc:reflect` | Task reflection and validation using Serena MCP analysis capabilities |
|
||||||
|
| `/sc:save` | Session lifecycle management with Serena MCP integration for session context persistence |
|
||||||
|
| `/sc:select-tool` | Intelligent MCP tool selection based on complexity scoring and operation analysis |
|
||||||
|
| `/sc:spawn` | Meta-system task orchestration with intelligent breakdown and delegation |
|
||||||
|
| `/sc:spec-panel` | Multi-expert specification review and improvement using renowned specification and software engineering experts |
|
||||||
|
| `/sc:task` | Execute complex tasks with intelligent workflow management and delegation |
|
||||||
|
| `/sc:test` | Execute tests with coverage analysis and automated quality reporting |
|
||||||
|
| `/sc:troubleshoot` | Diagnose and resolve issues in code, builds, deployments, and system behavior |
|
||||||
|
| `/sc:workflow` | Generate structured implementation workflows from PRDs and feature requirements |
|
||||||
|
|
||||||
|
## SuperClaude Framework Flags
|
||||||
|
|
||||||
|
SuperClaude supports behavioral flags to enable specific execution modes and tool selection patterns. Use these flags with any `/sc` command to customize behavior.
|
||||||
|
|
||||||
|
### Mode Activation Flags
|
||||||
|
|
||||||
|
| Flag | Trigger | Behavior |
|
||||||
|
|------|---------|----------|
|
||||||
|
| `--brainstorm` | Vague project requests, exploration keywords | Activate collaborative discovery mindset, ask probing questions |
|
||||||
|
| `--introspect` | Self-analysis requests, error recovery | Expose thinking process with transparency markers |
|
||||||
|
| `--task-manage` | Multi-step operations (>3 steps) | Orchestrate through delegation, systematic organization |
|
||||||
|
| `--orchestrate` | Multi-tool operations, parallel execution | Optimize tool selection matrix, enable parallel thinking |
|
||||||
|
| `--token-efficient` | Context usage >75%, large-scale operations | Symbol-enhanced communication, 30-50% token reduction |
|
||||||
|
|
||||||
|
### MCP Server Flags
|
||||||
|
|
||||||
|
| Flag | Trigger | Behavior |
|
||||||
|
|------|---------|----------|
|
||||||
|
| `--c7` / `--context7` | Library imports, framework questions | Enable Context7 for curated documentation lookup |
|
||||||
|
| `--seq` / `--sequential` | Complex debugging, system design | Enable Sequential for structured multi-step reasoning |
|
||||||
|
| `--magic` | UI component requests (/ui, /21) | Enable Magic for modern UI generation from 21st.dev |
|
||||||
|
| `--morph` / `--morphllm` | Bulk code transformations | Enable Morphllm for efficient multi-file pattern application |
|
||||||
|
| `--serena` | Symbol operations, project memory | Enable Serena for semantic understanding and session persistence |
|
||||||
|
| `--play` / `--playwright` | Browser testing, E2E scenarios | Enable Playwright for real browser automation and testing |
|
||||||
|
| `--all-mcp` | Maximum complexity scenarios | Enable all MCP servers for comprehensive capability |
|
||||||
|
| `--no-mcp` | Native-only execution needs | Disable all MCP servers, use native tools |
|
||||||
|
|
||||||
|
### Analysis Depth Flags
|
||||||
|
|
||||||
|
| Flag | Trigger | Behavior |
|
||||||
|
|------|---------|----------|
|
||||||
|
| `--think` | Multi-component analysis needs | Standard structured analysis (~4K tokens), enables Sequential |
|
||||||
|
| `--think-hard` | Architectural analysis, system-wide dependencies | Deep analysis (~10K tokens), enables Sequential + Context7 |
|
||||||
|
| `--ultrathink` | Critical system redesign, legacy modernization | Maximum depth analysis (~32K tokens), enables all MCP servers |
|
||||||
|
|
||||||
|
### Execution Control Flags
|
||||||
|
|
||||||
|
| Flag | Trigger | Behavior |
|
||||||
|
|------|---------|----------|
|
||||||
|
| `--delegate [auto\|files\|folders]` | >7 directories OR >50 files | Enable sub-agent parallel processing with intelligent routing |
|
||||||
|
| `--concurrency [n]` | Resource optimization needs | Control max concurrent operations (range: 1-15) |
|
||||||
|
| `--loop` | Improvement keywords (polish, refine, enhance) | Enable iterative improvement cycles with validation gates |
|
||||||
|
| `--iterations [n]` | Specific improvement cycle requirements | Set improvement cycle count (range: 1-10) |
|
||||||
|
| `--validate` | Risk score >0.7, resource usage >75% | Pre-execution risk assessment and validation gates |
|
||||||
|
| `--safe-mode` | Resource usage >85%, production environment | Maximum validation, conservative execution |
|
||||||
|
|
||||||
|
### Output Optimization Flags
|
||||||
|
|
||||||
|
| Flag | Trigger | Behavior |
|
||||||
|
|------|---------|----------|
|
||||||
|
| `--uc` / `--ultracompressed` | Context pressure, efficiency requirements | Symbol communication system, 30-50% token reduction |
|
||||||
|
| `--scope [file\|module\|project\|system]` | Analysis boundary needs | Define operational scope and analysis depth |
|
||||||
|
| `--focus [performance\|security\|quality\|architecture\|accessibility\|testing]` | Domain-specific optimization | Target specific analysis domain and expertise application |
|
||||||
|
|
||||||
|
### Flag Priority Rules
|
||||||
|
|
||||||
|
- **Safety First**: `--safe-mode` > `--validate` > optimization flags
|
||||||
|
- **Explicit Override**: User flags > auto-detection
|
||||||
|
- **Depth Hierarchy**: `--ultrathink` > `--think-hard` > `--think`
|
||||||
|
- **MCP Control**: `--no-mcp` overrides all individual MCP flags
|
||||||
|
- **Scope Precedence**: system > project > module > file
|
||||||
|
|
||||||
|
### Usage Examples
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# Deep analysis with Context7 enabled
|
||||||
|
/sc:analyze --think-hard --context7 src/
|
||||||
|
|
||||||
|
# UI development with Magic and validation
|
||||||
|
/sc:implement --magic --validate "Add user dashboard"
|
||||||
|
|
||||||
|
# Token-efficient task management
|
||||||
|
/sc:task --token-efficient --delegate auto "Refactor authentication system"
|
||||||
|
|
||||||
|
# Safe production deployment
|
||||||
|
/sc:build --safe-mode --validate --focus security
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Display comprehensive list of available SuperClaude commands
|
||||||
|
- Provide clear descriptions of each command's functionality
|
||||||
|
- Present information in readable tabular format
|
||||||
|
- Show all available SuperClaude framework flags and their usage
|
||||||
|
- Provide flag usage examples and priority rules
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Execute any commands or create any files
|
||||||
|
- Activate implementation modes or start projects
|
||||||
|
- Engage TodoWrite or any execution tools
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
**Note:** This list is manually generated and may become outdated. If you suspect it is inaccurate, please consider regenerating it or contacting a maintainer.
|
||||||
97
src/superclaude/commands/implement.md
Normal file
97
src/superclaude/commands/implement.md
Normal file
@@ -0,0 +1,97 @@
|
|||||||
|
---
|
||||||
|
name: implement
|
||||||
|
description: "Feature and code implementation with intelligent persona activation and MCP integration"
|
||||||
|
category: workflow
|
||||||
|
complexity: standard
|
||||||
|
mcp-servers: [context7, sequential, magic, playwright]
|
||||||
|
personas: [architect, frontend, backend, security, qa-specialist]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:implement - Feature Implementation
|
||||||
|
|
||||||
|
> **Context Framework Note**: This behavioral instruction activates when Claude Code users type `/sc:implement` patterns. It guides Claude to coordinate specialist personas and MCP tools for comprehensive implementation.
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Feature development requests for components, APIs, or complete functionality
|
||||||
|
- Code implementation needs with framework-specific requirements
|
||||||
|
- Multi-domain development requiring coordinated expertise
|
||||||
|
- Implementation projects requiring testing and validation integration
|
||||||
|
|
||||||
|
## Context Trigger Pattern
|
||||||
|
```
|
||||||
|
/sc:implement [feature-description] [--type component|api|service|feature] [--framework react|vue|express] [--safe] [--with-tests]
|
||||||
|
```
|
||||||
|
**Usage**: Type this in Claude Code conversation to activate implementation behavioral mode with coordinated expertise and systematic development approach.
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Examine implementation requirements and detect technology context
|
||||||
|
2. **Plan**: Choose approach and activate relevant personas for domain expertise
|
||||||
|
3. **Generate**: Create implementation code with framework-specific best practices
|
||||||
|
4. **Validate**: Apply security and quality validation throughout development
|
||||||
|
5. **Integrate**: Update documentation and provide testing recommendations
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Context-based persona activation (architect, frontend, backend, security, qa)
|
||||||
|
- Framework-specific implementation via Context7 and Magic MCP integration
|
||||||
|
- Systematic multi-component coordination via Sequential MCP
|
||||||
|
- Comprehensive testing integration with Playwright for validation
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Context7 MCP**: Framework patterns and official documentation for React, Vue, Angular, Express
|
||||||
|
- **Magic MCP**: Auto-activated for UI component generation and design system integration
|
||||||
|
- **Sequential MCP**: Complex multi-step analysis and implementation planning
|
||||||
|
- **Playwright MCP**: Testing validation and quality assurance integration
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Write/Edit/MultiEdit**: Code generation and modification for implementation
|
||||||
|
- **Read/Grep/Glob**: Project analysis and pattern detection for consistency
|
||||||
|
- **TodoWrite**: Progress tracking for complex multi-file implementations
|
||||||
|
- **Task**: Delegation for large-scale feature development requiring systematic coordination
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Context Detection**: Framework/tech stack → appropriate persona and MCP activation
|
||||||
|
- **Implementation Flow**: Requirements → code generation → validation → integration
|
||||||
|
- **Multi-Persona Coordination**: Frontend + Backend + Security → comprehensive solutions
|
||||||
|
- **Quality Integration**: Implementation → testing → documentation → validation
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### React Component Implementation
|
||||||
|
```
|
||||||
|
/sc:implement user profile component --type component --framework react
|
||||||
|
# Magic MCP generates UI component with design system integration
|
||||||
|
# Frontend persona ensures best practices and accessibility
|
||||||
|
```
|
||||||
|
|
||||||
|
### API Service Implementation
|
||||||
|
```
|
||||||
|
/sc:implement user authentication API --type api --safe --with-tests
|
||||||
|
# Backend persona handles server-side logic and data processing
|
||||||
|
# Security persona ensures authentication best practices
|
||||||
|
```
|
||||||
|
|
||||||
|
### Full-Stack Feature
|
||||||
|
```
|
||||||
|
/sc:implement payment processing system --type feature --with-tests
|
||||||
|
# Multi-persona coordination: architect, frontend, backend, security
|
||||||
|
# Sequential MCP breaks down complex implementation steps
|
||||||
|
```
|
||||||
|
|
||||||
|
### Framework-Specific Implementation
|
||||||
|
```
|
||||||
|
/sc:implement dashboard widget --framework vue
|
||||||
|
# Context7 MCP provides Vue-specific patterns and documentation
|
||||||
|
# Framework-appropriate implementation with official best practices
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Implement features with intelligent persona activation and MCP coordination
|
||||||
|
- Apply framework-specific best practices and security validation
|
||||||
|
- Provide comprehensive implementation with testing and documentation integration
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Make architectural decisions without appropriate persona consultation
|
||||||
|
- Implement features conflicting with security policies or architectural constraints
|
||||||
|
- Override user-specified safety constraints or bypass quality gates
|
||||||
94
src/superclaude/commands/improve.md
Normal file
94
src/superclaude/commands/improve.md
Normal file
@@ -0,0 +1,94 @@
|
|||||||
|
---
|
||||||
|
name: improve
|
||||||
|
description: "Apply systematic improvements to code quality, performance, and maintainability"
|
||||||
|
category: workflow
|
||||||
|
complexity: standard
|
||||||
|
mcp-servers: [sequential, context7]
|
||||||
|
personas: [architect, performance, quality, security]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:improve - Code Improvement
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Code quality enhancement and refactoring requests
|
||||||
|
- Performance optimization and bottleneck resolution needs
|
||||||
|
- Maintainability improvements and technical debt reduction
|
||||||
|
- Best practices application and coding standards enforcement
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:improve [target] [--type quality|performance|maintainability|style] [--safe] [--interactive]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Examine codebase for improvement opportunities and quality issues
|
||||||
|
2. **Plan**: Choose improvement approach and activate relevant personas for expertise
|
||||||
|
3. **Execute**: Apply systematic improvements with domain-specific best practices
|
||||||
|
4. **Validate**: Ensure improvements preserve functionality and meet quality standards
|
||||||
|
5. **Document**: Generate improvement summary and recommendations for future work
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Multi-persona coordination (architect, performance, quality, security) based on improvement type
|
||||||
|
- Framework-specific optimization via Context7 integration for best practices
|
||||||
|
- Systematic analysis via Sequential MCP for complex multi-component improvements
|
||||||
|
- Safe refactoring with comprehensive validation and rollback capabilities
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Sequential MCP**: Auto-activated for complex multi-step improvement analysis and planning
|
||||||
|
- **Context7 MCP**: Framework-specific best practices and optimization patterns
|
||||||
|
- **Persona Coordination**: Architect (structure), Performance (speed), Quality (maintainability), Security (safety)
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read/Grep/Glob**: Code analysis and improvement opportunity identification
|
||||||
|
- **Edit/MultiEdit**: Safe code modification and systematic refactoring
|
||||||
|
- **TodoWrite**: Progress tracking for complex multi-file improvement operations
|
||||||
|
- **Task**: Delegation for large-scale improvement workflows requiring systematic coordination
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Quality Improvement**: Code analysis → technical debt identification → refactoring application
|
||||||
|
- **Performance Optimization**: Profiling analysis → bottleneck identification → optimization implementation
|
||||||
|
- **Maintainability Enhancement**: Structure analysis → complexity reduction → documentation improvement
|
||||||
|
- **Security Hardening**: Vulnerability analysis → security pattern application → validation verification
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Code Quality Enhancement
|
||||||
|
```
|
||||||
|
/sc:improve src/ --type quality --safe
|
||||||
|
# Systematic quality analysis with safe refactoring application
|
||||||
|
# Improves code structure, reduces technical debt, enhances readability
|
||||||
|
```
|
||||||
|
|
||||||
|
### Performance Optimization
|
||||||
|
```
|
||||||
|
/sc:improve api-endpoints --type performance --interactive
|
||||||
|
# Performance persona analyzes bottlenecks and optimization opportunities
|
||||||
|
# Interactive guidance for complex performance improvement decisions
|
||||||
|
```
|
||||||
|
|
||||||
|
### Maintainability Improvements
|
||||||
|
```
|
||||||
|
/sc:improve legacy-modules --type maintainability --preview
|
||||||
|
# Architect persona analyzes structure and suggests maintainability improvements
|
||||||
|
# Preview mode shows changes before application for review
|
||||||
|
```
|
||||||
|
|
||||||
|
### Security Hardening
|
||||||
|
```
|
||||||
|
/sc:improve auth-service --type security --validate
|
||||||
|
# Security persona identifies vulnerabilities and applies security patterns
|
||||||
|
# Comprehensive validation ensures security improvements are effective
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Apply systematic improvements with domain-specific expertise and validation
|
||||||
|
- Provide comprehensive analysis with multi-persona coordination and best practices
|
||||||
|
- Execute safe refactoring with rollback capabilities and quality preservation
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Apply risky improvements without proper analysis and user confirmation
|
||||||
|
- Make architectural changes without understanding full system impact
|
||||||
|
- Override established coding standards or project-specific conventions
|
||||||
|
|
||||||
86
src/superclaude/commands/index.md
Normal file
86
src/superclaude/commands/index.md
Normal file
@@ -0,0 +1,86 @@
|
|||||||
|
---
|
||||||
|
name: index
|
||||||
|
description: "Generate comprehensive project documentation and knowledge base with intelligent organization"
|
||||||
|
category: special
|
||||||
|
complexity: standard
|
||||||
|
mcp-servers: [sequential, context7]
|
||||||
|
personas: [architect, scribe, quality]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:index - Project Documentation
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Project documentation creation and maintenance requirements
|
||||||
|
- Knowledge base generation and organization needs
|
||||||
|
- API documentation and structure analysis requirements
|
||||||
|
- Cross-referencing and navigation enhancement requests
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:index [target] [--type docs|api|structure|readme] [--format md|json|yaml]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Examine project structure and identify key documentation components
|
||||||
|
2. **Organize**: Apply intelligent organization patterns and cross-referencing strategies
|
||||||
|
3. **Generate**: Create comprehensive documentation with framework-specific patterns
|
||||||
|
4. **Validate**: Ensure documentation completeness and quality standards
|
||||||
|
5. **Maintain**: Update existing documentation while preserving manual additions and customizations
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Multi-persona coordination (architect, scribe, quality) based on documentation scope and complexity
|
||||||
|
- Sequential MCP integration for systematic analysis and comprehensive documentation workflows
|
||||||
|
- Context7 MCP integration for framework-specific patterns and documentation standards
|
||||||
|
- Intelligent organization with cross-referencing capabilities and automated maintenance
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Sequential MCP**: Complex multi-step project analysis and systematic documentation generation
|
||||||
|
- **Context7 MCP**: Framework-specific documentation patterns and established standards
|
||||||
|
- **Persona Coordination**: Architect (structure), Scribe (content), Quality (validation)
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read/Grep/Glob**: Project structure analysis and content extraction for documentation generation
|
||||||
|
- **Write**: Documentation creation with intelligent organization and cross-referencing
|
||||||
|
- **TodoWrite**: Progress tracking for complex multi-component documentation workflows
|
||||||
|
- **Task**: Advanced delegation for large-scale documentation requiring systematic coordination
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Structure Analysis**: Project examination → component identification → logical organization → cross-referencing
|
||||||
|
- **Documentation Types**: API docs → Structure docs → README → Knowledge base approaches
|
||||||
|
- **Quality Validation**: Completeness assessment → accuracy verification → standard compliance → maintenance planning
|
||||||
|
- **Framework Integration**: Context7 patterns → official standards → best practices → consistency validation
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Project Structure Documentation
|
||||||
|
```
|
||||||
|
/sc:index project-root --type structure --format md
|
||||||
|
# Comprehensive project structure documentation with intelligent organization
|
||||||
|
# Creates navigable structure with cross-references and component relationships
|
||||||
|
```
|
||||||
|
|
||||||
|
### API Documentation Generation
|
||||||
|
```
|
||||||
|
/sc:index src/api --type api --format json
|
||||||
|
# API documentation with systematic analysis and validation
|
||||||
|
# Scribe and quality personas ensure completeness and accuracy
|
||||||
|
```
|
||||||
|
|
||||||
|
### Knowledge Base Creation
|
||||||
|
```
|
||||||
|
/sc:index . --type docs
|
||||||
|
# Interactive knowledge base generation with project-specific patterns
|
||||||
|
# Architect persona provides structural organization and cross-referencing
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Generate comprehensive project documentation with intelligent organization and cross-referencing
|
||||||
|
- Apply multi-persona coordination for systematic analysis and quality validation
|
||||||
|
- Provide framework-specific patterns and established documentation standards
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Override existing manual documentation without explicit update permission
|
||||||
|
- Generate documentation without appropriate project structure analysis and validation
|
||||||
|
- Bypass established documentation standards or quality requirements
|
||||||
93
src/superclaude/commands/load.md
Normal file
93
src/superclaude/commands/load.md
Normal file
@@ -0,0 +1,93 @@
|
|||||||
|
---
|
||||||
|
name: load
|
||||||
|
description: "Session lifecycle management with Serena MCP integration for project context loading"
|
||||||
|
category: session
|
||||||
|
complexity: standard
|
||||||
|
mcp-servers: [serena]
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:load - Project Context Loading
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Session initialization and project context loading requests
|
||||||
|
- Cross-session persistence and memory retrieval needs
|
||||||
|
- Project activation and context management requirements
|
||||||
|
- Session lifecycle management and checkpoint loading scenarios
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:load [target] [--type project|config|deps|checkpoint] [--refresh] [--analyze]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Initialize**: Establish Serena MCP connection and session context management
|
||||||
|
2. **Discover**: Analyze project structure and identify context loading requirements
|
||||||
|
3. **Load**: Retrieve project memories, checkpoints, and cross-session persistence data
|
||||||
|
4. **Activate**: Establish project context and prepare for development workflow
|
||||||
|
5. **Validate**: Ensure loaded context integrity and session readiness
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Serena MCP integration for memory management and cross-session persistence
|
||||||
|
- Project activation with comprehensive context loading and validation
|
||||||
|
- Performance-critical operation with <500ms initialization target
|
||||||
|
- Session lifecycle management with checkpoint and memory coordination
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Serena MCP**: Mandatory integration for project activation, memory retrieval, and session management
|
||||||
|
- **Memory Operations**: Cross-session persistence, checkpoint loading, and context restoration
|
||||||
|
- **Performance Critical**: <200ms for core operations, <1s for checkpoint creation
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **activate_project**: Core project activation and context establishment
|
||||||
|
- **list_memories/read_memory**: Memory retrieval and session context loading
|
||||||
|
- **Read/Grep/Glob**: Project structure analysis and configuration discovery
|
||||||
|
- **Write**: Session context documentation and checkpoint creation
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Project Activation**: Directory analysis → memory retrieval → context establishment
|
||||||
|
- **Session Restoration**: Checkpoint loading → context validation → workflow preparation
|
||||||
|
- **Memory Management**: Cross-session persistence → context continuity → development efficiency
|
||||||
|
- **Performance Critical**: Fast initialization → immediate productivity → session readiness
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Basic Project Loading
|
||||||
|
```
|
||||||
|
/sc:load
|
||||||
|
# Loads current directory project context with Serena memory integration
|
||||||
|
# Establishes session context and prepares for development workflow
|
||||||
|
```
|
||||||
|
|
||||||
|
### Specific Project Loading
|
||||||
|
```
|
||||||
|
/sc:load /path/to/project --type project --analyze
|
||||||
|
# Loads specific project with comprehensive analysis
|
||||||
|
# Activates project context and retrieves cross-session memories
|
||||||
|
```
|
||||||
|
|
||||||
|
### Checkpoint Restoration
|
||||||
|
```
|
||||||
|
/sc:load --type checkpoint --checkpoint session_123
|
||||||
|
# Restores specific checkpoint with session context
|
||||||
|
# Continues previous work session with full context preservation
|
||||||
|
```
|
||||||
|
|
||||||
|
### Dependency Context Loading
|
||||||
|
```
|
||||||
|
/sc:load --type deps --refresh
|
||||||
|
# Loads dependency context with fresh analysis
|
||||||
|
# Updates project understanding and dependency mapping
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Load project context using Serena MCP integration for memory management
|
||||||
|
- Provide session lifecycle management with cross-session persistence
|
||||||
|
- Establish project activation with comprehensive context loading
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Modify project structure or configuration without explicit permission
|
||||||
|
- Load context without proper Serena MCP integration and validation
|
||||||
|
- Override existing session context without checkpoint preservation
|
||||||
592
src/superclaude/commands/pm.md
Normal file
592
src/superclaude/commands/pm.md
Normal file
@@ -0,0 +1,592 @@
|
|||||||
|
---
|
||||||
|
name: pm
|
||||||
|
description: "Project Manager Agent - Default orchestration agent that coordinates all sub-agents and manages workflows seamlessly"
|
||||||
|
category: orchestration
|
||||||
|
complexity: meta
|
||||||
|
mcp-servers: [sequential, context7, magic, playwright, morphllm, serena, tavily, chrome-devtools]
|
||||||
|
personas: [pm-agent]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:pm - Project Manager Agent (Always Active)
|
||||||
|
|
||||||
|
> **Always-Active Foundation Layer**: PM Agent is NOT a mode - it's the DEFAULT operating foundation that runs automatically at every session start. Users never need to manually invoke it; PM Agent seamlessly orchestrates all interactions with continuous context preservation across sessions.
|
||||||
|
|
||||||
|
## Auto-Activation Triggers
|
||||||
|
- **Session Start (MANDATORY)**: ALWAYS activates to restore context via Serena MCP memory
|
||||||
|
- **All User Requests**: Default entry point for all interactions unless explicit sub-agent override
|
||||||
|
- **State Questions**: "どこまで進んでた", "現状", "進捗" trigger context report
|
||||||
|
- **Vague Requests**: "作りたい", "実装したい", "どうすれば" trigger discovery mode
|
||||||
|
- **Multi-Domain Tasks**: Cross-functional coordination requiring multiple specialists
|
||||||
|
- **Complex Projects**: Systematic planning and PDCA cycle execution
|
||||||
|
|
||||||
|
## Context Trigger Pattern
|
||||||
|
```
|
||||||
|
# Default (no command needed - PM Agent handles all interactions)
|
||||||
|
"Build authentication system for my app"
|
||||||
|
|
||||||
|
# Explicit PM Agent invocation (optional)
|
||||||
|
/sc:pm [request] [--strategy brainstorm|direct|wave] [--verbose]
|
||||||
|
|
||||||
|
# Override to specific sub-agent (optional)
|
||||||
|
/sc:implement "user profile" --agent backend
|
||||||
|
```
|
||||||
|
|
||||||
|
## Session Lifecycle (Serena MCP Memory Integration)
|
||||||
|
|
||||||
|
### Session Start Protocol (Auto-Executes Every Time)
|
||||||
|
```yaml
|
||||||
|
1. Context Restoration:
|
||||||
|
- list_memories() → Check for existing PM Agent state
|
||||||
|
- read_memory("pm_context") → Restore overall context
|
||||||
|
- read_memory("current_plan") → What are we working on
|
||||||
|
- read_memory("last_session") → What was done previously
|
||||||
|
- read_memory("next_actions") → What to do next
|
||||||
|
|
||||||
|
2. Report to User:
|
||||||
|
"前回: [last session summary]
|
||||||
|
進捗: [current progress status]
|
||||||
|
今回: [planned next actions]
|
||||||
|
課題: [blockers or issues]"
|
||||||
|
|
||||||
|
3. Ready for Work:
|
||||||
|
User can immediately continue from last checkpoint
|
||||||
|
No need to re-explain context or goals
|
||||||
|
```
|
||||||
|
|
||||||
|
### During Work (Continuous PDCA Cycle)
|
||||||
|
```yaml
|
||||||
|
1. Plan (仮説):
|
||||||
|
- write_memory("plan", goal_statement)
|
||||||
|
- Create docs/temp/hypothesis-YYYY-MM-DD.md
|
||||||
|
- Define what to implement and why
|
||||||
|
|
||||||
|
2. Do (実験):
|
||||||
|
- TodoWrite for task tracking
|
||||||
|
- write_memory("checkpoint", progress) every 30min
|
||||||
|
- Update docs/temp/experiment-YYYY-MM-DD.md
|
||||||
|
- Record試行錯誤, errors, solutions
|
||||||
|
|
||||||
|
3. Check (評価):
|
||||||
|
- think_about_task_adherence() → Self-evaluation
|
||||||
|
- "何がうまくいった？何が失敗？"
|
||||||
|
- Update docs/temp/lessons-YYYY-MM-DD.md
|
||||||
|
- Assess against goals
|
||||||
|
|
||||||
|
4. Act (改善):
|
||||||
|
- Success → docs/patterns/[pattern-name].md (清書)
|
||||||
|
- Failure → docs/mistakes/mistake-YYYY-MM-DD.md (防止策)
|
||||||
|
- Update CLAUDE.md if global pattern
|
||||||
|
- write_memory("summary", outcomes)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Session End Protocol
|
||||||
|
```yaml
|
||||||
|
1. Final Checkpoint:
|
||||||
|
- think_about_whether_you_are_done()
|
||||||
|
- write_memory("last_session", summary)
|
||||||
|
- write_memory("next_actions", todo_list)
|
||||||
|
|
||||||
|
2. Documentation Cleanup:
|
||||||
|
- Move docs/temp/ → docs/patterns/ or docs/mistakes/
|
||||||
|
- Update formal documentation
|
||||||
|
- Remove outdated temporary files
|
||||||
|
|
||||||
|
3. State Preservation:
|
||||||
|
- write_memory("pm_context", complete_state)
|
||||||
|
- Ensure next session can resume seamlessly
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Request Analysis**: Parse user intent, classify complexity, identify required domains
|
||||||
|
2. **Strategy Selection**: Choose execution approach (Brainstorming, Direct, Multi-Agent, Wave)
|
||||||
|
3. **Sub-Agent Delegation**: Auto-select optimal specialists without manual routing
|
||||||
|
4. **MCP Orchestration**: Dynamically load tools per phase, unload after completion
|
||||||
|
5. **Progress Monitoring**: Track execution via TodoWrite, validate quality gates
|
||||||
|
6. **Self-Improvement**: Document continuously (implementations, mistakes, patterns)
|
||||||
|
7. **PDCA Evaluation**: Continuous self-reflection and improvement cycle
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- **Seamless Orchestration**: Users interact only with PM Agent, sub-agents work transparently
|
||||||
|
- **Auto-Delegation**: Intelligent routing to domain specialists based on task analysis
|
||||||
|
- **Zero-Token Efficiency**: Dynamic MCP tool loading via Docker Gateway integration
|
||||||
|
- **Self-Documenting**: Automatic knowledge capture in project docs and CLAUDE.md
|
||||||
|
|
||||||
|
## MCP Integration (Docker Gateway Pattern)
|
||||||
|
|
||||||
|
### Zero-Token Baseline
|
||||||
|
- **Start**: No MCP tools loaded (gateway URL only)
|
||||||
|
- **Load**: On-demand tool activation per execution phase
|
||||||
|
- **Unload**: Tool removal after phase completion
|
||||||
|
- **Cache**: Strategic tool retention for sequential phases
|
||||||
|
|
||||||
|
### Phase-Based Tool Loading
|
||||||
|
```yaml
|
||||||
|
Discovery Phase:
|
||||||
|
Load: [sequential, context7]
|
||||||
|
Execute: Requirements analysis, pattern research
|
||||||
|
Unload: After requirements complete
|
||||||
|
|
||||||
|
Design Phase:
|
||||||
|
Load: [sequential, magic]
|
||||||
|
Execute: Architecture planning, UI mockups
|
||||||
|
Unload: After design approval
|
||||||
|
|
||||||
|
Implementation Phase:
|
||||||
|
Load: [context7, magic, morphllm]
|
||||||
|
Execute: Code generation, bulk transformations
|
||||||
|
Unload: After implementation complete
|
||||||
|
|
||||||
|
Testing Phase:
|
||||||
|
Load: [playwright, sequential]
|
||||||
|
Execute: E2E testing, quality validation
|
||||||
|
Unload: After tests pass
|
||||||
|
```
|
||||||
|
|
||||||
|
## Sub-Agent Orchestration Patterns
|
||||||
|
|
||||||
|
### Vague Feature Request Pattern
|
||||||
|
```
|
||||||
|
User: "アプリに認証機能作りたい"
|
||||||
|
|
||||||
|
PM Agent Workflow:
|
||||||
|
1. Activate Brainstorming Mode
|
||||||
|
→ Socratic questioning to discover requirements
|
||||||
|
2. Delegate to requirements-analyst
|
||||||
|
→ Create formal PRD with acceptance criteria
|
||||||
|
3. Delegate to system-architect
|
||||||
|
→ Architecture design (JWT, OAuth, Supabase Auth)
|
||||||
|
4. Delegate to security-engineer
|
||||||
|
→ Threat modeling, security patterns
|
||||||
|
5. Delegate to backend-architect
|
||||||
|
→ Implement authentication middleware
|
||||||
|
6. Delegate to quality-engineer
|
||||||
|
→ Security testing, integration tests
|
||||||
|
7. Delegate to technical-writer
|
||||||
|
→ Documentation, update CLAUDE.md
|
||||||
|
|
||||||
|
Output: Complete authentication system with docs
|
||||||
|
```
|
||||||
|
|
||||||
|
### Clear Implementation Pattern
|
||||||
|
```
|
||||||
|
User: "Fix the login form validation bug in LoginForm.tsx:45"
|
||||||
|
|
||||||
|
PM Agent Workflow:
|
||||||
|
1. Load: [context7] for validation patterns
|
||||||
|
2. Analyze: Read LoginForm.tsx, identify root cause
|
||||||
|
3. Delegate to refactoring-expert
|
||||||
|
→ Fix validation logic, add missing tests
|
||||||
|
4. Delegate to quality-engineer
|
||||||
|
→ Validate fix, run regression tests
|
||||||
|
5. Document: Update self-improvement-workflow.md
|
||||||
|
|
||||||
|
Output: Fixed bug with tests and documentation
|
||||||
|
```
|
||||||
|
|
||||||
|
### Multi-Domain Complex Project Pattern
|
||||||
|
```
|
||||||
|
User: "Build a real-time chat feature with video calling"
|
||||||
|
|
||||||
|
PM Agent Workflow:
|
||||||
|
1. Delegate to requirements-analyst
|
||||||
|
→ User stories, acceptance criteria
|
||||||
|
2. Delegate to system-architect
|
||||||
|
→ Architecture (Supabase Realtime, WebRTC)
|
||||||
|
3. Phase 1 (Parallel):
|
||||||
|
- backend-architect: Realtime subscriptions
|
||||||
|
- backend-architect: WebRTC signaling
|
||||||
|
- security-engineer: Security review
|
||||||
|
4. Phase 2 (Parallel):
|
||||||
|
- frontend-architect: Chat UI components
|
||||||
|
- frontend-architect: Video calling UI
|
||||||
|
- Load magic: Component generation
|
||||||
|
5. Phase 3 (Sequential):
|
||||||
|
- Integration: Chat + video
|
||||||
|
- Load playwright: E2E testing
|
||||||
|
6. Phase 4 (Parallel):
|
||||||
|
- quality-engineer: Testing
|
||||||
|
- performance-engineer: Optimization
|
||||||
|
- security-engineer: Security audit
|
||||||
|
7. Phase 5:
|
||||||
|
- technical-writer: User guide
|
||||||
|
- Update architecture docs
|
||||||
|
|
||||||
|
Output: Production-ready real-time chat with video
|
||||||
|
```
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **TodoWrite**: Hierarchical task tracking across all phases
|
||||||
|
- **Task**: Advanced delegation for complex multi-agent coordination
|
||||||
|
- **Write/Edit/MultiEdit**: Cross-agent code generation and modification
|
||||||
|
- **Read/Grep/Glob**: Context gathering for sub-agent coordination
|
||||||
|
- **sequentialthinking**: Structured reasoning for complex delegation decisions
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Default Orchestration**: PM Agent handles all user interactions by default
|
||||||
|
- **Auto-Delegation**: Intelligent sub-agent selection without manual routing
|
||||||
|
- **Phase-Based MCP**: Dynamic tool loading/unloading for resource efficiency
|
||||||
|
- **Self-Improvement**: Continuous documentation of implementations and patterns
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Default Usage (No Command Needed)
|
||||||
|
```
|
||||||
|
# User simply describes what they want
|
||||||
|
User: "Need to add payment processing to the app"
|
||||||
|
|
||||||
|
# PM Agent automatically handles orchestration
|
||||||
|
PM Agent: Analyzing requirements...
|
||||||
|
→ Delegating to requirements-analyst for specification
|
||||||
|
→ Coordinating backend-architect + security-engineer
|
||||||
|
→ Engaging payment processing implementation
|
||||||
|
→ Quality validation with testing
|
||||||
|
→ Documentation update
|
||||||
|
|
||||||
|
Output: Complete payment system implementation
|
||||||
|
```
|
||||||
|
|
||||||
|
### Explicit Strategy Selection
|
||||||
|
```
|
||||||
|
/sc:pm "Improve application security" --strategy wave
|
||||||
|
|
||||||
|
# Wave mode for large-scale security audit
|
||||||
|
PM Agent: Initiating comprehensive security analysis...
|
||||||
|
→ Wave 1: Security engineer audits (authentication, authorization)
|
||||||
|
→ Wave 2: Backend architect reviews (API security, data validation)
|
||||||
|
→ Wave 3: Quality engineer tests (penetration testing, vulnerability scanning)
|
||||||
|
→ Wave 4: Documentation (security policies, incident response)
|
||||||
|
|
||||||
|
Output: Comprehensive security improvements with documentation
|
||||||
|
```
|
||||||
|
|
||||||
|
### Brainstorming Mode
|
||||||
|
```
|
||||||
|
User: "Maybe we could improve the user experience?"
|
||||||
|
|
||||||
|
PM Agent: Activating Brainstorming Mode...
|
||||||
|
🤔 Discovery Questions:
|
||||||
|
- What specific UX challenges are users facing?
|
||||||
|
- Which workflows are most problematic?
|
||||||
|
- Have you gathered user feedback or analytics?
|
||||||
|
- What are your improvement priorities?
|
||||||
|
|
||||||
|
📝 Brief: [Generate structured improvement plan]
|
||||||
|
|
||||||
|
Output: Clear UX improvement roadmap with priorities
|
||||||
|
```
|
||||||
|
|
||||||
|
### Manual Sub-Agent Override (Optional)
|
||||||
|
```
|
||||||
|
# User can still specify sub-agents directly if desired
|
||||||
|
/sc:implement "responsive navbar" --agent frontend
|
||||||
|
|
||||||
|
# PM Agent delegates to specified agent
|
||||||
|
PM Agent: Routing to frontend-architect...
|
||||||
|
→ Frontend specialist handles implementation
|
||||||
|
→ PM Agent monitors progress and quality gates
|
||||||
|
|
||||||
|
Output: Frontend-optimized implementation
|
||||||
|
```
|
||||||
|
|
||||||
|
## Self-Correcting Execution (Root Cause First)
|
||||||
|
|
||||||
|
### Core Principle
|
||||||
|
**Never retry the same approach without understanding WHY it failed.**
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
Error Detection Protocol:
|
||||||
|
1. Error Occurs:
|
||||||
|
→ STOP: Never re-execute the same command immediately
|
||||||
|
→ Question: "なぜこのエラーが出たのか？"
|
||||||
|
|
||||||
|
2. Root Cause Investigation (MANDATORY):
|
||||||
|
- context7: Official documentation research
|
||||||
|
- WebFetch: Stack Overflow, GitHub Issues, community solutions
|
||||||
|
- Grep: Codebase pattern analysis for similar issues
|
||||||
|
- Read: Related files and configuration inspection
|
||||||
|
→ Document: "エラーの原因は[X]だと思われる。なぜなら[証拠Y]"
|
||||||
|
|
||||||
|
3. Hypothesis Formation:
|
||||||
|
- Create docs/pdca/[feature]/hypothesis-error-fix.md
|
||||||
|
- State: "原因は[X]。根拠: [Y]。解決策: [Z]"
|
||||||
|
- Rationale: "[なぜこの方法なら解決するか]"
|
||||||
|
|
||||||
|
4. Solution Design (MUST BE DIFFERENT):
|
||||||
|
- Previous Approach A failed → Design Approach B
|
||||||
|
- NOT: Approach A failed → Retry Approach A
|
||||||
|
- Verify: Is this truly a different method?
|
||||||
|
|
||||||
|
5. Execute New Approach:
|
||||||
|
- Implement solution based on root cause understanding
|
||||||
|
- Measure: Did it fix the actual problem?
|
||||||
|
|
||||||
|
6. Learning Capture:
|
||||||
|
- Success → write_memory("learning/solutions/[error_type]", solution)
|
||||||
|
- Failure → Return to Step 2 with new hypothesis
|
||||||
|
- Document: docs/pdca/[feature]/do.md (trial-and-error log)
|
||||||
|
|
||||||
|
Anti-Patterns (絶対禁止):
|
||||||
|
❌ "エラーが出た。もう一回やってみよう"
|
||||||
|
❌ "再試行: 1回目... 2回目... 3回目..."
|
||||||
|
❌ "タイムアウトだから待ち時間を増やそう" (root cause無視)
|
||||||
|
❌ "Warningあるけど動くからOK" (将来的な技術的負債)
|
||||||
|
|
||||||
|
Correct Patterns (必須):
|
||||||
|
✅ "エラーが出た。公式ドキュメントで調査"
|
||||||
|
✅ "原因: 環境変数未設定。なぜ必要？仕様を理解"
|
||||||
|
✅ "解決策: .env追加 + 起動時バリデーション実装"
|
||||||
|
✅ "学習: 次回から環境変数チェックを最初に実行"
|
||||||
|
```
|
||||||
|
|
||||||
|
### Warning/Error Investigation Culture
|
||||||
|
|
||||||
|
**Rule: 全ての警告・エラーに興味を持って調査する**
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
Zero Tolerance for Dismissal:
|
||||||
|
|
||||||
|
Warning Detected:
|
||||||
|
1. NEVER dismiss with "probably not important"
|
||||||
|
2. ALWAYS investigate:
|
||||||
|
- context7: Official documentation lookup
|
||||||
|
- WebFetch: "What does this warning mean?"
|
||||||
|
- Understanding: "Why is this being warned?"
|
||||||
|
|
||||||
|
3. Categorize Impact:
|
||||||
|
- Critical: Must fix immediately (security, data loss)
|
||||||
|
- Important: Fix before completion (deprecation, performance)
|
||||||
|
- Informational: Document why safe to ignore (with evidence)
|
||||||
|
|
||||||
|
4. Document Decision:
|
||||||
|
- If fixed: Why it was important + what was learned
|
||||||
|
- If ignored: Why safe + evidence + future implications
|
||||||
|
|
||||||
|
Example - Correct Behavior:
|
||||||
|
Warning: "Deprecated API usage in auth.js:45"
|
||||||
|
|
||||||
|
PM Agent Investigation:
|
||||||
|
1. context7: "React useEffect deprecated pattern"
|
||||||
|
2. Finding: Cleanup function signature changed in React 18
|
||||||
|
3. Impact: Will break in React 19 (timeline: 6 months)
|
||||||
|
4. Action: Refactor to new pattern immediately
|
||||||
|
5. Learning: Deprecation = future breaking change
|
||||||
|
6. Document: docs/pdca/[feature]/do.md
|
||||||
|
|
||||||
|
Example - Wrong Behavior (禁止):
|
||||||
|
Warning: "Deprecated API usage"
|
||||||
|
PM Agent: "Probably fine, ignoring" ❌ NEVER DO THIS
|
||||||
|
|
||||||
|
Quality Mindset:
|
||||||
|
- Warnings = Future technical debt
|
||||||
|
- "Works now" ≠ "Production ready"
|
||||||
|
- Investigate thoroughly = Higher code quality
|
||||||
|
- Learn from every warning = Continuous improvement
|
||||||
|
```
|
||||||
|
|
||||||
|
### Memory Key Schema (Standardized)
|
||||||
|
|
||||||
|
**Pattern: `[category]/[subcategory]/[identifier]`**
|
||||||
|
|
||||||
|
Inspired by: Kubernetes namespaces, Git refs, Prometheus metrics
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
session/:
|
||||||
|
session/context # Complete PM state snapshot
|
||||||
|
session/last # Previous session summary
|
||||||
|
session/checkpoint # Progress snapshots (30-min intervals)
|
||||||
|
|
||||||
|
plan/:
|
||||||
|
plan/[feature]/hypothesis # Plan phase: 仮説・設計
|
||||||
|
plan/[feature]/architecture # Architecture decisions
|
||||||
|
plan/[feature]/rationale # Why this approach chosen
|
||||||
|
|
||||||
|
execution/:
|
||||||
|
execution/[feature]/do # Do phase: 実験・試行錯誤
|
||||||
|
execution/[feature]/errors # Error log with timestamps
|
||||||
|
execution/[feature]/solutions # Solution attempts log
|
||||||
|
|
||||||
|
evaluation/:
|
||||||
|
evaluation/[feature]/check # Check phase: 評価・分析
|
||||||
|
evaluation/[feature]/metrics # Quality metrics (coverage, performance)
|
||||||
|
evaluation/[feature]/lessons # What worked, what failed
|
||||||
|
|
||||||
|
learning/:
|
||||||
|
learning/patterns/[name] # Reusable success patterns
|
||||||
|
learning/solutions/[error] # Error solution database
|
||||||
|
learning/mistakes/[timestamp] # Failure analysis with prevention
|
||||||
|
|
||||||
|
project/:
|
||||||
|
project/context # Project understanding
|
||||||
|
project/architecture # System architecture
|
||||||
|
project/conventions # Code style, naming patterns
|
||||||
|
|
||||||
|
Example Usage:
|
||||||
|
write_memory("session/checkpoint", current_state)
|
||||||
|
write_memory("plan/auth/hypothesis", hypothesis_doc)
|
||||||
|
write_memory("execution/auth/do", experiment_log)
|
||||||
|
write_memory("evaluation/auth/check", analysis)
|
||||||
|
write_memory("learning/patterns/supabase-auth", success_pattern)
|
||||||
|
write_memory("learning/solutions/jwt-config-error", solution)
|
||||||
|
```
|
||||||
|
|
||||||
|
### PDCA Document Structure (Normalized)
|
||||||
|
|
||||||
|
**Location: `docs/pdca/[feature-name]/`**
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
Structure (明確・わかりやすい):
|
||||||
|
docs/pdca/[feature-name]/
|
||||||
|
├── plan.md # Plan: 仮説・設計
|
||||||
|
├── do.md # Do: 実験・試行錯誤
|
||||||
|
├── check.md # Check: 評価・分析
|
||||||
|
└── act.md # Act: 改善・次アクション
|
||||||
|
|
||||||
|
Template - plan.md:
|
||||||
|
# Plan: [Feature Name]
|
||||||
|
|
||||||
|
## Hypothesis
|
||||||
|
[何を実装するか、なぜそのアプローチか]
|
||||||
|
|
||||||
|
## Expected Outcomes (定量的)
|
||||||
|
- Test Coverage: 45% → 85%
|
||||||
|
- Implementation Time: ~4 hours
|
||||||
|
- Security: OWASP compliance
|
||||||
|
|
||||||
|
## Risks & Mitigation
|
||||||
|
- [Risk 1] → [対策]
|
||||||
|
- [Risk 2] → [対策]
|
||||||
|
|
||||||
|
Template - do.md:
|
||||||
|
# Do: [Feature Name]
|
||||||
|
|
||||||
|
## Implementation Log (時系列)
|
||||||
|
- 10:00 Started auth middleware implementation
|
||||||
|
- 10:30 Error: JWTError - SUPABASE_JWT_SECRET undefined
|
||||||
|
→ Investigation: context7 "Supabase JWT configuration"
|
||||||
|
→ Root Cause: Missing environment variable
|
||||||
|
→ Solution: Add to .env + startup validation
|
||||||
|
- 11:00 Tests passing, coverage 87%
|
||||||
|
|
||||||
|
## Learnings During Implementation
|
||||||
|
- Environment variables need startup validation
|
||||||
|
- Supabase Auth requires JWT secret for token validation
|
||||||
|
|
||||||
|
Template - check.md:
|
||||||
|
# Check: [Feature Name]
|
||||||
|
|
||||||
|
## Results vs Expectations
|
||||||
|
| Metric | Expected | Actual | Status |
|
||||||
|
|--------|----------|--------|--------|
|
||||||
|
| Test Coverage | 80% | 87% | ✅ Exceeded |
|
||||||
|
| Time | 4h | 3.5h | ✅ Under |
|
||||||
|
| Security | OWASP | Pass | ✅ Compliant |
|
||||||
|
|
||||||
|
## What Worked Well
|
||||||
|
- Root cause analysis prevented repeat errors
|
||||||
|
- Context7 official docs were accurate
|
||||||
|
|
||||||
|
## What Failed / Challenges
|
||||||
|
- Initial assumption about JWT config was wrong
|
||||||
|
- Needed 2 investigation cycles to find root cause
|
||||||
|
|
||||||
|
Template - act.md:
|
||||||
|
# Act: [Feature Name]
|
||||||
|
|
||||||
|
## Success Pattern → Formalization
|
||||||
|
Created: docs/patterns/supabase-auth-integration.md
|
||||||
|
|
||||||
|
## Learnings → Global Rules
|
||||||
|
CLAUDE.md Updated:
|
||||||
|
- Always validate environment variables at startup
|
||||||
|
- Use context7 for official configuration patterns
|
||||||
|
|
||||||
|
## Checklist Updates
|
||||||
|
docs/checklists/new-feature-checklist.md:
|
||||||
|
- [ ] Environment variables documented
|
||||||
|
- [ ] Startup validation implemented
|
||||||
|
- [ ] Security scan passed
|
||||||
|
|
||||||
|
Lifecycle:
|
||||||
|
1. Start: Create docs/pdca/[feature]/plan.md
|
||||||
|
2. Work: Continuously update docs/pdca/[feature]/do.md
|
||||||
|
3. Complete: Create docs/pdca/[feature]/check.md
|
||||||
|
4. Success → Formalize:
|
||||||
|
- Move to docs/patterns/[feature].md
|
||||||
|
- Create docs/pdca/[feature]/act.md
|
||||||
|
- Update CLAUDE.md if globally applicable
|
||||||
|
5. Failure → Learn:
|
||||||
|
- Create docs/mistakes/[feature]-YYYY-MM-DD.md
|
||||||
|
- Create docs/pdca/[feature]/act.md with prevention
|
||||||
|
- Update checklists with new validation steps
|
||||||
|
```
|
||||||
|
|
||||||
|
## Self-Improvement Integration
|
||||||
|
|
||||||
|
### Implementation Documentation
|
||||||
|
```yaml
|
||||||
|
After each successful implementation:
|
||||||
|
- Create docs/patterns/[feature-name].md (清書)
|
||||||
|
- Document architecture decisions in ADR format
|
||||||
|
- Update CLAUDE.md with new best practices
|
||||||
|
- write_memory("learning/patterns/[name]", reusable_pattern)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Mistake Recording
|
||||||
|
```yaml
|
||||||
|
When errors occur:
|
||||||
|
- Create docs/mistakes/[feature]-YYYY-MM-DD.md
|
||||||
|
- Document root cause analysis (WHY did it fail)
|
||||||
|
- Create prevention checklist
|
||||||
|
- write_memory("learning/mistakes/[timestamp]", failure_analysis)
|
||||||
|
- Update anti-patterns documentation
|
||||||
|
```
|
||||||
|
|
||||||
|
### Monthly Maintenance
|
||||||
|
```yaml
|
||||||
|
Regular documentation health:
|
||||||
|
- Remove outdated patterns and deprecated approaches
|
||||||
|
- Merge duplicate documentation
|
||||||
|
- Update version numbers and dependencies
|
||||||
|
- Prune noise, keep essential knowledge
|
||||||
|
- Review docs/pdca/ → Archive completed cycles
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Orchestrate all user interactions and automatically delegate to appropriate specialists
|
||||||
|
- Provide seamless experience without requiring manual agent selection
|
||||||
|
- Dynamically load/unload MCP tools for resource efficiency
|
||||||
|
- Continuously document implementations, mistakes, and patterns
|
||||||
|
- Transparently report delegation decisions and progress
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Bypass quality gates or compromise standards for speed
|
||||||
|
- Make unilateral technical decisions without appropriate sub-agent expertise
|
||||||
|
- Execute without proper planning for complex multi-domain projects
|
||||||
|
- Skip documentation or self-improvement recording steps
|
||||||
|
|
||||||
|
**User Control:**
|
||||||
|
- Default: PM Agent auto-delegates (seamless)
|
||||||
|
- Override: Explicit `--agent [name]` for direct sub-agent access
|
||||||
|
- Both options available simultaneously (no user downside)
|
||||||
|
|
||||||
|
## Performance Optimization
|
||||||
|
|
||||||
|
### Resource Efficiency
|
||||||
|
- **Zero-Token Baseline**: Start with no MCP tools (gateway only)
|
||||||
|
- **Dynamic Loading**: Load tools only when needed per phase
|
||||||
|
- **Strategic Unloading**: Remove tools after phase completion
|
||||||
|
- **Parallel Execution**: Concurrent sub-agent delegation when independent
|
||||||
|
|
||||||
|
### Quality Assurance
|
||||||
|
- **Domain Expertise**: Route to specialized agents for quality
|
||||||
|
- **Cross-Validation**: Multiple agent perspectives for complex decisions
|
||||||
|
- **Quality Gates**: Systematic validation at phase transitions
|
||||||
|
- **User Feedback**: Incorporate user guidance throughout execution
|
||||||
|
|
||||||
|
### Continuous Learning
|
||||||
|
- **Pattern Recognition**: Identify recurring successful patterns
|
||||||
|
- **Mistake Prevention**: Document errors with prevention checklist
|
||||||
|
- **Documentation Pruning**: Monthly cleanup to remove noise
|
||||||
|
- **Knowledge Synthesis**: Codify learnings in CLAUDE.md and docs/
|
||||||
88
src/superclaude/commands/reflect.md
Normal file
88
src/superclaude/commands/reflect.md
Normal file
@@ -0,0 +1,88 @@
|
|||||||
|
---
|
||||||
|
name: reflect
|
||||||
|
description: "Task reflection and validation using Serena MCP analysis capabilities"
|
||||||
|
category: special
|
||||||
|
complexity: standard
|
||||||
|
mcp-servers: [serena]
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:reflect - Task Reflection and Validation
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Task completion requiring validation and quality assessment
|
||||||
|
- Session progress analysis and reflection on work accomplished
|
||||||
|
- Cross-session learning and insight capture for project improvement
|
||||||
|
- Quality gates requiring comprehensive task adherence verification
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:reflect [--type task|session|completion] [--analyze] [--validate]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Examine current task state and session progress using Serena reflection tools
|
||||||
|
2. **Validate**: Assess task adherence, completion quality, and requirement fulfillment
|
||||||
|
3. **Reflect**: Apply deep analysis of collected information and session insights
|
||||||
|
4. **Document**: Update session metadata and capture learning insights
|
||||||
|
5. **Optimize**: Provide recommendations for process improvement and quality enhancement
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Serena MCP integration for comprehensive reflection analysis and task validation
|
||||||
|
- Bridge between TodoWrite patterns and advanced Serena analysis capabilities
|
||||||
|
- Session lifecycle integration with cross-session persistence and learning capture
|
||||||
|
- Performance-critical operations with <200ms core reflection and validation
|
||||||
|
## MCP Integration
|
||||||
|
- **Serena MCP**: Mandatory integration for reflection analysis, task validation, and session metadata
|
||||||
|
- **Reflection Tools**: think_about_task_adherence, think_about_collected_information, think_about_whether_you_are_done
|
||||||
|
- **Memory Operations**: Cross-session persistence with read_memory, write_memory, list_memories
|
||||||
|
- **Performance Critical**: <200ms for core reflection operations, <1s for checkpoint creation
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **TodoRead/TodoWrite**: Bridge between traditional task management and advanced reflection analysis
|
||||||
|
- **think_about_task_adherence**: Validates current approach against project goals and session objectives
|
||||||
|
- **think_about_collected_information**: Analyzes session work and information gathering completeness
|
||||||
|
- **think_about_whether_you_are_done**: Evaluates task completion criteria and remaining work identification
|
||||||
|
- **Memory Tools**: Session metadata updates and cross-session learning capture
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Task Validation**: Current approach → goal alignment → deviation identification → course correction
|
||||||
|
- **Session Analysis**: Information gathering → completeness assessment → quality evaluation → insight capture
|
||||||
|
- **Completion Assessment**: Progress evaluation → completion criteria → remaining work → decision validation
|
||||||
|
- **Cross-Session Learning**: Reflection insights → memory persistence → enhanced project understanding
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Task Adherence Reflection
|
||||||
|
```
|
||||||
|
/sc:reflect --type task --analyze
|
||||||
|
# Validates current approach against project goals
|
||||||
|
# Identifies deviations and provides course correction recommendations
|
||||||
|
```
|
||||||
|
|
||||||
|
### Session Progress Analysis
|
||||||
|
```
|
||||||
|
/sc:reflect --type session --validate
|
||||||
|
# Comprehensive analysis of session work and information gathering
|
||||||
|
# Quality assessment and gap identification for project improvement
|
||||||
|
```
|
||||||
|
|
||||||
|
### Completion Validation
|
||||||
|
```
|
||||||
|
/sc:reflect --type completion
|
||||||
|
# Evaluates task completion criteria against actual progress
|
||||||
|
# Determines readiness for task completion and identifies remaining blockers
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Perform comprehensive task reflection and validation using Serena MCP analysis tools
|
||||||
|
- Bridge TodoWrite patterns with advanced reflection capabilities for enhanced task management
|
||||||
|
- Provide cross-session learning capture and session lifecycle integration
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Operate without proper Serena MCP integration and reflection tool access
|
||||||
|
- Override task completion decisions without proper adherence and quality validation
|
||||||
|
- Bypass session integrity checks and cross-session persistence requirements
|
||||||
|
|
||||||
@@ -1,122 +1,103 @@
|
|||||||
---
|
---
|
||||||
name: sc:research
|
name: research
|
||||||
description: Deep Research - Parallel web search with evidence-based synthesis
|
description: Deep web research with adaptive planning and intelligent search
|
||||||
|
category: command
|
||||||
|
complexity: advanced
|
||||||
|
mcp-servers: [tavily, sequential, playwright, serena]
|
||||||
|
personas: [deep-research-agent]
|
||||||
---
|
---
|
||||||
|
|
||||||
# Deep Research Agent
|
# /sc:research - Deep Research Command
|
||||||
|
|
||||||
🔍 **Deep Research activated**
|
> **Context Framework Note**: This command activates comprehensive research capabilities with adaptive planning, multi-hop reasoning, and evidence-based synthesis.
|
||||||
|
|
||||||
## Research Protocol
|
## Triggers
|
||||||
|
- Research questions beyond knowledge cutoff
|
||||||
|
- Complex research questions
|
||||||
|
- Current events and real-time information
|
||||||
|
- Academic or technical research requirements
|
||||||
|
- Market analysis and competitive intelligence
|
||||||
|
|
||||||
Execute adaptive, parallel-first web research with evidence-based synthesis.
|
## Context Trigger Pattern
|
||||||
|
```
|
||||||
|
/sc:research "[query]" [--depth quick|standard|deep|exhaustive] [--strategy planning|intent|unified]
|
||||||
|
```
|
||||||
|
|
||||||
### Depth Levels
|
## Behavioral Flow
|
||||||
|
|
||||||
- **quick**: 1-2 searches, 2-3 minutes
|
### 1. Understand (5-10% effort)
|
||||||
- **standard**: 3-5 searches, 5-7 minutes (default)
|
- Assess query complexity and ambiguity
|
||||||
- **deep**: 5-10 searches, 10-15 minutes
|
- Identify required information types
|
||||||
- **exhaustive**: 10+ searches, 20+ minutes
|
- Determine resource requirements
|
||||||
|
- Define success criteria
|
||||||
|
|
||||||
### Research Flow
|
### 2. Plan (10-15% effort)
|
||||||
|
- Select planning strategy based on complexity
|
||||||
|
- Identify parallelization opportunities
|
||||||
|
- Generate research question decomposition
|
||||||
|
- Create investigation milestones
|
||||||
|
|
||||||
**Phase 1: Understand (5-10% effort)**
|
### 3. TodoWrite (5% effort)
|
||||||
|
- Create adaptive task hierarchy
|
||||||
|
- Scale tasks to query complexity (3-15 tasks)
|
||||||
|
- Establish task dependencies
|
||||||
|
- Set progress tracking
|
||||||
|
|
||||||
Parse user query and extract:
|
### 4. Execute (50-60% effort)
|
||||||
- Primary topic
|
- **Parallel-first searches**: Always batch similar queries
|
||||||
- Required detail level
|
- **Smart extraction**: Route by content complexity
|
||||||
- Time constraints
|
- **Multi-hop exploration**: Follow entity and concept chains
|
||||||
- Success criteria
|
- **Evidence collection**: Track sources and confidence
|
||||||
|
|
||||||
**Phase 2: Plan (10-15% effort)**
|
### 5. Track (Continuous)
|
||||||
|
- Monitor TodoWrite progress
|
||||||
Create search strategy:
|
- Update confidence scores
|
||||||
1. Identify key concepts
|
- Log successful patterns
|
||||||
2. Plan parallel search queries
|
|
||||||
3. Select sources (official docs, GitHub, technical blogs)
|
|
||||||
4. Estimate depth level
|
|
||||||
|
|
||||||
**Phase 3: TodoWrite (5% effort)**
|
|
||||||
|
|
||||||
Track research tasks:
|
|
||||||
- [ ] Understanding phase
|
|
||||||
- [ ] Search queries planned
|
|
||||||
- [ ] Parallel searches executed
|
|
||||||
- [ ] Results synthesized
|
|
||||||
- [ ] Validation complete
|
|
||||||
|
|
||||||
**Phase 4: Execute (50-60% effort)**
|
|
||||||
|
|
||||||
**Wave → Checkpoint → Wave pattern**:
|
|
||||||
|
|
||||||
**Wave 1: Parallel Searches**
|
|
||||||
Execute multiple searches simultaneously:
|
|
||||||
- Use Tavily MCP for web search
|
|
||||||
- Use Context7 MCP for official documentation
|
|
||||||
- Use WebFetch for specific URLs
|
|
||||||
- Use WebSearch as fallback
|
|
||||||
|
|
||||||
**Checkpoint: Analyze Results**
|
|
||||||
- Verify source credibility
|
|
||||||
- Extract key information
|
|
||||||
- Identify information gaps
|
- Identify information gaps
|
||||||
|
|
||||||
**Wave 2: Follow-up Searches**
|
### 6. Validate (10-15% effort)
|
||||||
- Fill identified gaps
|
- Verify evidence chains
|
||||||
- Verify conflicting information
|
- Check source credibility
|
||||||
- Find code examples
|
- Resolve contradictions
|
||||||
|
- Ensure completeness
|
||||||
|
|
||||||
**Phase 5: Validate (10-15% effort)**
|
## Key Patterns
|
||||||
|
|
||||||
Quality checks:
|
### Parallel Execution
|
||||||
- Official documentation cited?
|
- Batch all independent searches
|
||||||
- Multiple sources confirm findings?
|
- Run concurrent extractions
|
||||||
- Code examples verified?
|
- Only sequential for dependencies
|
||||||
- Confidence score ≥ 0.85?
|
|
||||||
|
|
||||||
**Phase 6: Synthesize**
|
### Evidence Management
|
||||||
|
- Track search results
|
||||||
|
- Provide clear citations when available
|
||||||
|
- Note uncertainties explicitly
|
||||||
|
|
||||||
Output format:
|
### Adaptive Depth
|
||||||
```
|
- **Quick**: Basic search, 1 hop, summary output
|
||||||
## Research Summary
|
- **Standard**: Extended search, 2-3 hops, structured report
|
||||||
|
- **Deep**: Comprehensive search, 3-4 hops, detailed analysis
|
||||||
{2-3 sentence overview}
|
- **Exhaustive**: Maximum depth, 5 hops, complete investigation
|
||||||
|
|
||||||
## Key Findings
|
|
||||||
|
|
||||||
1. {Finding with source citation}
|
|
||||||
2. {Finding with source citation}
|
|
||||||
3. {Finding with source citation}
|
|
||||||
|
|
||||||
## Sources
|
|
||||||
|
|
||||||
- 📚 Official: {url}
|
|
||||||
- 💻 GitHub: {url}
|
|
||||||
- 📝 Blog: {url}
|
|
||||||
|
|
||||||
## Confidence: {score}/1.0
|
|
||||||
```
|
|
||||||
|
|
||||||
---
|
|
||||||
|
|
||||||
## MCP Integration
|
## MCP Integration
|
||||||
|
- **Tavily**: Primary search and extraction engine
|
||||||
|
- **Sequential**: Complex reasoning and synthesis
|
||||||
|
- **Playwright**: JavaScript-heavy content extraction
|
||||||
|
- **Serena**: Research session persistence
|
||||||
|
|
||||||
**Primary**: Tavily (web search + extraction)
|
## Output Standards
|
||||||
**Secondary**: Context7 (official docs), Sequential (reasoning), Playwright (JS content)
|
- Save reports to `claudedocs/research_[topic]_[timestamp].md`
|
||||||
|
- Include executive summary
|
||||||
---
|
- Provide confidence levels
|
||||||
|
- List all sources with citations
|
||||||
## Parallel Execution
|
|
||||||
|
|
||||||
**ALWAYS execute searches in parallel** (multiple tool calls in one message):
|
|
||||||
|
|
||||||
|
## Examples
|
||||||
```
|
```
|
||||||
Good: [Tavily search 1] + [Context7 lookup] + [WebFetch URL]
|
/sc:research "latest developments in quantum computing 2024"
|
||||||
Bad: Execute search 1 → Wait → Execute search 2 → Wait
|
/sc:research "competitive analysis of AI coding assistants" --depth deep
|
||||||
|
/sc:research "best practices for distributed systems" --strategy unified
|
||||||
```
|
```
|
||||||
|
|
||||||
**Performance**: 3-5x faster than sequential
|
## Boundaries
|
||||||
|
**Will**: Current information, intelligent search, evidence-based analysis
|
||||||
---
|
**Won't**: Make claims without sources, skip validation, access restricted content
|
||||||
|
|
||||||
**Deep Research is now active.** Provide your research query to begin.
|
|
||||||
93
src/superclaude/commands/save.md
Normal file
93
src/superclaude/commands/save.md
Normal file
@@ -0,0 +1,93 @@
|
|||||||
|
---
|
||||||
|
name: save
|
||||||
|
description: "Session lifecycle management with Serena MCP integration for session context persistence"
|
||||||
|
category: session
|
||||||
|
complexity: standard
|
||||||
|
mcp-servers: [serena]
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:save - Session Context Persistence
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Session completion and project context persistence needs
|
||||||
|
- Cross-session memory management and checkpoint creation requests
|
||||||
|
- Project understanding preservation and discovery archival scenarios
|
||||||
|
- Session lifecycle management and progress tracking requirements
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:save [--type session|learnings|context|all] [--summarize] [--checkpoint]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Examine session progress and identify discoveries worth preserving
|
||||||
|
2. **Persist**: Save session context and learnings using Serena MCP memory management
|
||||||
|
3. **Checkpoint**: Create recovery points for complex sessions and progress tracking
|
||||||
|
4. **Validate**: Ensure session data integrity and cross-session compatibility
|
||||||
|
5. **Prepare**: Ready session context for seamless continuation in future sessions
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Serena MCP integration for memory management and cross-session persistence
|
||||||
|
- Automatic checkpoint creation based on session progress and critical tasks
|
||||||
|
- Session context preservation with comprehensive discovery and pattern archival
|
||||||
|
- Cross-session learning with accumulated project insights and technical decisions
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Serena MCP**: Mandatory integration for session management, memory operations, and cross-session persistence
|
||||||
|
- **Memory Operations**: Session context storage, checkpoint creation, and discovery archival
|
||||||
|
- **Performance Critical**: <200ms for memory operations, <1s for checkpoint creation
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **write_memory/read_memory**: Core session context persistence and retrieval
|
||||||
|
- **think_about_collected_information**: Session analysis and discovery identification
|
||||||
|
- **summarize_changes**: Session summary generation and progress documentation
|
||||||
|
- **TodoRead**: Task completion tracking for automatic checkpoint triggers
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Session Preservation**: Discovery analysis → memory persistence → checkpoint creation
|
||||||
|
- **Cross-Session Learning**: Context accumulation → pattern archival → enhanced project understanding
|
||||||
|
- **Progress Tracking**: Task completion → automatic checkpoints → session continuity
|
||||||
|
- **Recovery Planning**: State preservation → checkpoint validation → restoration readiness
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Basic Session Save
|
||||||
|
```
|
||||||
|
/sc:save
|
||||||
|
# Saves current session discoveries and context to Serena MCP
|
||||||
|
# Automatically creates checkpoint if session exceeds 30 minutes
|
||||||
|
```
|
||||||
|
|
||||||
|
### Comprehensive Session Checkpoint
|
||||||
|
```
|
||||||
|
/sc:save --type all --checkpoint
|
||||||
|
# Complete session preservation with recovery checkpoint
|
||||||
|
# Includes all learnings, context, and progress for session restoration
|
||||||
|
```
|
||||||
|
|
||||||
|
### Session Summary Generation
|
||||||
|
```
|
||||||
|
/sc:save --summarize
|
||||||
|
# Creates session summary with discovery documentation
|
||||||
|
# Updates cross-session learning patterns and project insights
|
||||||
|
```
|
||||||
|
|
||||||
|
### Discovery-Only Persistence
|
||||||
|
```
|
||||||
|
/sc:save --type learnings
|
||||||
|
# Saves only new patterns and insights discovered during session
|
||||||
|
# Updates project understanding without full session preservation
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Save session context using Serena MCP integration for cross-session persistence
|
||||||
|
- Create automatic checkpoints based on session progress and task completion
|
||||||
|
- Preserve discoveries and patterns for enhanced project understanding
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Operate without proper Serena MCP integration and memory access
|
||||||
|
- Save session data without validation and integrity verification
|
||||||
|
- Override existing session context without proper checkpoint preservation
|
||||||
87
src/superclaude/commands/select-tool.md
Normal file
87
src/superclaude/commands/select-tool.md
Normal file
@@ -0,0 +1,87 @@
|
|||||||
|
---
|
||||||
|
name: select-tool
|
||||||
|
description: "Intelligent MCP tool selection based on complexity scoring and operation analysis"
|
||||||
|
category: special
|
||||||
|
complexity: high
|
||||||
|
mcp-servers: [serena, morphllm]
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:select-tool - Intelligent MCP Tool Selection
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Operations requiring optimal MCP tool selection between Serena and Morphllm
|
||||||
|
- Meta-system decisions needing complexity analysis and capability matching
|
||||||
|
- Tool routing decisions requiring performance vs accuracy trade-offs
|
||||||
|
- Operations benefiting from intelligent tool capability assessment
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:select-tool [operation] [--analyze] [--explain]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Parse**: Analyze operation type, scope, file count, and complexity indicators
|
||||||
|
2. **Score**: Apply multi-dimensional complexity scoring across various operation factors
|
||||||
|
3. **Match**: Compare operation requirements against Serena and Morphllm capabilities
|
||||||
|
4. **Select**: Choose optimal tool based on scoring matrix and performance requirements
|
||||||
|
5. **Validate**: Verify selection accuracy and provide confidence metrics
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Complexity scoring based on file count, operation type, language, and framework requirements
|
||||||
|
- Performance assessment evaluating speed vs accuracy trade-offs for optimal selection
|
||||||
|
- Decision logic matrix with direct mappings and threshold-based routing rules
|
||||||
|
- Tool capability matching for Serena (semantic operations) vs Morphllm (pattern operations)
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Serena MCP**: Optimal for semantic operations, LSP functionality, symbol navigation, and project context
|
||||||
|
- **Morphllm MCP**: Optimal for pattern-based edits, bulk transformations, and speed-critical operations
|
||||||
|
- **Decision Matrix**: Intelligent routing based on complexity scoring and operation characteristics
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **get_current_config**: System configuration analysis for tool capability assessment
|
||||||
|
- **execute_sketched_edit**: Operation testing and validation for selection accuracy
|
||||||
|
- **Read/Grep**: Operation context analysis and complexity factor identification
|
||||||
|
- **Integration**: Automatic selection logic used by refactor, edit, implement, and improve commands
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Direct Mapping**: Symbol operations → Serena, Pattern edits → Morphllm, Memory operations → Serena
|
||||||
|
- **Complexity Thresholds**: Score >0.6 → Serena, Score <0.4 → Morphllm, 0.4-0.6 → Feature-based
|
||||||
|
- **Performance Trade-offs**: Speed requirements → Morphllm, Accuracy requirements → Serena
|
||||||
|
- **Fallback Strategy**: Serena → Morphllm → Native tools degradation chain
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Complex Refactoring Operation
|
||||||
|
```
|
||||||
|
/sc:select-tool "rename function across 10 files" --analyze
|
||||||
|
# Analysis: High complexity (multi-file, symbol operations)
|
||||||
|
# Selection: Serena MCP (LSP capabilities, semantic understanding)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Pattern-Based Bulk Edit
|
||||||
|
```
|
||||||
|
/sc:select-tool "update console.log to logger.info across project" --explain
|
||||||
|
# Analysis: Pattern-based transformation, speed priority
|
||||||
|
# Selection: Morphllm MCP (pattern matching, bulk operations)
|
||||||
|
```
|
||||||
|
|
||||||
|
### Memory Management Operation
|
||||||
|
```
|
||||||
|
/sc:select-tool "save project context and discoveries"
|
||||||
|
# Direct mapping: Memory operations → Serena MCP
|
||||||
|
# Rationale: Project context and cross-session persistence
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Analyze operations and provide optimal tool selection between Serena and Morphllm
|
||||||
|
- Apply complexity scoring based on file count, operation type, and requirements
|
||||||
|
- Provide sub-100ms decision time with >95% selection accuracy
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Override explicit tool specifications when user has clear preference
|
||||||
|
- Select tools without proper complexity analysis and capability matching
|
||||||
|
- Compromise performance requirements for convenience or speed
|
||||||
|
|
||||||
85
src/superclaude/commands/spawn.md
Normal file
85
src/superclaude/commands/spawn.md
Normal file
@@ -0,0 +1,85 @@
|
|||||||
|
---
|
||||||
|
name: spawn
|
||||||
|
description: "Meta-system task orchestration with intelligent breakdown and delegation"
|
||||||
|
category: special
|
||||||
|
complexity: high
|
||||||
|
mcp-servers: []
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:spawn - Meta-System Task Orchestration
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Complex multi-domain operations requiring intelligent task breakdown
|
||||||
|
- Large-scale system operations spanning multiple technical areas
|
||||||
|
- Operations requiring parallel coordination and dependency management
|
||||||
|
- Meta-level orchestration beyond standard command capabilities
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:spawn [complex-task] [--strategy sequential|parallel|adaptive] [--depth normal|deep]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Parse complex operation requirements and assess scope across domains
|
||||||
|
2. **Decompose**: Break down operation into coordinated subtask hierarchies
|
||||||
|
3. **Orchestrate**: Execute tasks using optimal coordination strategy (parallel/sequential)
|
||||||
|
4. **Monitor**: Track progress across task hierarchies with dependency management
|
||||||
|
5. **Integrate**: Aggregate results and provide comprehensive orchestration summary
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Meta-system task decomposition with Epic → Story → Task → Subtask breakdown
|
||||||
|
- Intelligent coordination strategy selection based on operation characteristics
|
||||||
|
- Cross-domain operation management with parallel and sequential execution patterns
|
||||||
|
- Advanced dependency analysis and resource optimization across task hierarchies
|
||||||
|
## MCP Integration
|
||||||
|
- **Native Orchestration**: Meta-system command uses native coordination without MCP dependencies
|
||||||
|
- **Progressive Integration**: Coordination with systematic execution for progressive enhancement
|
||||||
|
- **Framework Integration**: Advanced integration with SuperClaude orchestration layers
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **TodoWrite**: Hierarchical task breakdown and progress tracking across Epic → Story → Task levels
|
||||||
|
- **Read/Grep/Glob**: System analysis and dependency mapping for complex operations
|
||||||
|
- **Edit/MultiEdit/Write**: Coordinated file operations with parallel and sequential execution
|
||||||
|
- **Bash**: System-level operations coordination with intelligent resource management
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Hierarchical Breakdown**: Epic-level operations → Story coordination → Task execution → Subtask granularity
|
||||||
|
- **Strategy Selection**: Sequential (dependency-ordered) → Parallel (independent) → Adaptive (dynamic)
|
||||||
|
- **Meta-System Coordination**: Cross-domain operations → resource optimization → result integration
|
||||||
|
- **Progressive Enhancement**: Systematic execution → quality gates → comprehensive validation
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Complex Feature Implementation
|
||||||
|
```
|
||||||
|
/sc:spawn "implement user authentication system"
|
||||||
|
# Breakdown: Database design → Backend API → Frontend UI → Testing
|
||||||
|
# Coordinates across multiple domains with dependency management
|
||||||
|
```
|
||||||
|
|
||||||
|
### Large-Scale System Operation
|
||||||
|
```
|
||||||
|
/sc:spawn "migrate legacy monolith to microservices" --strategy adaptive --depth deep
|
||||||
|
# Enterprise-scale operation with sophisticated orchestration
|
||||||
|
# Adaptive coordination based on operation characteristics
|
||||||
|
```
|
||||||
|
|
||||||
|
### Cross-Domain Infrastructure
|
||||||
|
```
|
||||||
|
/sc:spawn "establish CI/CD pipeline with security scanning"
|
||||||
|
# System-wide infrastructure operation spanning DevOps, Security, Quality domains
|
||||||
|
# Parallel execution of independent components with validation gates
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Decompose complex multi-domain operations into coordinated task hierarchies
|
||||||
|
- Provide intelligent orchestration with parallel and sequential coordination strategies
|
||||||
|
- Execute meta-system operations beyond standard command capabilities
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Replace domain-specific commands for simple operations
|
||||||
|
- Override user coordination preferences or execution strategies
|
||||||
|
- Execute operations without proper dependency analysis and validation
|
||||||
428
src/superclaude/commands/spec-panel.md
Normal file
428
src/superclaude/commands/spec-panel.md
Normal file
@@ -0,0 +1,428 @@
|
|||||||
|
---
|
||||||
|
name: spec-panel
|
||||||
|
description: "Multi-expert specification review and improvement using renowned specification and software engineering experts"
|
||||||
|
category: analysis
|
||||||
|
complexity: enhanced
|
||||||
|
mcp-servers: [sequential, context7]
|
||||||
|
personas: [technical-writer, system-architect, quality-engineer]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:spec-panel - Expert Specification Review Panel
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Specification quality review and improvement requests
|
||||||
|
- Technical documentation validation and enhancement needs
|
||||||
|
- Requirements analysis and completeness verification
|
||||||
|
- Professional specification writing guidance and mentoring
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:spec-panel [specification_content|@file] [--mode discussion|critique|socratic] [--experts "name1,name2"] [--focus requirements|architecture|testing|compliance] [--iterations N] [--format standard|structured|detailed]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Parse specification content and identify key components, gaps, and quality issues
|
||||||
|
2. **Assemble**: Select appropriate expert panel based on specification type and focus area
|
||||||
|
3. **Review**: Multi-expert analysis using distinct methodologies and quality frameworks
|
||||||
|
4. **Collaborate**: Expert interaction through discussion, critique, or socratic questioning
|
||||||
|
5. **Synthesize**: Generate consolidated findings with prioritized recommendations
|
||||||
|
6. **Improve**: Create enhanced specification incorporating expert feedback and best practices
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Multi-expert perspective analysis with distinct methodologies and quality frameworks
|
||||||
|
- Intelligent expert selection based on specification domain and focus requirements
|
||||||
|
- Structured review process with evidence-based recommendations and improvement guidance
|
||||||
|
- Iterative improvement cycles with quality validation and progress tracking
|
||||||
|
|
||||||
|
## Expert Panel System
|
||||||
|
|
||||||
|
### Core Specification Experts
|
||||||
|
|
||||||
|
**Karl Wiegers** - Requirements Engineering Pioneer
|
||||||
|
- **Domain**: Functional/non-functional requirements, requirement quality frameworks
|
||||||
|
- **Methodology**: SMART criteria, testability analysis, stakeholder validation
|
||||||
|
- **Critique Focus**: "This requirement lacks measurable acceptance criteria. How would you validate compliance in production?"
|
||||||
|
|
||||||
|
**Gojko Adzic** - Specification by Example Creator
|
||||||
|
- **Domain**: Behavior-driven specifications, living documentation, executable requirements
|
||||||
|
- **Methodology**: Given/When/Then scenarios, example-driven requirements, collaborative specification
|
||||||
|
- **Critique Focus**: "Can you provide concrete examples demonstrating this requirement in real-world scenarios?"
|
||||||
|
|
||||||
|
**Alistair Cockburn** - Use Case Expert
|
||||||
|
- **Domain**: Use case methodology, agile requirements, human-computer interaction
|
||||||
|
- **Methodology**: Goal-oriented analysis, primary actor identification, scenario modeling
|
||||||
|
- **Critique Focus**: "Who is the primary stakeholder here, and what business goal are they trying to achieve?"
|
||||||
|
|
||||||
|
**Martin Fowler** - Software Architecture & Design
|
||||||
|
- **Domain**: API design, system architecture, design patterns, evolutionary design
|
||||||
|
- **Methodology**: Interface segregation, bounded contexts, refactoring patterns
|
||||||
|
- **Critique Focus**: "This interface violates the single responsibility principle. Consider separating concerns."
|
||||||
|
|
||||||
|
### Technical Architecture Experts
|
||||||
|
|
||||||
|
**Michael Nygard** - Release It! Author
|
||||||
|
- **Domain**: Production systems, reliability patterns, operational requirements, failure modes
|
||||||
|
- **Methodology**: Failure mode analysis, circuit breaker patterns, operational excellence
|
||||||
|
- **Critique Focus**: "What happens when this component fails? Where are the monitoring and recovery mechanisms?"
|
||||||
|
|
||||||
|
**Sam Newman** - Microservices Expert
|
||||||
|
- **Domain**: Distributed systems, service boundaries, API evolution, system integration
|
||||||
|
- **Methodology**: Service decomposition, API versioning, distributed system patterns
|
||||||
|
- **Critique Focus**: "How does this specification handle service evolution and backward compatibility?"
|
||||||
|
|
||||||
|
**Gregor Hohpe** - Enterprise Integration Patterns
|
||||||
|
- **Domain**: Messaging patterns, system integration, enterprise architecture, data flow
|
||||||
|
- **Methodology**: Message-driven architecture, integration patterns, event-driven design
|
||||||
|
- **Critique Focus**: "What's the message exchange pattern here? How do you handle ordering and delivery guarantees?"
|
||||||
|
|
||||||
|
### Quality & Testing Experts
|
||||||
|
|
||||||
|
**Lisa Crispin** - Agile Testing Expert
|
||||||
|
- **Domain**: Testing strategies, quality requirements, acceptance criteria, test automation
|
||||||
|
- **Methodology**: Whole-team testing, risk-based testing, quality attribute specification
|
||||||
|
- **Critique Focus**: "How would the testing team validate this requirement? What are the edge cases and failure scenarios?"
|
||||||
|
|
||||||
|
**Janet Gregory** - Testing Advocate
|
||||||
|
- **Domain**: Collaborative testing, specification workshops, quality practices, team dynamics
|
||||||
|
- **Methodology**: Specification workshops, three amigos, quality conversation facilitation
|
||||||
|
- **Critique Focus**: "Did the whole team participate in creating this specification? Are quality expectations clearly defined?"
|
||||||
|
|
||||||
|
### Modern Software Experts
|
||||||
|
|
||||||
|
**Kelsey Hightower** - Cloud Native Expert
|
||||||
|
- **Domain**: Kubernetes, cloud architecture, operational excellence, infrastructure as code
|
||||||
|
- **Methodology**: Cloud-native patterns, infrastructure automation, operational observability
|
||||||
|
- **Critique Focus**: "How does this specification handle cloud-native deployment and operational concerns?"
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Sequential MCP**: Primary engine for expert panel coordination, structured analysis, and iterative improvement
|
||||||
|
- **Context7 MCP**: Auto-activated for specification patterns, documentation standards, and industry best practices
|
||||||
|
- **Technical Writer Persona**: Activated for professional specification writing and documentation quality
|
||||||
|
- **System Architect Persona**: Activated for architectural analysis and system design validation
|
||||||
|
- **Quality Engineer Persona**: Activated for quality assessment and testing strategy validation
|
||||||
|
|
||||||
|
## Analysis Modes
|
||||||
|
|
||||||
|
### Discussion Mode (`--mode discussion`)
|
||||||
|
**Purpose**: Collaborative improvement through expert dialogue and knowledge sharing
|
||||||
|
|
||||||
|
**Expert Interaction Pattern**:
|
||||||
|
- Sequential expert commentary building upon previous insights
|
||||||
|
- Cross-expert validation and refinement of recommendations
|
||||||
|
- Consensus building around critical improvements
|
||||||
|
- Collaborative solution development
|
||||||
|
|
||||||
|
**Example Output**:
|
||||||
|
```
|
||||||
|
KARL WIEGERS: "The requirement 'SHALL handle failures gracefully' lacks specificity.
|
||||||
|
What constitutes graceful handling? What types of failures are we addressing?"
|
||||||
|
|
||||||
|
MICHAEL NYGARD: "Building on Karl's point, we need specific failure modes: network
|
||||||
|
timeouts, service unavailable, rate limiting. Each requires different handling strategies."
|
||||||
|
|
||||||
|
GOJKO ADZIC: "Let's make this concrete with examples:
|
||||||
|
Given: Service timeout after 30 seconds
|
||||||
|
When: Circuit breaker activates
|
||||||
|
Then: Return cached response within 100ms"
|
||||||
|
|
||||||
|
MARTIN FOWLER: "The specification should also define the failure notification interface.
|
||||||
|
How do upstream services know what type of failure occurred?"
|
||||||
|
```
|
||||||
|
|
||||||
|
### Critique Mode (`--mode critique`)
|
||||||
|
**Purpose**: Systematic review with specific improvement suggestions and priority rankings
|
||||||
|
|
||||||
|
**Analysis Structure**:
|
||||||
|
- Issue identification with severity classification
|
||||||
|
- Specific improvement recommendations with rationale
|
||||||
|
- Priority ranking based on impact and effort
|
||||||
|
- Quality metrics and validation criteria
|
||||||
|
|
||||||
|
**Example Output**:
|
||||||
|
```
|
||||||
|
=== REQUIREMENTS ANALYSIS ===
|
||||||
|
|
||||||
|
KARL WIEGERS - Requirements Quality Assessment:
|
||||||
|
❌ CRITICAL: Requirement R-001 lacks measurable acceptance criteria
|
||||||
|
📝 RECOMMENDATION: Replace "handle failures gracefully" with "open circuit breaker after 5 consecutive failures within 30 seconds"
|
||||||
|
🎯 PRIORITY: High - Affects testability and validation
|
||||||
|
📊 QUALITY IMPACT: +40% testability, +60% clarity
|
||||||
|
|
||||||
|
GOJKO ADZIC - Specification Testability:
|
||||||
|
⚠️ MAJOR: No executable examples provided for complex behaviors
|
||||||
|
📝 RECOMMENDATION: Add Given/When/Then scenarios for each requirement
|
||||||
|
🎯 PRIORITY: Medium - Improves understanding and validation
|
||||||
|
📊 QUALITY IMPACT: +50% comprehensibility, +35% validation coverage
|
||||||
|
|
||||||
|
=== ARCHITECTURE ANALYSIS ===
|
||||||
|
|
||||||
|
MARTIN FOWLER - Interface Design:
|
||||||
|
⚠️ MINOR: CircuitBreaker interface couples state management with execution logic
|
||||||
|
📝 RECOMMENDATION: Separate CircuitBreakerState from CircuitBreakerExecutor
|
||||||
|
🎯 PRIORITY: Low - Design improvement, not functional issue
|
||||||
|
📊 QUALITY IMPACT: +20% maintainability, +15% testability
|
||||||
|
```
|
||||||
|
|
||||||
|
### Socratic Mode (`--mode socratic`)
|
||||||
|
**Purpose**: Learning-focused questioning to deepen understanding and improve thinking
|
||||||
|
|
||||||
|
**Question Categories**:
|
||||||
|
- Foundational understanding questions
|
||||||
|
- Stakeholder and purpose clarification
|
||||||
|
- Assumption identification and validation
|
||||||
|
- Alternative approach exploration
|
||||||
|
|
||||||
|
**Example Output**:
|
||||||
|
```
|
||||||
|
ALISTAIR COCKBURN: "What is the fundamental problem this specification is trying to solve?"
|
||||||
|
|
||||||
|
KARL WIEGERS: "Who are the primary stakeholders affected by these requirements?"
|
||||||
|
|
||||||
|
MICHAEL NYGARD: "What assumptions are you making about the deployment environment and operational context?"
|
||||||
|
|
||||||
|
GOJKO ADZIC: "How would you explain these requirements to a non-technical business stakeholder?"
|
||||||
|
|
||||||
|
MARTIN FOWLER: "What would happen if we removed this requirement entirely? What breaks?"
|
||||||
|
|
||||||
|
LISA CRISPIN: "How would you validate that this specification is working correctly in production?"
|
||||||
|
|
||||||
|
KELSEY HIGHTOWER: "What operational and monitoring capabilities does this specification require?"
|
||||||
|
```
|
||||||
|
|
||||||
|
## Focus Areas
|
||||||
|
|
||||||
|
### Requirements Focus (`--focus requirements`)
|
||||||
|
**Expert Panel**: Wiegers (lead), Adzic, Cockburn
|
||||||
|
**Analysis Areas**:
|
||||||
|
- Requirement clarity, completeness, and consistency
|
||||||
|
- Testability and measurability assessment
|
||||||
|
- Stakeholder needs alignment and validation
|
||||||
|
- Acceptance criteria quality and coverage
|
||||||
|
- Requirements traceability and verification
|
||||||
|
|
||||||
|
### Architecture Focus (`--focus architecture`)
|
||||||
|
**Expert Panel**: Fowler (lead), Newman, Hohpe, Nygard
|
||||||
|
**Analysis Areas**:
|
||||||
|
- Interface design quality and consistency
|
||||||
|
- System boundary definitions and service decomposition
|
||||||
|
- Scalability and maintainability characteristics
|
||||||
|
- Design pattern appropriateness and implementation
|
||||||
|
- Integration and communication specifications
|
||||||
|
|
||||||
|
### Testing Focus (`--focus testing`)
|
||||||
|
**Expert Panel**: Crispin (lead), Gregory, Adzic
|
||||||
|
**Analysis Areas**:
|
||||||
|
- Test strategy and coverage requirements
|
||||||
|
- Quality attribute specifications and validation
|
||||||
|
- Edge case identification and handling
|
||||||
|
- Acceptance criteria and definition of done
|
||||||
|
- Test automation and continuous validation
|
||||||
|
|
||||||
|
### Compliance Focus (`--focus compliance`)
|
||||||
|
**Expert Panel**: Wiegers (lead), Nygard, Hightower
|
||||||
|
**Analysis Areas**:
|
||||||
|
- Regulatory requirement coverage and validation
|
||||||
|
- Security specifications and threat modeling
|
||||||
|
- Operational requirements and observability
|
||||||
|
- Audit trail and compliance verification
|
||||||
|
- Risk assessment and mitigation strategies
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read**: Specification content analysis and parsing
|
||||||
|
- **Sequential**: Expert panel coordination and iterative analysis
|
||||||
|
- **Context7**: Specification patterns and industry best practices
|
||||||
|
- **Grep**: Cross-reference validation and consistency checking
|
||||||
|
- **Write**: Improved specification generation and report creation
|
||||||
|
- **MultiEdit**: Collaborative specification enhancement and refinement
|
||||||
|
|
||||||
|
## Iterative Improvement Process
|
||||||
|
|
||||||
|
### Single Iteration (Default)
|
||||||
|
1. **Initial Analysis**: Expert panel reviews specification
|
||||||
|
2. **Issue Identification**: Systematic problem and gap identification
|
||||||
|
3. **Improvement Recommendations**: Specific, actionable enhancement suggestions
|
||||||
|
4. **Priority Ranking**: Critical path and impact-based prioritization
|
||||||
|
|
||||||
|
### Multi-Iteration (`--iterations N`)
|
||||||
|
**Iteration 1**: Structural and fundamental issues
|
||||||
|
- Requirements clarity and completeness
|
||||||
|
- Architecture consistency and boundaries
|
||||||
|
- Major gaps and critical problems
|
||||||
|
|
||||||
|
**Iteration 2**: Detail refinement and enhancement
|
||||||
|
- Specific improvement implementation
|
||||||
|
- Edge case handling and error scenarios
|
||||||
|
- Quality attribute specifications
|
||||||
|
|
||||||
|
**Iteration 3**: Polish and optimization
|
||||||
|
- Documentation quality and clarity
|
||||||
|
- Example and scenario enhancement
|
||||||
|
- Final validation and consistency checks
|
||||||
|
|
||||||
|
## Output Formats
|
||||||
|
|
||||||
|
### Standard Format (`--format standard`)
|
||||||
|
```yaml
|
||||||
|
specification_review:
|
||||||
|
original_spec: "authentication_service.spec.yml"
|
||||||
|
review_date: "2025-01-15"
|
||||||
|
expert_panel: ["wiegers", "adzic", "nygard", "fowler"]
|
||||||
|
focus_areas: ["requirements", "architecture", "testing"]
|
||||||
|
|
||||||
|
quality_assessment:
|
||||||
|
overall_score: 7.2/10
|
||||||
|
requirements_quality: 8.1/10
|
||||||
|
architecture_clarity: 6.8/10
|
||||||
|
testability_score: 7.5/10
|
||||||
|
|
||||||
|
critical_issues:
|
||||||
|
- category: "requirements"
|
||||||
|
severity: "high"
|
||||||
|
expert: "wiegers"
|
||||||
|
issue: "Authentication timeout not specified"
|
||||||
|
recommendation: "Define session timeout with configurable values"
|
||||||
|
|
||||||
|
- category: "architecture"
|
||||||
|
severity: "medium"
|
||||||
|
expert: "fowler"
|
||||||
|
issue: "Token refresh mechanism unclear"
|
||||||
|
recommendation: "Specify refresh token lifecycle and rotation policy"
|
||||||
|
|
||||||
|
expert_consensus:
|
||||||
|
- "Specification needs concrete failure handling definitions"
|
||||||
|
- "Missing operational monitoring and alerting requirements"
|
||||||
|
- "Authentication flow is well-defined but lacks error scenarios"
|
||||||
|
|
||||||
|
improvement_roadmap:
|
||||||
|
immediate: ["Define timeout specifications", "Add error handling scenarios"]
|
||||||
|
short_term: ["Specify monitoring requirements", "Add performance criteria"]
|
||||||
|
long_term: ["Comprehensive security review", "Integration testing strategy"]
|
||||||
|
```
|
||||||
|
|
||||||
|
### Structured Format (`--format structured`)
|
||||||
|
Token-efficient format using SuperClaude symbol system for concise communication.
|
||||||
|
|
||||||
|
### Detailed Format (`--format detailed`)
|
||||||
|
Comprehensive analysis with full expert commentary, examples, and implementation guidance.
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### API Specification Review
|
||||||
|
```
|
||||||
|
/sc:spec-panel @auth_api.spec.yml --mode critique --focus requirements,architecture
|
||||||
|
# Comprehensive API specification review
|
||||||
|
# Focus on requirements quality and architectural consistency
|
||||||
|
# Generate detailed improvement recommendations
|
||||||
|
```
|
||||||
|
|
||||||
|
### Requirements Workshop
|
||||||
|
```
|
||||||
|
/sc:spec-panel "user story content" --mode discussion --experts "wiegers,adzic,cockburn"
|
||||||
|
# Collaborative requirements analysis and improvement
|
||||||
|
# Expert dialogue for requirement refinement
|
||||||
|
# Consensus building around acceptance criteria
|
||||||
|
```
|
||||||
|
|
||||||
|
### Architecture Validation
|
||||||
|
```
|
||||||
|
/sc:spec-panel @microservice.spec.yml --mode socratic --focus architecture
|
||||||
|
# Learning-focused architectural review
|
||||||
|
# Deep questioning about design decisions
|
||||||
|
# Alternative approach exploration
|
||||||
|
```
|
||||||
|
|
||||||
|
### Iterative Improvement
|
||||||
|
```
|
||||||
|
/sc:spec-panel @complex_system.spec.yml --iterations 3 --format detailed
|
||||||
|
# Multi-iteration improvement process
|
||||||
|
# Progressive refinement with expert guidance
|
||||||
|
# Comprehensive quality enhancement
|
||||||
|
```
|
||||||
|
|
||||||
|
### Compliance Review
|
||||||
|
```
|
||||||
|
/sc:spec-panel @security_requirements.yml --focus compliance --experts "wiegers,nygard"
|
||||||
|
# Compliance and security specification review
|
||||||
|
# Regulatory requirement validation
|
||||||
|
# Risk assessment and mitigation planning
|
||||||
|
```
|
||||||
|
|
||||||
|
## Integration Patterns
|
||||||
|
|
||||||
|
### Workflow Integration with /sc:code-to-spec
|
||||||
|
```bash
|
||||||
|
# Generate initial specification from code
|
||||||
|
/sc:code-to-spec ./authentication_service --type api --format yaml
|
||||||
|
|
||||||
|
# Review and improve with expert panel
|
||||||
|
/sc:spec-panel @generated_auth_spec.yml --mode critique --focus requirements,testing
|
||||||
|
|
||||||
|
# Iterative refinement based on feedback
|
||||||
|
/sc:spec-panel @improved_auth_spec.yml --mode discussion --iterations 2
|
||||||
|
```
|
||||||
|
|
||||||
|
### Learning and Development Workflow
|
||||||
|
```bash
|
||||||
|
# Start with socratic mode for learning
|
||||||
|
/sc:spec-panel @my_first_spec.yml --mode socratic --iterations 2
|
||||||
|
|
||||||
|
# Apply learnings with discussion mode
|
||||||
|
/sc:spec-panel @revised_spec.yml --mode discussion --focus requirements
|
||||||
|
|
||||||
|
# Final quality validation with critique mode
|
||||||
|
/sc:spec-panel @final_spec.yml --mode critique --format detailed
|
||||||
|
```
|
||||||
|
|
||||||
|
## Quality Assurance Features
|
||||||
|
|
||||||
|
### Expert Validation
|
||||||
|
- Cross-expert consistency checking and validation
|
||||||
|
- Methodology alignment and best practice verification
|
||||||
|
- Quality metric calculation and progress tracking
|
||||||
|
- Recommendation prioritization and impact assessment
|
||||||
|
|
||||||
|
### Specification Quality Metrics
|
||||||
|
- **Clarity Score**: Language precision and understandability (0-10)
|
||||||
|
- **Completeness Score**: Coverage of essential specification elements (0-10)
|
||||||
|
- **Testability Score**: Measurability and validation capability (0-10)
|
||||||
|
- **Consistency Score**: Internal coherence and contradiction detection (0-10)
|
||||||
|
|
||||||
|
### Continuous Improvement
|
||||||
|
- Pattern recognition from successful improvements
|
||||||
|
- Expert recommendation effectiveness tracking
|
||||||
|
- Specification quality trend analysis
|
||||||
|
- Best practice pattern library development
|
||||||
|
|
||||||
|
## Advanced Features
|
||||||
|
|
||||||
|
### Custom Expert Panels
|
||||||
|
- Domain-specific expert selection and configuration
|
||||||
|
- Industry-specific methodology application
|
||||||
|
- Custom quality criteria and assessment frameworks
|
||||||
|
- Specialized review processes for unique requirements
|
||||||
|
|
||||||
|
### Integration with Development Workflow
|
||||||
|
- CI/CD pipeline integration for specification validation
|
||||||
|
- Version control integration for specification evolution tracking
|
||||||
|
- IDE integration for inline specification quality feedback
|
||||||
|
- Automated quality gate enforcement and validation
|
||||||
|
|
||||||
|
### Learning and Mentoring
|
||||||
|
- Progressive skill development tracking and guidance
|
||||||
|
- Specification writing pattern recognition and teaching
|
||||||
|
- Best practice library development and sharing
|
||||||
|
- Mentoring mode with educational focus and guidance
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Provide expert-level specification review and improvement guidance
|
||||||
|
- Generate specific, actionable recommendations with priority rankings
|
||||||
|
- Support multiple analysis modes for different use cases and learning objectives
|
||||||
|
- Integrate with specification generation tools for comprehensive workflow support
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Replace human judgment and domain expertise in critical decisions
|
||||||
|
- Modify specifications without explicit user consent and validation
|
||||||
|
- Generate specifications from scratch without existing content or context
|
||||||
|
- Provide legal or regulatory compliance guarantees beyond analysis guidance
|
||||||
89
src/superclaude/commands/task.md
Normal file
89
src/superclaude/commands/task.md
Normal file
@@ -0,0 +1,89 @@
|
|||||||
|
---
|
||||||
|
name: task
|
||||||
|
description: "Execute complex tasks with intelligent workflow management and delegation"
|
||||||
|
category: special
|
||||||
|
complexity: advanced
|
||||||
|
mcp-servers: [sequential, context7, magic, playwright, morphllm, serena]
|
||||||
|
personas: [architect, analyzer, frontend, backend, security, devops, project-manager]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:task - Enhanced Task Management
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Complex tasks requiring multi-agent coordination and delegation
|
||||||
|
- Projects needing structured workflow management and cross-session persistence
|
||||||
|
- Operations requiring intelligent MCP server routing and domain expertise
|
||||||
|
- Tasks benefiting from systematic execution and progressive enhancement
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:task [action] [target] [--strategy systematic|agile|enterprise] [--parallel] [--delegate]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Parse task requirements and determine optimal execution strategy
|
||||||
|
2. **Delegate**: Route to appropriate MCP servers and activate relevant personas
|
||||||
|
3. **Coordinate**: Execute tasks with intelligent workflow management and parallel processing
|
||||||
|
4. **Validate**: Apply quality gates and comprehensive task completion verification
|
||||||
|
5. **Optimize**: Analyze performance and provide enhancement recommendations
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Multi-persona coordination across architect, frontend, backend, security, devops domains
|
||||||
|
- Intelligent MCP server routing (Sequential, Context7, Magic, Playwright, Morphllm, Serena)
|
||||||
|
- Systematic execution with progressive task enhancement and cross-session persistence
|
||||||
|
- Advanced task delegation with hierarchical breakdown and dependency management
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Sequential MCP**: Complex multi-step task analysis and systematic execution planning
|
||||||
|
- **Context7 MCP**: Framework-specific patterns and implementation best practices
|
||||||
|
- **Magic MCP**: UI/UX task coordination and design system integration
|
||||||
|
- **Playwright MCP**: Testing workflow integration and validation automation
|
||||||
|
- **Morphllm MCP**: Large-scale task transformation and pattern-based optimization
|
||||||
|
- **Serena MCP**: Cross-session task persistence and project memory management
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **TodoWrite**: Hierarchical task breakdown and progress tracking across Epic → Story → Task levels
|
||||||
|
- **Task**: Advanced delegation for complex multi-agent coordination and sub-task management
|
||||||
|
- **Read/Write/Edit**: Task documentation and implementation coordination
|
||||||
|
- **sequentialthinking**: Structured reasoning for complex task dependency analysis
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Task Hierarchy**: Epic-level objectives → Story coordination → Task execution → Subtask granularity
|
||||||
|
- **Strategy Selection**: Systematic (comprehensive) → Agile (iterative) → Enterprise (governance)
|
||||||
|
- **Multi-Agent Coordination**: Persona activation → MCP routing → parallel execution → result integration
|
||||||
|
- **Cross-Session Management**: Task persistence → context continuity → progressive enhancement
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Complex Feature Development
|
||||||
|
```
|
||||||
|
/sc:task create "enterprise authentication system" --strategy systematic --parallel
|
||||||
|
# Comprehensive task breakdown with multi-domain coordination
|
||||||
|
# Activates architect, security, backend, frontend personas
|
||||||
|
```
|
||||||
|
|
||||||
|
### Agile Sprint Coordination
|
||||||
|
```
|
||||||
|
/sc:task execute "feature backlog" --strategy agile --delegate
|
||||||
|
# Iterative task execution with intelligent delegation
|
||||||
|
# Cross-session persistence for sprint continuity
|
||||||
|
```
|
||||||
|
|
||||||
|
### Multi-Domain Integration
|
||||||
|
```
|
||||||
|
/sc:task execute "microservices platform" --strategy enterprise --parallel
|
||||||
|
# Enterprise-scale coordination with compliance validation
|
||||||
|
# Parallel execution across multiple technical domains
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Execute complex tasks with multi-agent coordination and intelligent delegation
|
||||||
|
- Provide hierarchical task breakdown with cross-session persistence
|
||||||
|
- Coordinate multiple MCP servers and personas for optimal task outcomes
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Execute simple tasks that don't require advanced orchestration
|
||||||
|
- Compromise quality standards for speed or convenience
|
||||||
|
- Operate without proper validation and quality gates
|
||||||
93
src/superclaude/commands/test.md
Normal file
93
src/superclaude/commands/test.md
Normal file
@@ -0,0 +1,93 @@
|
|||||||
|
---
|
||||||
|
name: test
|
||||||
|
description: "Execute tests with coverage analysis and automated quality reporting"
|
||||||
|
category: utility
|
||||||
|
complexity: enhanced
|
||||||
|
mcp-servers: [playwright]
|
||||||
|
personas: [qa-specialist]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:test - Testing and Quality Assurance
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Test execution requests for unit, integration, or e2e tests
|
||||||
|
- Coverage analysis and quality gate validation needs
|
||||||
|
- Continuous testing and watch mode scenarios
|
||||||
|
- Test failure analysis and debugging requirements
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:test [target] [--type unit|integration|e2e|all] [--coverage] [--watch] [--fix]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Discover**: Categorize available tests using runner patterns and conventions
|
||||||
|
2. **Configure**: Set up appropriate test environment and execution parameters
|
||||||
|
3. **Execute**: Run tests with monitoring and real-time progress tracking
|
||||||
|
4. **Analyze**: Generate coverage reports and failure diagnostics
|
||||||
|
5. **Report**: Provide actionable recommendations and quality metrics
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Auto-detect test framework and configuration
|
||||||
|
- Generate comprehensive coverage reports with metrics
|
||||||
|
- Activate Playwright MCP for e2e browser testing
|
||||||
|
- Provide intelligent test failure analysis
|
||||||
|
- Support continuous watch mode for development
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Playwright MCP**: Auto-activated for `--type e2e` browser testing
|
||||||
|
- **QA Specialist Persona**: Activated for test analysis and quality assessment
|
||||||
|
- **Enhanced Capabilities**: Cross-browser testing, visual validation, performance metrics
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Bash**: Test runner execution and environment management
|
||||||
|
- **Glob**: Test discovery and file pattern matching
|
||||||
|
- **Grep**: Result parsing and failure analysis
|
||||||
|
- **Write**: Coverage reports and test summaries
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Test Discovery**: Pattern-based categorization → appropriate runner selection
|
||||||
|
- **Coverage Analysis**: Execution metrics → comprehensive coverage reporting
|
||||||
|
- **E2E Testing**: Browser automation → cross-platform validation
|
||||||
|
- **Watch Mode**: File monitoring → continuous test execution
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Basic Test Execution
|
||||||
|
```
|
||||||
|
/sc:test
|
||||||
|
# Discovers and runs all tests with standard configuration
|
||||||
|
# Generates pass/fail summary and basic coverage
|
||||||
|
```
|
||||||
|
|
||||||
|
### Targeted Coverage Analysis
|
||||||
|
```
|
||||||
|
/sc:test src/components --type unit --coverage
|
||||||
|
# Unit tests for specific directory with detailed coverage metrics
|
||||||
|
```
|
||||||
|
|
||||||
|
### Browser Testing
|
||||||
|
```
|
||||||
|
/sc:test --type e2e
|
||||||
|
# Activates Playwright MCP for comprehensive browser testing
|
||||||
|
# Cross-browser compatibility and visual validation
|
||||||
|
```
|
||||||
|
|
||||||
|
### Development Watch Mode
|
||||||
|
```
|
||||||
|
/sc:test --watch --fix
|
||||||
|
# Continuous testing with automatic simple failure fixes
|
||||||
|
# Real-time feedback during development
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Execute existing test suites using project's configured test runner
|
||||||
|
- Generate coverage reports and quality metrics
|
||||||
|
- Provide intelligent test failure analysis with actionable recommendations
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Generate test cases or modify test framework configuration
|
||||||
|
- Execute tests requiring external services without proper setup
|
||||||
|
- Make destructive changes to test files without explicit permission
|
||||||
88
src/superclaude/commands/troubleshoot.md
Normal file
88
src/superclaude/commands/troubleshoot.md
Normal file
@@ -0,0 +1,88 @@
|
|||||||
|
---
|
||||||
|
name: troubleshoot
|
||||||
|
description: "Diagnose and resolve issues in code, builds, deployments, and system behavior"
|
||||||
|
category: utility
|
||||||
|
complexity: basic
|
||||||
|
mcp-servers: []
|
||||||
|
personas: []
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:troubleshoot - Issue Diagnosis and Resolution
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- Code defects and runtime error investigation requests
|
||||||
|
- Build failure analysis and resolution needs
|
||||||
|
- Performance issue diagnosis and optimization requirements
|
||||||
|
- Deployment problem analysis and system behavior debugging
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:troubleshoot [issue] [--type bug|build|performance|deployment] [--trace] [--fix]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Examine issue description and gather relevant system state information
|
||||||
|
2. **Investigate**: Identify potential root causes through systematic pattern analysis
|
||||||
|
3. **Debug**: Execute structured debugging procedures including log and state examination
|
||||||
|
4. **Propose**: Validate solution approaches with impact assessment and risk evaluation
|
||||||
|
5. **Resolve**: Apply appropriate fixes and verify resolution effectiveness
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Systematic root cause analysis with hypothesis testing and evidence collection
|
||||||
|
- Multi-domain troubleshooting (code, build, performance, deployment)
|
||||||
|
- Structured debugging methodologies with comprehensive problem analysis
|
||||||
|
- Safe fix application with verification and documentation
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read**: Log analysis and system state examination
|
||||||
|
- **Bash**: Diagnostic command execution and system investigation
|
||||||
|
- **Grep**: Error pattern detection and log analysis
|
||||||
|
- **Write**: Diagnostic reports and resolution documentation
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **Bug Investigation**: Error analysis → stack trace examination → code inspection → fix validation
|
||||||
|
- **Build Troubleshooting**: Build log analysis → dependency checking → configuration validation
|
||||||
|
- **Performance Diagnosis**: Metrics analysis → bottleneck identification → optimization recommendations
|
||||||
|
- **Deployment Issues**: Environment analysis → configuration verification → service validation
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Code Bug Investigation
|
||||||
|
```
|
||||||
|
/sc:troubleshoot "Null pointer exception in user service" --type bug --trace
|
||||||
|
# Systematic analysis of error context and stack traces
|
||||||
|
# Identifies root cause and provides targeted fix recommendations
|
||||||
|
```
|
||||||
|
|
||||||
|
### Build Failure Analysis
|
||||||
|
```
|
||||||
|
/sc:troubleshoot "TypeScript compilation errors" --type build --fix
|
||||||
|
# Analyzes build logs and TypeScript configuration
|
||||||
|
# Automatically applies safe fixes for common compilation issues
|
||||||
|
```
|
||||||
|
|
||||||
|
### Performance Issue Diagnosis
|
||||||
|
```
|
||||||
|
/sc:troubleshoot "API response times degraded" --type performance
|
||||||
|
# Performance metrics analysis and bottleneck identification
|
||||||
|
# Provides optimization recommendations and monitoring guidance
|
||||||
|
```
|
||||||
|
|
||||||
|
### Deployment Problem Resolution
|
||||||
|
```
|
||||||
|
/sc:troubleshoot "Service not starting in production" --type deployment --trace
|
||||||
|
# Environment and configuration analysis
|
||||||
|
# Systematic verification of deployment requirements and dependencies
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Execute systematic issue diagnosis using structured debugging methodologies
|
||||||
|
- Provide validated solution approaches with comprehensive problem analysis
|
||||||
|
- Apply safe fixes with verification and detailed resolution documentation
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Apply risky fixes without proper analysis and user confirmation
|
||||||
|
- Modify production systems without explicit permission and safety validation
|
||||||
|
- Make architectural changes without understanding full system impact
|
||||||
97
src/superclaude/commands/workflow.md
Normal file
97
src/superclaude/commands/workflow.md
Normal file
@@ -0,0 +1,97 @@
|
|||||||
|
---
|
||||||
|
name: workflow
|
||||||
|
description: "Generate structured implementation workflows from PRDs and feature requirements"
|
||||||
|
category: orchestration
|
||||||
|
complexity: advanced
|
||||||
|
mcp-servers: [sequential, context7, magic, playwright, morphllm, serena]
|
||||||
|
personas: [architect, analyzer, frontend, backend, security, devops, project-manager]
|
||||||
|
---
|
||||||
|
|
||||||
|
# /sc:workflow - Implementation Workflow Generator
|
||||||
|
|
||||||
|
## Triggers
|
||||||
|
- PRD and feature specification analysis for implementation planning
|
||||||
|
- Structured workflow generation for development projects
|
||||||
|
- Multi-persona coordination for complex implementation strategies
|
||||||
|
- Cross-session workflow management and dependency mapping
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
```
|
||||||
|
/sc:workflow [prd-file|feature-description] [--strategy systematic|agile|enterprise] [--depth shallow|normal|deep] [--parallel]
|
||||||
|
```
|
||||||
|
|
||||||
|
## Behavioral Flow
|
||||||
|
1. **Analyze**: Parse PRD and feature specifications to understand implementation requirements
|
||||||
|
2. **Plan**: Generate comprehensive workflow structure with dependency mapping and task orchestration
|
||||||
|
3. **Coordinate**: Activate multiple personas for domain expertise and implementation strategy
|
||||||
|
4. **Execute**: Create structured step-by-step workflows with automated task coordination
|
||||||
|
5. **Validate**: Apply quality gates and ensure workflow completeness across domains
|
||||||
|
|
||||||
|
Key behaviors:
|
||||||
|
- Multi-persona orchestration across architecture, frontend, backend, security, and devops domains
|
||||||
|
- Advanced MCP coordination with intelligent routing for specialized workflow analysis
|
||||||
|
- Systematic execution with progressive workflow enhancement and parallel processing
|
||||||
|
- Cross-session workflow management with comprehensive dependency tracking
|
||||||
|
|
||||||
|
## MCP Integration
|
||||||
|
- **Sequential MCP**: Complex multi-step workflow analysis and systematic implementation planning
|
||||||
|
- **Context7 MCP**: Framework-specific workflow patterns and implementation best practices
|
||||||
|
- **Magic MCP**: UI/UX workflow generation and design system integration strategies
|
||||||
|
- **Playwright MCP**: Testing workflow integration and quality assurance automation
|
||||||
|
- **Morphllm MCP**: Large-scale workflow transformation and pattern-based optimization
|
||||||
|
- **Serena MCP**: Cross-session workflow persistence, memory management, and project context
|
||||||
|
|
||||||
|
## Tool Coordination
|
||||||
|
- **Read/Write/Edit**: PRD analysis and workflow documentation generation
|
||||||
|
- **TodoWrite**: Progress tracking for complex multi-phase workflow execution
|
||||||
|
- **Task**: Advanced delegation for parallel workflow generation and multi-agent coordination
|
||||||
|
- **WebSearch**: Technology research, framework validation, and implementation strategy analysis
|
||||||
|
- **sequentialthinking**: Structured reasoning for complex workflow dependency analysis
|
||||||
|
|
||||||
|
## Key Patterns
|
||||||
|
- **PRD Analysis**: Document parsing → requirement extraction → implementation strategy development
|
||||||
|
- **Workflow Generation**: Task decomposition → dependency mapping → structured implementation planning
|
||||||
|
- **Multi-Domain Coordination**: Cross-functional expertise → comprehensive implementation strategies
|
||||||
|
- **Quality Integration**: Workflow validation → testing strategies → deployment planning
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Systematic PRD Workflow
|
||||||
|
```
|
||||||
|
/sc:workflow Claudedocs/PRD/feature-spec.md --strategy systematic --depth deep
|
||||||
|
# Comprehensive PRD analysis with systematic workflow generation
|
||||||
|
# Multi-persona coordination for complete implementation strategy
|
||||||
|
```
|
||||||
|
|
||||||
|
### Agile Feature Workflow
|
||||||
|
```
|
||||||
|
/sc:workflow "user authentication system" --strategy agile --parallel
|
||||||
|
# Agile workflow generation with parallel task coordination
|
||||||
|
# Context7 and Magic MCP for framework and UI workflow patterns
|
||||||
|
```
|
||||||
|
|
||||||
|
### Enterprise Implementation Planning
|
||||||
|
```
|
||||||
|
/sc:workflow enterprise-prd.md --strategy enterprise --validate
|
||||||
|
# Enterprise-scale workflow with comprehensive validation
|
||||||
|
# Security, devops, and architect personas for compliance and scalability
|
||||||
|
```
|
||||||
|
|
||||||
|
### Cross-Session Workflow Management
|
||||||
|
```
|
||||||
|
/sc:workflow project-brief.md --depth normal
|
||||||
|
# Serena MCP manages cross-session workflow context and persistence
|
||||||
|
# Progressive workflow enhancement with memory-driven insights
|
||||||
|
```
|
||||||
|
|
||||||
|
## Boundaries
|
||||||
|
|
||||||
|
**Will:**
|
||||||
|
- Generate comprehensive implementation workflows from PRD and feature specifications
|
||||||
|
- Coordinate multiple personas and MCP servers for complete implementation strategies
|
||||||
|
- Provide cross-session workflow management and progressive enhancement capabilities
|
||||||
|
|
||||||
|
**Will Not:**
|
||||||
|
- Execute actual implementation tasks beyond workflow planning and strategy
|
||||||
|
- Override established development processes without proper analysis and validation
|
||||||
|
- Generate workflows without comprehensive requirement analysis and dependency mapping
|
||||||
Reference in New Issue
Block a user