docs/user-guide-jp/modes.md
コマンドを使用してモードをテストします/sc:。モードはタスクの複雑さに基づいて自動的にアクティブになります。コマンドの完全なリファレンスについては、コマンドガイドをご覧ください。
| モード | 目的 | 自動トリガー | 重要な行動 | 最適な用途 |
|---|---|---|---|---|
| 🧠 ブレインストーミング | インタラクティブな発見 | 「ブレインストーミング」、「たぶん」、漠然とした要望 | ソクラテス式の質問、要件の抽出 | 新しいプロジェクトの計画、不明確な要件 |
| 🔍 内省 | メタ認知分析 | エラー回復、「推論の分析」 | 透明な思考マーカー(🤔、🎯、💡) | デバッグ、学習、最適化 |
| 📋 タスク管理 | 複雑な調整 | >3ステップ、>2ディレクトリ | 相の崩壊、記憶の持続 | 多段階操作、プロジェクト管理 |
| 🎯 オーケストレーション | インテリジェントなツール選択 | 複数のツールを使用した操作、高いリソース使用率 | 最適なツールルーティング、並列実行 | 複雑な分析、パフォーマンスの最適化 |
| ⚡ トークン効率 | 圧縮通信 | コンテキスト使用率が高い、--ucフラグ | シンボルシステム、推定30~50%のトークン削減 | リソースの制約、大規模な操作 |
モードは動作指示を通じてアクティブ化されます- Claude Code はコンテキスト ファイルを読み取り、タスクのパターンと複雑さに基づいてどのモード動作を採用するかを決定します。
簡単な例:
# Automatic activation examples
/sc:brainstorm "mobile app" # → Socratic discovery questions
/sc:implement "auth system" # → Multi-phase coordination
"--uc analyze large-codebase/" # → Compressed symbol output
手動フラグを使用する場合:
--brainstorm、、--introspect``--uc目的: 共同作業による発見を通じて、漠然としたアイデアを構造化された要件に変換します。
自動アクティベーショントリガー:
--brainstorm、--bs行動の変化:
経験例:
Standard Approach: "I'll build a user authentication system with JWT tokens..."
Brainstorming Approach:
"🤔 Let's explore this together:
- What specific user problems does auth solve for your app?
- Who are your users and what's their technical comfort level?
- Any existing systems or social logins to integrate with?
- What security/compliance requirements do you have?
📝 Outcome: Detailed auth requirements brief ready for implementation"
検証: /sc:brainstorm "web app"ユーザー、機能、テクノロジーについて質問する必要があります。
**��スト:**漠然としたリクエストは、推測ではなく発見のための質問を引き起こす必要があります。
**チェック:**モードは、同じ会話内のフォローアップの質問でも維持される必要があります。
最適な組み合わせ:
--brainstorm「明確な」要件であっても強制的に検出するために使用します目的: 学習の最適化と透明な意思決定のための推論プロセスを公開します。
自動アクティベーショントリガー:
--introspect行動の変化:
経験例:
Standard Approach: "I'll analyze this code structure and suggest improvements..."
Introspective Approach:
"🧠 Meta-Analysis: Why did I choose structural analysis over functional flow?
🎯 Decision Logic: Saw class hierarchy → assumed OOP pattern dominance
🔄 Alternative Considered: Data flow analysis might reveal hidden dependencies
📊 Evidence Check: File imports suggest functional composition, not OOP
💡 Learning: Need to analyze imports before choosing analysis strategy
⚡ Correction: Switching to functional flow analysis approach"
最適な組み合わせ:
--introspect学習セッションやワークフローのデバッグに使用します目的: 複数ステップの操作のためのセッション永続性を備えた階層的なタスク構成。
自動アクティベーショントリガー:
--task-manage、--delegate行動の変化:
経験例:
Standard Approach: "I'll implement user authentication..." → Direct implementation
Task Management Approach:
"📋 Multi-Phase Implementation Plan:
🎯 Phase 1: Security Requirements Analysis (Session 1)
🎯 Phase 2: API Design & Documentation (Session 2)
🎯 Phase 3: Implementation & Testing (Session 3-4)
🎯 Phase 4: Integration & Validation (Session 5)
💾 Session persistence: Resume context automatically
✓ Quality gates: Validation before each phase transition"
最適な組み合わせ:
目的: インテリジェントなツールルーティングと並列調整を通じてタスクの実行を最適化します。
自動アクティベーショントリガー:
行動の変化:
経験例:
Standard Approach: Sequential file-by-file analysis and editing
Orchestration Approach:
"🎯 Multi-Tool Coordination Strategy:
🔍 Phase 1: Serena (semantic analysis) + Sequential (architecture review)
⚡ Phase 2: Morphllm (pattern edits) + Magic (UI components)
🧪 Phase 3: Playwright (testing) + Context7 (documentation patterns)
🔄 Parallel execution: 3 tools working simultaneously
\"
最適な組み合わせ:
目的: 情報の品質を維持しながら、シンボル システムを通じて推定 30 ~ 50% のトークン削減を実現します。
自動アクティベーショントリガー:
--uc、--ultracompressed行動の変化:
経験例:
Standard Approach: "The authentication system implementation shows a security vulnerability in the user validation function that needs immediate attention..."
Token Efficient Approach:
"🛡️ Security Alert:
auth.js:45 → user val() → critical vuln
📊 Impact: ❌ token bypass possible
⚡ Action: fix validation + audit ∵ high sev
🔧 Est: 2h impl + 1h test"
最適な組み合わせ:
--ucコンテキストのプレッシャーや効率が優先される場合に使用します目的: 簡単な開発タスクに対して明確でプロフェッショナルなコミュニケーションを提供します。
自動アクティベーショントリガー:
行動の変化:
経験例:
Standard Approach: Consistent, professional baseline for all tasks
"I'll implement the login function with proper error handling:
1. Validate user input (email format, password requirements)
2. Authenticate against database with secure hashing
3. Generate JWT token with appropriate expiration
4. Return success response with user data
The implementation will follow security best practices and include comprehensive error handling."
最適な組み合わせ:
マルチモードワークフロー:
# Discovery → Planning → Implementation
/sc:brainstorm "microservices architecture" --task-manage
# → Brainstorming: requirement discovery
# → Task Management: multi-phase coordination
# Analysis with transparency and efficiency
/sc:analyze legacy-system/ --introspect --uc
# → Introspection: transparent reasoning
# → Token Efficiency: compressed output
特定の動作を強制する:
--brainstorm: あらゆるタスクで共同発見を強制--introspect: あらゆるモードに推論の透明性を追加--task-manage: 階層的な調整を可能にする--orchestrate: ツール選択と並列実行を最適化--uc: 効率化のために通信を圧縮するオーバーライドの例:
# Force brainstorming on "clear" requirements
/sc:implement "user login" --brainstorm
# Add reasoning transparency to debugging
# 認証問題を透明な推理でデバッグ
# Enable task management for simple operations
# システマチックなタスク管理でスタイルファイルを更新
モードがアクティブになると:
優先ルール:
新規プロジェクト開発:
# Phase 1: Discovery (Brainstorming Mode auto-activates)
"I want to build a productivity app"
→ 🤔 Socratic questions about users, features, platform choice
→ 📝 Structured requirements brief
# Phase 2: Planning (Task Management Mode auto-activates)
/sc:implement "core productivity features"
→ 📋 Multi-phase breakdown with dependencies
→ 🎯 Phase coordination with quality gates
# Phase 3: Implementation (Orchestration Mode coordinates tools)
/sc:implement "frontend and backend systems"
→ 🎯 Magic (UI) + Context7 (patterns) + Sequential (architecture)
→ ⚡ Parallel execution optimization
複雑な問題のデバッグ:
# Problem analysis (Introspection Mode auto-activates)
"Users getting intermittent auth failures"
→ 🤔 Transparent reasoning about potential causes
→ 🎯 Hypothesis formation and evidence gathering
→ 💡 Pattern recognition across similar issues
# Systematic resolution (Task Management coordinates)
# 認証システムを包括的に修正
→ 📋 Phase 1: Root cause analysis
→ 📋 Phase 2: Solution implementation
→ 📋 Phase 3: Testing and validation
非常に複雑なシナリオ:
# Large refactoring with multiple constraints
/sc:improve legacy-system/ --introspect --uc --orchestrate
→ 🔍 Transparent reasoning (Introspection)
→ ⚡ Compressed communication (Token Efficiency)
→ 🎯 Optimal tool coordination (Orchestration)
→ 📋 Systematic phases (Task Management auto-activates)
| トリガータイプ | 入力例 | モードが有効 | 主要な動作 |
|---|---|---|---|
| 漠然とした要求 | 「アプリを作りたい」 | 🧠 ブレインストーミング | ソクラテス式の発見的質問 |
| 複雑なスコープ | >3 つのファイルまたは >2 つのディレクトリ | 📋 タスク管理 | 位相調整 |
| マルチツールの必要性 | 分析 + 実装 | 🎯 オーケストレーション | ツールの最適化 |
| エラー回復 | 「期待通りに動作していません」 | 🔍 内省 | 透明な推論 |
| リソースの圧力 | 高コンテキスト使用 | ⚡ トークン効率 | シンボル圧縮 |
| 簡単なタスク | 「この機能を修正する」 | 🎨 標準 | 明確で直接的なアプローチ |
# Force specific mode behaviors
/sc:command --brainstorm # Collaborative discovery
/sc:command --introspect # Reasoning transparency
/sc:command --task-manage # Hierarchical coordination
/sc:command --orchestrate # Tool optimization
/sc:command --uc # Token compression
# Combine multiple modes
/sc:command --introspect --uc # Transparent + efficient
/sc:command --task-manage --orchestrate # Coordinated + optimized
トラブルシューティングのヘルプについては、以下を参照してください。
--brainstorm、、--introspect``--uc--brainstormまたはのような明示的なフラグを使用する--task-manageブレインストーミングモードの問題:
# Problem: Mode gives solutions instead of asking questions
# Quick Fix: Check request clarity and use explicit flag
/sc:brainstorm "web app" --brainstorm # Force discovery mode
"I have a vague idea about..." # Use uncertainty language
"Maybe we could build..." # Trigger exploration
タスク管理モードの問題:
# Problem: Simple tasks getting complex coordination
# Quick Fix: Reduce scope or use simpler commands
/sc:implement "function" --no-task-manage # Disable coordination
/sc:troubleshoot bug.js # Use basic commands
# Check if task really is complex (>3 files, >2 directories)
トークン効率モードの問題:
# Problem: Output too compressed or unclear
# Quick Fix: Disable compression for clarity
/sc:command --no-uc # Disable compression
/sc:command --verbose # Force detailed output
# Use when clarity is more important than efficiency
イントロスペクションモードの問題:
# Problem: Too much meta-commentary, not enough action
# Quick Fix: Disable introspection for direct work
/sc:command --no-introspect # Direct execution
# Use introspection only for learning and debugging
オーケストレーション モードの問題:
# Problem: Tool coordination causing confusion
# Quick Fix: Simplify tool usage
/sc:command --no-mcp # Native tools only
/sc:command --simple # Basic execution
# Check if task complexity justifies orchestration
| モードエラー | 意味 | クイックフィックス |
|---|---|---|
| B001 | ブレインストーミングが起動できませんでした | --brainstorm明示的なフラグを使用する |
| T001 | タスク管理のオーバーヘッド | --no-task-manage簡単なタスクに使用する |
| U001 | トークン効率が強すぎる | 使用--verboseまたは--no-uc |
| I001 | イントロスペクションモードが停止しました | --no-introspect直接行動に使う |
| O001 | オーケストレーション調整に失敗 | 使用--no-mcpまたは--simple |
| M001 | モードの競合が検出されました | フラグの優先順位のルールを確認する |
| M002 | モード切り替えループ | 状態をリセットするにはセッションを再起動してください |
| M003 | モードが認識されません | SuperClaudeを更新するかスペルをチェックする |
レベル 1: クイックフィックス (< 2 分)
レベル2: 詳細なヘルプ(5~15分)
# Mode-specific diagnostics
/sc:help modes # List all available modes
/sc:reflect --type mode-status # Check current mode state
# Review request complexity and triggers
レベル3: 専門家によるサポート(30分以上)
# Deep mode analysis
SuperClaude install --diagnose
# Check mode activation patterns
# Review behavioral triggers and thresholds
レベル4: コミュニティサポート
モード修正を適用した後、次のようにテストします。
--brainstorm、、--introspect``--ucQ: どのモードがアクティブになっているかはどうすればわかりますか? A: 通信パターンで次のインジケーターを確認してください。
Q: 特定のモードを強制できますか? A: はい、手動フラグを使用して自動検出をオーバーライドします。
/sc:command --brainstorm # Force discovery
/sc:command --introspect # Add transparency
/sc:command --task-manage # Enable coordination
/sc:command --uc # Compress output
Q: モードは実行に影響しますか? A: モードは調整を通じてツールの使用を最適化します。
Q: モードは連携して動作しますか? A: はい、モードは互いに補完し合うように設計されています。
SuperClaude の 5 つの行動モードは、ユーザーのニーズに自動的に適合するインテリジェントな適応システムを作成します。
重要な洞察:モードについて考える必要はありません。モードは透過的に動作し、開発エクスペリエンスを向上させます。達成したいことを説明するだけで、SuperClaudeはニーズに合わせてアプローチを自動的に調整します。
学習の進捗:
🌱 エッセンシャル(第1週)
🌿中級(第2~3週)
🌲 上級(2ヶ月目以降)
🔧 エキスパート
モード固有のガイド: