SuperClaude コマンドマニュアル - AI開発アシスタント完全ガイド

💡 SuperClaude フレームワークへようこそ！

このマニュアルは、25のコマンド、15の専門エージェント + ビジネスエキスパートパネル、7つの動作モード、8つのMCPサーバーをすべてカバーし、詳細な使用方法と豊富な実践例を含んでいます。各機能は、開発作業をより効率的でインテリジェントにするために慎重に設計されています。

🎯 クイックスタート

SuperClaude のインストール

# 推奨方法（pipx）
pipx install SuperClaude && pipx upgrade SuperClaude && SuperClaude install

# または npm を使用
npm install -g @bifrost_inc/superclaude && superclaude install

# または pip を使用
pip install SuperClaude && pip upgrade SuperClaude && SuperClaude install

初回使用

インストール後、Claude Code で以下を入力してください：

/sc:help

利用可能なすべてのコマンドのリストが表示されます。さあ、探索を始めましょう！

📋 コアコマンド

📋 コマンド概要

SuperClaudeは提供します 25 個の強力なコマンドで、開発のあらゆる側面をカバーします：

/sc:help - 全コマンドの表示
/sc:brainstorm - インタラクティブな要件探索
/sc:analyze - コード品質分析
/sc:research - 深度ネット調査
/sc:implement - 機能実装
/sc:improve - コード改善
/sc:test - テスト実行
/sc:build - プロジェクトビルド
/sc:git - Git 操作
/sc:design - システム設計
/sc:document - ドキュメント生成
/sc:cleanup - コードクリーンアップ
/sc:save - セッション保存
/sc:load - セッション読み込み
/sc:troubleshoot - トラブルシューティング
/sc:explain - コード説明
/sc:business-panel - ビジネスエキスパートパネル
/sc:task - 複雑なタスク実行
/sc:workflow - ワークフロー生成
/sc:estimate - 開発見積もり
/sc:spawn - タスクオーケストレーション
/sc:spec-panel - 仕様レビュー
/sc:reflect - タスクリフレクション
/sc:index - プロジェクトインデックス
/sc:select-tool - ツール選択

💻 開発ワークフロー

要件から展開までの全サイクル開発を支援する一般的な開発ワークフローコマンド：

/sc:brainstorm - インタラクティブな要件探索

ソクラテス式対話により、曖昧なアイデアを明確な技術仕様に変換

構文

/sc:brainstorm [--strategy systematic|agile|enterprise] [--depth shallow|normal|deep] [--parallel] [トピック/アイデア]

例 1: 体系的な製品探索

/sc:brainstorm --strategy systematic --depth deep "AI-driven project management tool"

✨ 効果:

マルチエキスパート分析(アーキテクト、アナリスト、プロジェクトマネージャー)
Sequential MCP を使用した構造化探索フレームワーク提供
完全な要件ドキュメントの生成

💡 実用シナリオ

SaaS製品コンセプトの探索

/sc:brainstorm --strategy systematic --depth shallow --parallel "Team collaboration project management tool with AI assistant"

背景:

製品コンセプトシナリオ：

AIアシスタント統合を備えたチームコラボレーションプロジェクト管理ツールについて漠然としたアイデアがある
コアバリュープロポジションとターゲットユーザーグループについて不確実
具体的なAI統合シナリオが不明確
製品のポジショニングと機能範囲を明確にするために体系的な探索が必要

結果:

要件の探索が完了し、ユーザーストーリー、コア機能、技術スタックが特定されました。設計フェーズの準備が整いました。

チームコラボレーションツールの開発

/sc:brainstorm --strategy agile --depth normal "Team collaboration project management tool with AI assistant"

背景:

開発計画シナリオ：

チームコラボレーションツールを開発したい
真の価値を提供するコア機能について不確実
競争市場での差別化の優位性を特定する必要がある

結果:

体系的な対話を通じて、コア機能と価値提案が明確になりました。PRD作成の準備が整いました。

機能優先順位の評価

/sc:brainstorm --strategy enterprise --depth deep "Feature prioritization: User feedback system vs Advanced analytics vs Third-party integrations"

背景:

優先順位付けの課題：

製品バックログにさまざまなステークホルダーからの20以上の機能リクエストが蓄積
限られた開発リソース（小規模チーム）
影響を最大化するためのデータ駆動の優先順位付けが必要
クイックウィンと長期戦略的機能のバランスを取る必要がある

結果:

機能の優先順位付けが完了し、データドリブンな推奨事項と実装ロードマップが提供されました。

💡 ベストプラクティス:

アイデアが曖昧であるほど、このコマンドの使用に適しています
Claude に対話を導かせ、提起された質問に答えましょう
生成された要件ドキュメントを後続の開発に活用するため保存しましょう

/sc:implement - 機能実装

インテリジェントエキスパート調整と MCP 統合を使用した機能とコードの実装

構文

/sc:implement [--type component|api|service|feature] [--framework react|vue|express] [--safe] [--with-tests] [機能説明]

例 1.1: クイックコンポーネント

/sc:implement --type component --framework react "user login form"

✨ 効果:

Reactコンポーネントを生成
HooksとState管理を含む
自動フォーム検証

例 1.2: APIエンドポイント

/sc:implement --type api --framework express --safe "payment processing interface"

✨ 効果:

Express REST API
エラーハンドリングと入力検証を含む
セキュリティモードで一般的な脆弱性を防止

例 1.3: 完全な機能モジュール

/sc:implement --type feature --framework react --with-tests --magic --c7 "real-time chat system"

✨ 効果:

完全なフロントエンドとバックエンドの実装
ユニットテストと統合テストを含む
Magicで美しいUIを生成
Context7がベストプラクティスを提供
WebSocket接続を自動セットアップ

例 1.4: マイクロサービス実装

/sc:implement --type service --framework express --with-tests --seq --think-hard "order processing microservice"

✨ 効果:

独立したマイクロサービスアーキテクチャ
メッセージキュー統合を含む
Sequentialによるビジネスロジックの深層分析
Docker設定を自動生成

💡 実用シナリオ

ファイルアップロード機能

/sc:implement --type feature --framework react --safe --with-tests "Large file upload with chunking and resume"

背景:

実装要件：

チャンキング機構を備えた大容量ファイルアップロードのサポートを実装する必要がある
最大2GBのファイルをサポートする必要がある
リアルタイム更新による進捗追跡が必要
ネットワーク中断を処理する再開機能が必要
ユーザーに正確なアップロード進捗を表示する必要がある

結果:

ファイルアップロード機能が実装され、検証と進捗追跡が含まれました。

ユーザー認証システム

/sc:implement --type api --framework express --safe --with-tests "User authentication system (registration, login, JWT)"

背景:

システム要件：

完全なユーザー認証システムを実装する必要がある
メール検証付きユーザー登録を含める必要がある
JWTトークン管理による安全なログインが必要
技術スタック：Express.js + JWT + パスワードハッシング用bcrypt
暗号化されたパスワードを持つユーザーモデルを設計する必要がある
適切な検証を備えた登録とログインAPIエンドポイントが必要
保護されたルートのための認証ミドルウェアが必要

結果:

認証システムが実装され、安全なトークン処理とセッション管理が含まれました。

💡 ベストプラクティス:

説明は明確かつ具体的に、主要な要件を含めましょう
本番コードには常に --safe を使用しましょう
--with-tests を使用してテストカバレッジを確保しましょう

/sc:design - システム設計

システムアーキテクチャ、APIインターフェース、コンポーネント構造を設計し、スケーラブルな技術ソリューションを提供

構文

/sc:design [--type architecture|api|component|database] [--format diagram|spec|code] "<システム/コンポーネント>"

パラメータ

--type: : 設計タイプ
- architecture
- api
- component
- database
--format: : 出力形式
- diagram
- spec
- code

例 9.1: API設計

/sc:design --type api --format spec "User Authentication API"

✨ 効果:

OpenAPI仕様
エンドポイント定義
セキュリティスキーム

例 9.2: データベース設計

/sc:design --type database --format code "E-commerce Order System"

✨ 効果:

データベーススキーマ
ER図
SQLスクリプト

例 9.3: マイクロサービスアーキテクチャ設計

/sc:design --type architecture --format diagram --ultrathink --c7 ""

✨ 効果:

完全なアーキテクチャ図
サービス通信設計
データフロー図
技術スタック選定
スケーラビリティ計画

💡 実用シナリオ

リアルタイムコラボレーションAPI設計

/sc:design --type api --format spec "Real-time Document Collaboration API"

背景:

設計要件：

リアルタイムの協働ドキュメント編集機能を設計する必要がある
マルチユーザー編集のための適切なAPI構造が必要
データ同期と競合解決を処理する必要がある
すべての接続クライアント間でリアルタイム更新が必要

結果:

API設計が完了し、実装準備が整った仕様とドキュメントが提供されました。

決済システムアーキテクチャのリファクタリング

/sc:design --type architecture --format diagram "Payment System Refactoring"

背景:

リファクタリングの課題：

Eコマースシステムの決済コードが乱雑でコンポーネント間の結合度が高い
新しい決済プロバイダーの追加や既存フローの変更が困難
リファクタリング前にアーキテクチャを再設計する必要がある
関心の明確な分離とテスト可能性を確保する必要がある

結果:

システムアーキテクチャが定義され、コンポーネント間の相互作用とデプロイメント戦略が文書化されました。

💡 ベストプラクティス:

実装前に設計を行い、手戻りを防ぐ
システムのスケーラビリティとメンテナンス性を考慮
--format diagramを使用して可視化ドキュメントを生成
設計レビュー後に実装フェーズへ移行

💾 セッション管理

開発セッションを保存および読み込み、セッション間でコンテキストを永続化します：

/sc:save - セッション保存

Serena MCPを使用してセッションコンテキストと発見を保存

構文

/sc:save [--type session|learnings|context|all] [--summarize] [--checkpoint]

パラメータ

--type: : 保存タイプ
- session
- learnings
- context
- all
--summarize: : 要約を生成
--checkpoint: : 復元可能なチェックポイントを作成

例: 総合チェックポイント

/sc:save --type session

✨ 効果:

完全なセッション保存と復元チェックポイント
すべての学習、コンテキスト、進捗状況を含む
セッション復元に使用可能

例: 学習ポイントの保存

/sc:save --type all --checkpoint --summarize

✨ 効果:

現在のセッションから学習ポイントと技術的発見を保存
タグを使用して分類し、後で簡単に検索
プロジェクト知識ベースとベストプラクティスを構築

💡 実用シナリオ

デバッグセッションの進捗保存

/sc:save "payment-bug-analysis"

背景:

セッションシナリオ：

複雑な決済統合バグに取り組んでいる
作業日の終わりが近づいている
保存する必要がある重要なデバッグの進捗がある
コンテキストを失わずに明日調査を継続したい

結果:

デバッグセッションが保存され、進捗状況と調査結果が文書化されて将来の継続に備えました。

プロジェクトアーキテクチャの学習ドキュメント化

/sc:save "project-architecture-overview"

背景:

知識キャプチャシナリオ：

チームとの詳細なアーキテクチャディスカッションが完了
重要な技術スタックの決定を行った
将来の参照のためにアーキテクチャの根拠を保存する必要がある
チームのオンボーディングのために知識をアクセス可能にしたい

結果:

プロジェクトの学習内容が永続ストレージに保存され、知識が保持されました。

パフォーマンス最適化の洞察を保存

/sc:save "react-performance-optimization"

背景:

最適化完了：

Reactコンポーネントのレンダリングパフォーマンスの最適化が完了
不必要な再レンダリングに関する重要な洞察を発見
React.memoとuseCallbackの最適化を適用
大幅なパフォーマンス改善を達成
同様のシナリオのためにソリューションをドキュメント化したい

結果:

システムアーキテクチャが定義され、コンポーネント間の相互作用が文書化されました。

💡 ベストプラクティス:

重要なブレークスルー後すぐに保存
長時間のセッションでは30分ごとにチェックポイントを作成
セッション終了前に--summarizeを使用

/sc:load - セッション読み込み

Serena MCPを使用してプロジェクトコンテキストと履歴セッションを読み込み

構文

/sc:load [--type session|learnings|context|all] [--checkpoint id]

パラメータ

--type: : 読み込みタイプ
- session
- learnings
- context
- all
--checkpoint: : 読み込むチェックポイントIDを指定
--analyze: : 読み込み時にプロジェクト構造を自動分析
--refresh: : コンテキストをリフレッシュ

例: チェックポイントから復元

/sc:load --type project --analyze ""

✨ 効果:

特定のチェックポイントのセッション状態を復元
進捗状況とコンテキストを再読み込み
中断された作業を継続

例: 最近のセッションを読み込み

/sc:load --type checkpoint --refresh "session_20250118_1430"

✨ 効果:

最近の作業セッションを素早く読み込み
以前のコードコンテキストと思考を復元
以前の開発タスクをシームレスに継続

💡 実用シナリオ

昨日のデバッグセッションの継続

/sc:load "payment-bug-analysis"

背景:

作業再開シナリオ：

新しい作業日を開始
昨日は認証問題をデバッグしていた
コンテキストを迅速に復元し、中断したところから継続する必要がある
問題を再分析せずにシームレスなワークフロー継続が必要

結果:

セッションコンテキストが正常に復元され、完全なプロジェクト状態が利用可能になりました。

プロジェクトメモリの読み込み

/sc:load "ecommerce-platform"

背景:

プロジェクトアクティベーションシナリオ：

別のコードベースで作業した後、異なるプロジェクトに切り替え
プロジェクト固有のコンテキスト、アーキテクチャ、規約を思い出す必要がある
ドキュメントを手動で確認せずに迅速な再アクティベーションが必要

結果:

プロジェクトコンテキストがアクティベートされ、アーキテクチャと開発パターンがロードされました。

学習コンテキストの復元

/sc:load "nextjs-learning"

背景:

学習再開：

先週Next.js App Routerアーキテクチャを学習していた
メモを取り、例で練習した
中断したところから学習を継続する必要がある
主要な概念と次の学習ステップを思い出したい

結果:

システムアーキテクチャが定義され、コンポーネント間の相互作用が文書化されました。

💡 ベストプラクティス:

新しいセッションを開始する際はすぐにプロジェクトコンテキストを読み込む
プロジェクトを切り替える前に現在のセッションを保存してから新しいプロジェクトを読み込む
定期的に --refresh を使用して古いコンテキストをリフレッシュ
--analyze を使用してプロジェクト構造を自動分析

🎯 高度な機能

複雑な開発シナリオを解決するための強力な高度なコマンド：

/sc:task - 複雑なタスク実行

インテリジェントなワークフロー管理と委任による複雑なタスク実行

構文

/sc:task [--parallel] [--validate] [タスク説明] [--delegate auto|files|folders]

例: 大規模リファクタリング

/sc:task --delegate auto --validate "refactor authentication system"

✨ 効果:

自動タスク分解と委任
並列専門家協力
実行前のリスク評価

💡 実用シナリオ

エンドツーエンド機能実装

/sc:task --parallel --validate "Integrate Stripe payment (requirements → design → implementation → testing → deployment)"

背景:

要件定義からデプロイメントまで、決済統合機能を完成させる必要があります。

結果:

機能実装が完全なワークフローを通じてオーケストレートされ、すべてのフェーズが正常に完了しました。

問題診断と修正

/sc:task --parallel --validate "Production environment memory leak"

背景:

本番環境でメモリリークが発生しており、完全な診断と修正ワークフローが必要です。

結果:

問題が体系的なトラブルシューティングワークフローを通じて診断され、解決されました。

プロジェクト初期化

/sc:task --parallel --validate "Next.js + TypeScript + Tailwind project"

背景:

新しいNext.jsプロジェクトを開始し、完全なプロジェクトセットアップが必要です。

結果:

システムアーキテクチャが定義され、コンポーネント間の相互作用が文書化されました。

/sc:workflow - ワークフロー生成

PRDと機能要件から構造化された実装ワークフローを生成

構文

/sc:workflow [--strategy systematic|agile|enterprise] [--depth shallow|normal|deep] [--parallel] [--delegate auto] ""

例 7.1: アジャイルワークフロー

/sc:workflow --strategy agile "User Management System"

✨ 効果:

アジャイル手法
ユーザーストーリーの分解
イテレーション計画

例 7.2: 体系的ワークフロー

/sc:workflow --strategy systematic --depth deep "@requirements.prd"

✨ 効果:

体系的手法
詳細なタスク分解
依存関係グラフ

例 7.3: エンタープライズ並列ワークフロー

/sc:workflow --strategy enterprise --depth deep --parallel --delegate auto "@product-spec.md"

✨ 効果:

エンタープライズレベルプロセス
並列タスク実行
自動タスク割り当て
ガントチャート生成
チームコラボレーション計画

💡 実用シナリオ

機能開発標準プロセス

/sc:workflow --strategy systematic --depth normal "New Feature Development Standard Process"

背景:

チームに新メンバーが多く、機能開発プロセスを標準化する必要があります。

結果:

開発ワークフローが構造化され、明確なフェーズとチームコラボレーションのガイドラインが定義されました。

バグ修正プロセス

/sc:workflow --strategy agile --depth shallow "Bug Fix Standard Process"

背景:

バグ修正プロセスが不規則で、しばしばステップが欠落して再作業につながっています。

結果:

バグ修正ワークフローが標準化され、調査、解決、検証のステップが文書化されました。

エンタープライズ並列ワークフロー

/sc:workflow --strategy enterprise --depth deep --parallel --delegate auto "@product-spec.md"

背景:

大規模プロジェクトでマルチチーム協力が必要であり、エンタープライズワークフロー計画が必要です。

結果:

改善が適用され、測定可能なパフォーマンス向上が達成されました。

💡 ベストプラクティス:

PRDに明確な要件定義が含まれていることを確認
--estimateを使用してリソース計画を立てる
定期的にワークフローを更新して進捗を追跡
チーム規模を考慮して時間見積もりを調整

/sc:spawn - タスクオーケストレーション

メタシステムタスクオーケストレーション、大規模で複雑なタスクのインテリジェントな分解と委任

構文

/sc:spawn "タスク説明" [--strategy sequential|parallel|adaptive] [--breakdown auto] [--delegate agents]

例: 大規模プロジェクトのオーケストレーション

/sc:spawn --strategy adaptive --breakdown auto --delegate agents "Build complete e-commerce admin system"

✨ 効果:

タスク分解: ユーザー管理、商品管理、注文システム、決済統合、データ分析
エージェント割り当て: backend-architect(アーキテクチャ)、security-engineer(決済セキュリティ)、frontend-architect(管理インターフェース)
実行戦略: アーキテクチャ設計→並列開発→統合テスト
インテリジェントスケジューリングと進捗追跡

💡 実用シナリオ

複数機能の並列開発

/sc:spawn --strategy adaptive --breakdown auto "user avatar upload, comment system, search optimization"

背景:

スプリントで3つの独立した機能を同時に開発する必要があり、並列処理により開発を加速したい。

結果:

タスクオーケストレーションが完了し、すべての並列開発ストリームが正常に実行されました。

マルチ環境デプロイメント

/sc:spawn --strategy parallel --breakdown auto "Deploy to test, staging, and production environments"

背景:

テスト、ステージング、本番環境に同時にデプロイする必要があります。

結果:

すべての対象環境で並列デプロイメントが正常に完了しました。

複雑な問題の分割統治

/sc:spawn --strategy adaptive --breakdown auto "Analyze slow API, frontend lag, and database query performance"

背景:

システムパフォーマンスの問題は複雑であり、複数のサブ問題に分解して並列に分析する必要があります。

結果:

システムアーキテクチャが定義され、コンポーネント間の相互作用が文書化されました。

💡 ベストプラクティス:

大規模でマルチモジュールのプロジェクトに適用
システムにエージェントと戦略をインテリジェントに割り当てさせる
サブタスクの進捗を定期的に確認
複雑な依存関係にはsequential戦略を使用

/sc:reflect - タスクリフレクション

Serena MCP分析機能を使用したタスクのリフレクションと検証、品質評価

構文

/sc:reflect [--analyze outcomes|process|quality] [--improve] [--task TasksID]

例: 実装タスクのリフレクション

/sc:reflect --task --analyze quality --improve "implement user authentication"

✨ 効果:

実装品質の分析（コードカバレッジ、セキュリティ）
潜在的な問題の特定（エラー処理不足、パフォーマンス上の懸念）
改善提案の生成
安全に改善可能な部分の自動適用
人間のレビューが必要な問題のマーク

💡 実用シナリオ

タスク完了の検証

/sc:reflect --analyze outcomes --improve

背景:

ユーザー認証機能の開発が完了し、すべての要件が満たされているかを検証する必要がある：

機能開発が完了
要件の充足度を確認したい
潜在的な問題や改善点を特定したい

結果:

タスク完了が検証され、要件カバレッジが確認されました。

コード品質のリフレクション

/sc:reflect --analyze process

背景:

リファクタリングが完了し、コード品質が基準を満たしているかを評価する必要がある：

リファクタリング作業が完了
コード品質の改善度を測定したい
残っている問題があれば特定したい

結果:

コード品質検証が完了し、改善領域が特定されました。

プロジェクトマイルストーンレビュー

/sc:reflect --analyze quality --improve

背景:

スプリントが終了し、今回のイテレーションの成果と問題をレビューする必要がある：

スプリントが完了
達成度と課題を評価したい
次回スプリントのための改善点を特定したい

結果:

スプリントレビューが完了し、成果が文書化され、改善機会が特定されました。

💡 ベストプラクティス:

重要なタスク完了後に迅速にリフレクション
リフレクション結果を使用して将来の作業を最適化
定期的なリフレクションで開発品質を向上
リフレクションで発見された問題を速やかに修正

/sc:select-tool - ツール選択

複雑度スコアリングと操作分析に基づくMCPツールのインテリジェント選択

構文

/sc:select-tool "操作説明" [--suggest] [--compare] [--explain]

例: ツール選択の提案

/sc:select-tool --suggest --explain "Need to rename function names in 100 files"

✨ 効果:

操作の複雑度を分析: 中程度（一括編集）
推奨ツール: Morphllm MCP（一括パターン編集）
代替案: Serena MCP（シンボルリネーム）
説明: Morphllmはパターン化された一括置換により適している
推定効率向上: 80%

💡 実用シナリオ

複雑なタスクのツール選択

/sc:select-tool --suggest --explain "Implement user behavior data analysis and visualization reports"

背景:

複雑なデータ分析機能を実装する必要があるが、どのMCPツールが最も適切か不明です。

結果:

タスク複雑性分析に基づいて最適なツールの組み合わせが推奨されました。

パフォーマンス最適化のツール選択

/sc:select-tool --suggest --explain "API performance optimization"

背景:

APIレスポンスが遅いため、パフォーマンス分析と最適化に適切なツールを選択する必要があります。

結果:

体系的な最適化のための適切なMCPサーバーを使用したツールワークフローが設計されました。

Learning New Framework Tool Selection

/sc:select-tool --suggest --explain "Learn Next.js 14 new features"

背景:

Team needs to learn Next.js 14, need to select the best learning path and tools.

結果:

ビルドが正常に完了し、最適化されたプロダクションアーティファクトが生成されました。

💡 ベストプラクティス:

どのツールを使用すべきか不明な場合はこのコマンドを参照
--compare を使用して異なるソリューションの長所短所を理解
プロジェクト規模に応じて適切なツールを選択
ツール選択のロジックを学んで効率を向上

その他のコアコマンド

より強力な機能コマンド

/sc:help - 全コマンドの表示

利用可能なすべての SuperClaude コマンドとその機能説明を素早く確認

構文

/sc:help

/sc:analyze - コード品質分析

コード品質、セキュリティ、パフォーマンス、アーキテクチャの包括的な分析

構文

/sc:analyze [--focus quality|security|performance|architecture] [--depth quick|deep] [--format text|json|report] [--all-mcp] [--validate] [対象]

パラメータ

--focus: : 分析の焦点
- quality
- security
- performance
- architecture
--depth: : 分析の深さ
- quick
- deep
--format: : 出力形式
- text
- json
- report
--all-mcp: : すべてのMCPサーバーを有効にして包括的な分析を実行
--validate: : 分析結果を検証し、改善計画を生成

例 2.1: クイックセキュリティスキャン

/sc:analyze --focus security --depth quick "src/auth"

✨ 効果:

セキュリティ脆弱性の迅速な特定
5〜10秒でスキャン完了
認証ロジックに焦点

例 2.2: パフォーマンス分析

/sc:analyze --focus performance --depth normal "api/"

✨ 効果:

標準的なパフォーマンス分析
パフォーマンスボトルネックの特定
最適化の推奨事項を提供

例 2.3: 深層アーキテクチャ評価

/sc:analyze --focus architecture --depth deep --format report --think-hard --seq "."

✨ 効果:

包括的なアーキテクチャ分析
詳細レポートを生成
デザインパターンの使用を評価
アーキテクチャ上の負債を特定
Sequentialによるリファクタリング提案を提供

例 2.4: 包括的品質レビュー

/sc:analyze --focus quality --depth deep --format json --all-mcp --validate "src/"

✨ 効果:

包括的なコード品質レビュー
CI/CD統合用のJSON形式
カバレッジと複雑性分析
改善計画を自動生成

💡 実用シナリオ

新機能のパフォーマンス分析

/sc:analyze --focus performance --depth deep --format report "src/search"

背景:

パフォーマンス調査：

新しく開発した検索機能のレスポンスタイムが遅い
ユーザーが検索ごとに2〜3秒の遅延を経験している
パフォーマンスのボトルネックを分析する必要がある
最適化の機会を迅速に特定する必要がある

結果:

パフォーマンス分析が完了し、ボトルネックが特定され、最適化の推奨事項が提供されました。

レガシーコードの品質評価

/sc:analyze --focus quality --depth deep --format json "src/legacy"

背景:

技術的負債の評価：

レガシーコードベースの包括的な品質分析を実施する必要がある
前任チームから引き継いだコードベースで品質状況が不明確
リファクタリング作業を計画する前に技術的負債を評価する必要がある
影響度に基づいて改善作業の優先順位を付ける必要がある

結果:

コード品質評価が完了し、実行可能な改善提案が提供されました。

💡 ベストプラクティス:

初回分析では --depth quick を使用して問題領域を迅速に特定
重要なモジュールには --depth deep を使用して詳細分析
コアモジュールに対して定期的に --focus security のセキュリティ監査を実施
--format report を使用してチームで共有可能な分析レポートを生成
--all-mcp と組み合わせて複数のMCPサーバーを使用した包括的な分析を実行

/sc:research - 深度ネット調査

適応的計画とインテリジェント検索を使用した深度ネット調査

構文

/sc:research [--depth quick|standard|deep|exhaustive] [--strategy planning_only|intent_planning|unified] [--domains "domain1,domain2"] "[queries]"

例 8.1: クイック調査

/sc:research --depth quick "latest frontend framework comparison"

✨ 効果:

クイック概要
重要ポイントのサマリー
5〜10分で完了

例 8.2: 標準調査

/sc:research --depth standard --strategy planning "microservices architecture best practices"

✨ 効果:

標準的な深さの調査
マルチソース情報集約
実用的な推奨事項

例 8.3: 包括的技術調査

/sc:research --depth exhaustive --strategy unified --serena "zero trust security architecture implementation guide"

✨ 効果:

最も包括的な調査
完全な情報収集
比較分析表
Serenaが調査結果を保存
トレンドと予測分析

💡 実用シナリオ

技術スタック調査

/sc:research --strategy unified "React state management comparison 2024"

背景:

技術的決定：

新しいReactプロジェクトのための状態管理ソリューションを選択する必要がある
Redux vs Zustand vs Jotai vs React Contextを評価中
チームには様々な経験レベルがある
長所と短所を含むデータ駆動の決定が必要

結果:

技術オプションが分析され、プロジェクト要件に基づく推奨事項が提供されました。

セキュリティベストプラクティス調査

/sc:research --strategy unified "OAuth 2.0 security best practices and common vulnerabilities"

背景:

セキュリティ監査の準備：

認証システムのセキュリティ監査の準備中
現在のベストプラクティスと標準を理解する必要がある
現在の実装のギャップを特定したい
改善のための推奨事項を提供する必要がある

結果:

リサーチが完了し、セキュリティのベストプラクティスと実装推奨事項が文書化されました。

/sc:improve - コード改善

体系的リファクタリングと品質向上により、既存コードの保守性、パフォーマンス、セキュリティを改善

構文

/sc:improve [--type quality|performance|maintainability] [--safe] [--preview] [--interactive] [--iterations N] "<対象パス>"

パラメータ

--type: : 改善タイプ
- quality
- performance
- maintainability
--safe: : 安全モード、すべての変更はテスト検証が必要
--preview: : プレビューモード、実際のファイル変更は行わない
--interactive: : 各改善を対話的に確認
--iterations: : 反復改善の回数

例 10.1: パフォーマンス最適化

/sc:improve --type performance --safe "src/api/"

✨ 効果:

パフォーマンス最適化
安全モード
ベンチマークテスト

例 10.2: コード品質

/sc:improve --type quality --preview "src/"

✨ 効果:

品質改善プレビュー
実際の変更なし
改善チェックリスト

例 10.3: 包括的リファクタリング

/sc:improve --type maintainability --interactive --iterations 3 --morph ""

✨ 効果:

段階的リファクタリング
3回の反復ラウンド
インタラクティブ確認
Morphllmによるバッチリファクタリング
保守性スコアの向上

💡 実用シナリオ

コード品質の改善

/sc:improve --type quality --safe "src/auth/legacy"

背景:

コード品質の向上：

レガシー認証モジュールに技術的負債が蓄積されている
コードは機能しているが保守とテストが困難
既存の機能を壊さずに改善する必要がある
モダンなベストプラクティスに従いたい

結果:

コード品質の改善が完了し、保守性とテストカバレッジが向上しました。

パフォーマンス最適化

/sc:improve --type performance --safe "src/api/products"

背景:

パフォーマンス改善：

APIレスポンスタイムが平均800ms、目標は<200ms
データベースクエリが非効率
キャッシング層が実装されていない
Reactコンポーネントが不必要に再レンダリングされている

結果:

パフォーマンス最適化が適用され、測定可能な改善が達成されました。

💡 ベストプラクティス:

改善前にテストを実行し、テストカバレッジがあることを確認
大規模な改善は段階的に進め、--iterationsを使用して反復的に改善
本番コードでは必ず --safe モードを使用
--previewを使用して改善効果をプレビューしてから適用
改善後にパフォーマンス指標を比較し、正の向上を確認

/sc:test - テスト実行

テストを実行し、カバレッジ分析と品質レポートを生成

構文

/sc:test [--type unit|integration|e2e|all] [--coverage] [--watch] [--fix] [--parallel] [--concurrency N] [--validate] [対象]

例 3.1: ユニットテスト

/sc:test --type unit --coverage "src/utils"

✨ 効果:

ユニットテストを実行
カバレッジレポートを生成
高速実行

例 3.2: ウォッチモード

/sc:test --type unit --watch "src/"

✨ 効果:

ファイル変更時にテストを自動再実行
即座にフィードバック
TDD開発に適している

例 3.3: E2Eテストスイート

/sc:test --type e2e --fix --play --verbose ""

✨ 効果:

エンドツーエンドテスト
失敗したテストケースを自動修正
Playwrightブラウザ自動化
詳細なログ出力

例 3.4: 完全なテストパイプライン

/sc:test --type all --coverage --parallel --concurrency 4 --validate "."

✨ 効果:

すべてのテストが並列実行
4倍の速度向上
完全なカバレッジ分析
結果検証とレポート作成

💡 実用シナリオ

包括的な機能テスト

/sc:test --type all --coverage --validate "src/auth"

背景:

機能検証：

ユーザー認証機能の実装が完了した
すべての機能が仕様通りに動作することを確認する必要がある
エッジケースとエラーシナリオをテストする必要がある
マージ前に包括的なテストカバレッジが必要

結果:

テストで修正が必要な失敗が特定されました。次に進む前に修正が必要です。

リファクタリング後のリグレッションテスト

/sc:test --type all --coverage --validate "src/payments"

背景:

リファクタリング検証：

決済処理モジュールの大規模なリファクタリングが完了した
内部実装を変更したがAPIは変更されないはず
既存の機能が壊れていないことを確認する必要がある
下位互換性を検証する必要がある

結果:

すべてのテストが合格し、包括的なカバレッジレポートが生成されました。コードレビューの準備が整いました。

/sc:build - プロジェクトビルド

プロジェクトをコンパイル、パッケージ化してデプロイ準備、マルチ環境設定と最適化をサポート

構文

/sc:build [--type dev|prod] [--clean] [--optimize] [--validate] [--parallel]

例 5.1: 開発ビルド

/sc:build --type dev --verbose "frontend/"

✨ 効果:

開発環境ビルド
詳細なログ出力
高速ホットリロード

例 5.2: 本番環境ビルド

/sc:build --type prod --clean "."

✨ 効果:

本番環境最適化
古いビルドをクリーン
圧縮とミニフィケーション

例 5.3: 最適化されたビルドパイプライン

/sc:build --type prod --clean --optimize --validate --parallel "."

✨ 効果:

完全最適化本番環境ビルド
並列ビルドタスク
ビルド結果検証
パフォーマンス分析レポート
ツリーシェイキングとコード分割

例 5.4: マルチ環境ビルド

/sc:build --type all --environments "dev,staging,prod" --dockerize ""

✨ 効果:

複数環境を同時ビルド
Dockerイメージを生成
環境固有の設定
デプロイ準備完了

💡 実用シナリオ

最適化された本番環境ビルド

/sc:build --type prod --optimize --validate --clean

背景:

本番環境デプロイの準備：

v2.0の本番リリースを準備中
ミニフィケーションとツリーシェイキングによる最適化ビルドが必要
すべてのアセットが適切にバンドルされていることを確認する必要がある
本番環境の問題をデバッグするためのソースマップが必要

結果:

ビルドが正常に完了し、最適化されたプロダクションアーティファクトが生成されました。

CI/CD統合ビルド

/sc:build --type prod --optimize --validate --parallel --clean

背景:

継続的インテグレーションのセットアップ：

GitHub Actionsで自動ビルドパイプラインをセットアップ中
環境間で一貫性のある再現可能なビルドが必要
ビルド前にテストと品質チェックを実行する必要がある
デプロイ自動化のためのビルドアーティファクトが必要

結果:

ビルドが正常に完了し、最適化されたプロダクションアーティファクトが生成されました。

💡 ベストプラクティス:

本番ビルド前にテストを実行し、コード品質を確保しましょう
--clean を使用して古いファイル残留による問題を回避しましょう
開発環境では --watch を使用して開発効率を向上させましょう
ビルドサイズレポートをチェックし、大きな依存関係を特定しましょう

/sc:git - Git 操作

インテリジェントコミットメッセージとワークフロー最適化による Git 操作

構文

/sc:git [commit|merge|rebase|pr|flow] [--smart-commit] [--interactive] [--push] [--create-pr] [--squash] [--create] [--title " "] [--auto-description] [parameters]

例 4.1: スマートコミット

/sc:git commit --smart-commit

✨ 効果:

仕様に準拠したコミットメッセージを自動生成
コード変更内容を分析
Conventional Commitsに従う

例 4.2: インタラクティブマージ

/sc:git merge --interactive ""

✨ 効果:

スマート競合解決
ステップバイステップのマージガイダンス
ベストプラクティスの提案を提供

例 4.3: 完全なGitワークフロー

/sc:git flow --smart-commit --push --create-pr ""

✨ 効果:

ブランチを自動作成
スマートコミットメッセージ
プッシュしてPRを作成
変更サマリーを生成

💡 実用シナリオ

機能開発のGitワークフロー

/sc:git flow --smart-commit --push --create-pr

背景:

フィーチャーブランチの管理：

新しいダッシュボード分析機能の作業中
開発中に複数のコミットを実施
PR前にクリーンなコミット履歴を作成する必要がある
リモートにプッシュしてプルリクエストを作成したい

結果:

プロジェクトの規約に従って変更がコミットされ、コードレビューに提出されました。

ホットフィックスのデプロイ

/sc:git flow --smart-commit --push --create-pr --title "Hotfix: Payment callback race condition"

背景:

重大なバグ修正：

本番環境の決済処理バグが発見された
本番ブランチから緊急ホットフィックスを作成する必要がある
Gitのベストプラクティスを維持しながら迅速に修正をデプロイする必要がある
マージ前に自動テストが必要

結果:

ホットフィックスが本番環境にデプロイされ、検証とロールバック計画が文書化されました。

/sc:document - ドキュメント生成

コード、API、コンポーネントの明確で正確な技術ドキュメントを生成

構文

/sc:document [--type api|code|readme|guide] [--format markdown|html|jsdoc] [対象]

例 13.1: インラインドキュメント

/sc:document --type inline --style brief "utils.js"

✨ 効果:

コードコメントを追加
簡潔なスタイル
高速生成

例 13.2: APIドキュメント

/sc:document --type api --style detailed "src/api/"

✨ 効果:

完全なAPIドキュメント
パラメータ説明
サンプルコード

例 13.3: ユーザーガイド

/sc:document --type guide --style detailed --format markdown --toc ""

✨ 効果:

完全なユーザーガイド
目次構造
図解説明
ベストプラクティス
検索フレンドリー

💡 実用シナリオ

APIドキュメントの生成

/sc:document --type api --format markdown "src/api/"

背景:

ドキュメントのニーズ：

バックエンドAPIに包括的なドキュメントが欠けている
フロントエンドチームがエンドポイントの契約を理解するのに苦労している
最新のAPIリファレンスを生成する必要がある
リクエスト/レスポンスの例を含めたい

結果:

APIドキュメントが生成され、包括的なエンドポイントリファレンスと例が含まれました。

コンポーネントライブラリのドキュメント

/sc:document --type code --format markdown "src/components/"

背景:

コンポーネントのドキュメント：

Reactコンポーネントライブラリがドキュメントなしで成長している
開発者が既存のコンポーネントの使用方法が不明
props、使用例、ベストプラクティスをドキュメント化する必要がある
インタラクティブなコンポーネントショーケースを作成したい

結果:

コンポーネントドキュメントが作成され、使用例とプロップ仕様が含まれました。

💡 ベストプラクティス:

ドキュメントとコードを同期的に更新
豊富な使用例を提供
APIドキュメントに完全なリクエスト/レスポンス例を含める
ドキュメントは簡潔で理解しやすく、過度に技術的にならないように

/sc:cleanup - コードクリーンアップ

コードベースを体系的にクリーンアップし、デッドコードを削除し、プロジェクト構造を最適化

構文

/sc:cleanup [--type imports|code|all] [--safe] [--preview] [--aggressive] [--interactive] [--backup]

パラメータ

--type: : クリーンアップタイプ
- imports
- code
- all
--safe: : 安全モード、保守的なアプローチ
--preview: : プレビューモード、実際の変更なし
--aggressive: : アグレッシブモード(慎重に使用)
--interactive: : 各クリーンアップ項目を個別に確認
--backup: : 自動バックアップ

例 11.1: インポートのクリーンアップ

/sc:cleanup --type imports --safe "src/"

✨ 効果:

未使用のインポートをクリーン
保守的な処理
高速実行

例 11.2: デッドコードの削除

/sc:cleanup --type code --preview "."

✨ 効果:

デッドコードを識別
プレビューモード
クリーンアップレポート

例 11.3: アグレッシブクリーンアップ

/sc:cleanup --type all --aggressive --interactive --backup ""

✨ 効果:

包括的深層クリーンアップ
アグレッシブモード（慎重に使用）
各項目を確認
自動バックアップ
クリーンアップ統計レポート

💡 実用シナリオ

レガシーコードのクリーンアップ

/sc:cleanup --type code --safe --preview "src/"

背景:

コードクリーンアップ要件：

プロジェクトに未使用のコードと非推奨の機能が蓄積されている
デッドコードがコードベースの保守性に影響
安全に時代遅れのコンポーネントを削除する必要がある
アクティブな機能に破壊的変更がないことを確認する必要がある

結果:

レガシーコードが削除され、機能損失がないことを確認する検証テストが実施されました。

依存関係のクリーンアップと更新

/sc:cleanup --type all --safe --backup

背景:

依存関係管理：

package.jsonに古い脆弱な依存関係がある
npm auditで複数のセキュリティ脆弱性が報告されている
破壊的変更なしで安全にパッケージを更新する必要がある
未使用の依存関係を削除したい

結果:

コードベースのクリーンアップが完了し、未使用コードが削除され、依存関係が更新されました。

💡 ベストプラクティス:

定期的にクリーンアップして技術的負債の蓄積を回避
クリーンアップ前にテストを実行して機能が破壊されないことを確認
バックアップには常に --safe モードを使用
クリーンアップ後にアプリケーションが正常に動作することを確認

/sc:troubleshoot - トラブルシューティング

コードの問題、ビルド失敗、ランタイムエラーを体系的に診断・解決

構文

/sc:troubleshoot [--type bug|performance|build] [--trace] [--fix] [--safe-mode] "<問題の説明>"

パラメータ

--type: : 問題のタイプ
- bug
- performance
- build
--trace: : 詳細なスタックトレース分析
--fix: : 自動修正を試行
--safe-mode: : 安全モード、保守的な修正戦略を使用

例 6.1: パフォーマンス問題

/sc:troubleshoot --type performance --trace "API response slow"

✨ 効果:

パフォーマンス問題の特定
フレームグラフの生成
ボトルネックの識別

例 6.2: ビルド失敗

/sc:troubleshoot --type build --fix

✨ 効果:

ビルド問題の自動検出
自動修正を試行
解決策を提供

例 6.3: 本番環境デバッグ

/sc:troubleshoot --type bug --trace --fix --safe-mode --seq ""

✨ 効果:

セーフモードデバッグ
深層スタックトレース
Sequentialによる根本原因分析
保守的な修正戦略
パフォーマンス影響評価

💡 実用シナリオ

本番API障害調査

/sc:troubleshoot --type bug --trace --fix --safe-mode "checkout API 500 errors"

背景:

重大な本番問題：

チェックアウトAPIで500エラーが報告されている
エラー率が通常の0.1%から15%に急増
根本原因を迅速に特定する必要がある
サービスをできるだけ早く復旧させる必要がある

結果:

根本原因が特定され、再発を防ぐための監視とともに修正が実装されました。

Performance Degradation Root Cause Analysis

/sc:troubleshoot --type performance --trace --fix "dashboard performance"

背景:

Performance issue investigation:

Dashboard loading time increased from 2s to 8s over past week
No recent code changes to frontend
Users complaining about slow experience
Need to find what changed and fix it

結果:

パフォーマンスの問題が診断され、最適化の推奨事項が適用されて解決されました。

💡 ベストプラクティス:

完全なエラー情報とコンテキストを提供
--traceを使用して詳細なスタックトレース分析を実行
本番環境の問題には --safe-mode を使用して安全性を確保
修正適用後に問題が解決されたことを検証
診断プロセスを記録し、問題の再発を防止

/sc:explain - コード説明

明確な言葉でコード、概念、システムの動作を説明

構文

/sc:explain [--level beginner|intermediate|expert] [--focus logic|architecture|performance|security] [対象]

例 1: 複雑な関数の説明

/sc:explain --level intermediate --focus security @utils/encryption.js

✨ 効果:

暗号化アルゴリズムを段階的に説明
なぜこのソリューションを選択したか説明
セキュリティ上の重要なポイントを指摘
パラメータと戻り値を説明

例 2: アーキテクチャ説明

/sc:explain --level beginner --focus architecture "Microservices Architecture"

✨ 効果:

平易な言葉でマイクロサービスの概念を説明
モノリシックアーキテクチャとの違いを比較
適用シナリオを説明
入門例を提供

💡 実用シナリオ

複雑なアルゴリズムの説明

/sc:explain --level beginner "src/cache/lru-cache.ts"

背景:

学習シナリオ：

新しいチームメンバーがプロジェクトに参加
カスタムキャッシングアルゴリズムの理解に苦戦
コードにコメントとドキュメントが欠けている
その仕組みの明確な説明が必要

結果:

アルゴリズムの説明が提供され、ステップバイステップの分解とビジュアル例が含まれました。

アーキテクチャパターンの説明

/sc:explain --level intermediate --focus architecture "Event sourcing pattern in payment service"

背景:

コードレビューディスカッション：

チームがマイクロサービスのイベント駆動アーキテクチャについて議論中
一部の開発者がイベントソーシングパターンに不慣れ
パターンとその使用理由を説明する必要がある
利点とトレードオフを示したい

結果:

アーキテクチャパターンが説明され、実装ガイダンスとベストプラクティスが提供されました。

💡 ベストプラクティス:

対象者に応じて適切な--levelを選択
説明を要求する際は具体的なコンテキストを提供
--focusを使用して関心のある側面に焦点を当てる
説明後に質問してさらに深く理解

/sc:business-panel - ビジネスエキスパートパネル

適応的なインタラクションモードを備えた複数専門家によるビジネス分析

構文

/sc:business-panel [--mode discussion|debate|socratic] [--experts "expert1,expert2"] [--focus domain] [document]

例: イノベーション評価

/sc:business-panel --mode discussion --focus strategy "SaaS pricing model evaluation"

✨ 効果:

Christensenのjobs-to-be-done(ジョブ理論)分析
Druckerの顧客価値視点
Godinのマーケット推進戦略

💡 実用シナリオ

製品戦略レビュー

/sc:business-panel --mode sequential "SaaS project management tool - freemium vs paid subscription strategy"

背景:

戦略計画：

プロジェクト管理のための新しいSaaS製品を立ち上げ中
市場ポジショニングと価格戦略の検証が必要
フリーミアムモデルとサブスクリプションモデルを評価中
市場参入アプローチについて専門家のガイダンスが欲しい

結果:

ビジネス戦略エキスパートパネルが完了し、市場ポジショニングと市場投入の推奨事項が提供されました。

ビジネスモデルのピボット評価

/sc:business-panel --mode debate "Pivot from B2C to B2B enterprise model"

背景:

ピボットの決定：

現在のB2Cモデルが成長目標を達成していない
B2Bエンタープライズセールスへのピボットを検討中
実現可能性とリスクを評価する必要がある
長所と短所について構造化された議論が必要

結果:

ビジネスモデル分析が完了し、ピボット決定フレームワークとリスク評価が提供されました。

/sc:estimate - 開発見積もり

タスク、機能、またはプロジェクトの開発時間とリソース見積もりを提供

構文

/sc:estimate [--detail brief|standard|comprehensive] [--team-size N] [--complexity auto|low|medium|high] [タスク説明]

例 14.1: 時間見積もり

/sc:estimate --type time --unit hours "Implement login functionality"

✨ 効果:

作業時間見積もり
時間単位で正確
バッファ時間を含む

例 14.2: 複雑性評価

/sc:estimate --type complexity "Microservice decomposition"

✨ 効果:

技術的複雑性
リスク評価
難易度レベル

例 14.3: 詳細プロジェクト見積もり

/sc:estimate --type effort --unit days --breakdown --team-size 5 ""

✨ 効果:

完全な工数分解
チームサイズを考慮
タスク依存関係
バーンダウンチャート予測
コスト見積もり

💡 実用シナリオ

機能開発の見積もり

/sc:estimate --type time --unit days --breakdown --team-size 3 "Analytics dashboard with charts, filters, CSV export"

背景:

スプリント計画：

プロダクトマネージャーが新しい分析ダッシュボードの見積もりを要求
機能にはデータ可視化、フィルタリング、エクスポート機能が含まれる
スプリント計画のために現実的なタイムラインを提供する必要がある
チームには3名の開発者が利用可能

結果:

開発工数が見積もられ、タイムラインとリソース要件が定義されました。

技術的負債のリファクタリング見積もり

/sc:estimate --type time --unit days --breakdown "Refactor authentication system to modern architecture"

背景:

リファクタリング計画：

レガシー認証システムをリファクタリングする必要がある
現在のコードは保守とテストが困難
下位互換性を維持する必要がある
リソースをコミットする前に現実的な見積もりが必要

結果:

リファクタリング工数が見積もられ、段階的なアプローチとタイムラインが定義されました。

💡 ベストプラクティス:

精度を上げるために詳細な機能説明を提供
チームの経験を考慮して見積もりを調整
20-30%のバッファ時間を確保
履歴データを使用して見積もりモデルを校正

/sc:spec-panel - 仕様レビュー

著名な仕様およびソフトウェアエンジニアリング専門家による複数専門家仕様レビューと改善

構文

/sc:spec-panel @spec-document [--mode review|critique|improve] [--focus clarity|completeness|feasibility]

例: API仕様レビュー

/sc:spec-panel --mode improve --focus completeness @specs/api-design.md

✨ 効果:

専門家パネルレビュー(アーキテクト、テクニカルライティング専門家)
欠落しているエンドポイントとパラメータを識別
不完全なエラーハンドリングを指摘
改善提案と例を提供
より完全な仕様バージョンを生成

💡 実用シナリオ

API Specification Review

/sc:spec-panel --mode improve --focus completeness "docs/api-spec.yaml"

背景:

Specification review:

Drafted new REST API specification for microservices
Need expert review for best practices and potential issues
Want to ensure scalability and maintainability
Require feedback on naming conventions and structure

結果:

エキスパートパネルレビューが完了し、実行可能な推奨事項と実装優先順位が設定されました。

Database Schema Review

/sc:spec-panel --mode critique --focus feasibility "schemas/ecommerce.sql"

背景:

Schema validation:

Designed database schema for e-commerce platform
Includes users, products, orders, payments tables
Need expert validation for normalization and performance
Want to identify potential scaling issues

結果:

データベーススキーマが専門家によってレビューされ、最適化提案とベストプラクティスが文書化されました。

💡 ベストプラクティス:

仕様の初稿完成後、直ちにレビュー
critique モードを使用して隠れた問題を発見
レビュー後、提案に基づいて仕様を修正
品質基準に達するまでレビューを繰り返す

/sc:index - プロジェクトインデックス

包括的なプロジェクトドキュメントとナレッジベースインデックスの生成、プロジェクト情報のインテリジェントな整理

構文

/sc:index [--type codebase|docs|all] [--depth shallow|deep] [--output markdown|json|html]

例: コードベースインデックス

/sc:index --type codebase --depth deep --output markdown

✨ 効果:

コードベース全体をスキャン
ディレクトリ構造ツリーを生成
すべてのモジュールと依存関係をリスト
主要な関数とクラスを抽出
PROJECT_INDEX.mdを生成

💡 実用シナリオ

プロジェクトナレッジベースのインデックス作成

/sc:index --type codebase --depth shallow --output markdown

背景:

新入社員がプロジェクトを迅速に理解する必要があり、包括的なコードインデックスを確立：

プロジェクト全体の構造を把握する必要がある
主要なモジュールと依存関係を特定したい
素早くコードベースをナビゲートできるようにしたい

結果:

プロジェクトのナレッジベースがインデックス化され、高速なセマンティック検索とナビゲーションが可能になりました。

インクリメンタルインデックス更新

/sc:index --type docs --depth deep --output json

背景:

プロジェクトの頻繁な更新：

プロジェクトが頻繁に更新される
最新の状態を保つため定期的にインデックスを更新する必要がある
変更されたファイルのみを効率的に再インデックス化したい

結果:

インデックスが更新され、最近の変更が組み込まれて検索精度が向上しました。

特定モジュールのインデックス作成

/sc:index --type all --depth shallow --output html

背景:

決済モジュールのリファクタリング：

決済関連のコードのみをインデックス化する必要がある
関連する依存関係を特定したい
詳細なモジュール構造を理解したい

結果:

モジュールインデックスが生成され、依存関係グラフとドキュメントがレビュー準備完了しました。

💡 ベストプラクティス:

新しいプロジェクトに参加する際は、まずインデックスを実行
同期を保つため定期的にインデックスを更新
インデックスを使用して大規模プロジェクトを迅速にナビゲート
インデックスを新メンバーの入門ドキュメントとして活用

🤖 専門エージェント

専門エージェントとは？

SuperClaude フレームワークには 15の専門エージェント が組み込まれており、それぞれが特定の領域で深い専門知識を持っています。エージェントは自動的に有効化されるか、フラグパラメータを介して手動で指定できます。

🎨 フロントエンド開発エージェント

frontend-architect

アクセシブルで高性能なユーザーインターフェースを作成し、ユーザーエクスペリエンスとモダンフレームワークに焦点を当てる

専門分野：

React、Vue、Angularなどのモダンフレームワーク
レスポンシブデザインとモバイル最適化
Webアクセシビリティ（WCAG 2.1）
パフォーマンス最適化とコード分割

⚙️ バックエンド開発エージェント

backend-architect

データの整合性、セキュリティ、フォールトトレランスに焦点を当てた信頼性の高いバックエンドシステムを設計

専門分野：

RESTful および GraphQL API 設計
データベースアーキテクチャと最適化
認証と認可
マイクロサービスアーキテクチャ

🏗️ システムアーキテクチャエージェント

system-architect

保守性と長期的な技術的決定に焦点を当てたスケーラブルなシステムアーキテクチャを設計

専門分野：

システム設計パターン
スケーラビリティアーキテクチャ
技術選択
アーキテクチャドキュメント

🐍 Python エキスパートエージェント

python-expert

SOLID 原則に従った本番対応、安全、高性能な Python コードを提供

専門分野：

Python ベストプラクティス
FastAPI、Django、Flask
データ処理と分析
非同期プログラミング

🚀 DevOps エージェント

devops-architect

信頼性と可観測性に焦点を当てたインフラストラクチャとデプロイメントプロセスの自動化

専門分野：

CI/CD パイプライン
Docker と Kubernetes
監視とログ
Infrastructure as Code

🔧 リファクタリングエキスパートエージェント

refactoring-expert

体系的なリファクタリングとクリーンコードの原則を通じてコード品質を向上させ、技術的負債を削減

専門分野：

コードスメルの識別
リファクタリングパターン
コード品質メトリクス
技術的負債管理

🎓 その他の専門エージェント

SuperClaude には以下の専門エージェントも含まれています：

security-engineer

セキュリティ脆弱性の識別とコンプライアンス

quality-engineer

包括的なテスト戦略

performance-engineer

パフォーマンス最適化

learning-guide

プログラミング教育

root-cause-analyst

根本原因分析

requirements-analyst

要件の発見

technical-writer

技術ドキュメント

socratic-mentor

ソクラテス式教授法

business-panel-experts

ビジネス戦略パネル（9人の専門家）

🚩 フラグパラメータリファレンス

フラグパラメータでコマンドの動作をカスタマイズできます。利用可能なすべてのフラグは次のとおりです：

⚡ モード有効化フラグ

これらのフラグは特定の作業モードを有効化し、AI 機能と対話方法を強化します

フラグ	説明	トークンコスト	適用コマンド
`--brainstorm`	ソクラテス式対話を通じて要件を探索する協調的発見思考モードを有効化	+2-3K	すべてのコマンド
`--introspect`	思考プロセスの透明性を表示し、AI に推論ステップを表示させる	+1-2K	すべてのコマンド
`--task-manage`	複数ステップのタスク管理を有効化し、複雑なタスクを自動的に追跡および整理	+1K	すべてのコマンド
`--orchestrate`	複数ツールの並列実行を有効化し、複数の MCP サーバーとツールを調整	+3-5K	すべてのコマンド
`--token-efficient`	トークン最適化モードを有効化し、品質を維持しながらトークン消費を削減	-30-50%	すべてのコマンド
`--plan`	計画モードを有効化し、実行前に詳細な計画を生成	標準	implement, design, refactor
`--validate`	検証モードを有効化し、出力と結果を自動的に検証	標準	implement, test, build
`--parallel`	並列実行を有効化し、複数のタスクを同時に処理	標準	test, analyze, research
`--interactive`	インタラクティブモードを有効化し、ステップバイステップで確認と調整	標準	brainstorm, design

🔍 分析深度フラグ

AI の分析深度を制御し、速度と詳細のバランスを調整

フラグ	トークンコスト	説明	シナリオ
`--think`	~4K	標準的な分析深度、通常の開発タスクに適している	日常の開発
`--think-hard`	~10K	多角的な思考と検証を伴う深い分析	複雑な問題
`--ultrathink`	~32K	すべての可能性を尽くす最大深度分析	重要な決定
`--depth shallow`	低	迅速な概要、時間が限られている状況に適している	クイックチェック
`--depth normal`	標準	速度と詳細のバランス（デフォルト）	通常の分析
`--depth deep`	高	複雑なシナリオのための包括的な詳細分析	詳細な評価

🔌 MCP サーバー制御

専門機能のために MCP サーバーを選択的に有効化

フラグ	エイリアス	サーバー	目的
`--c7`	`--context7`	Context7	フレームワークドキュメントクエリ、公式の最新ドキュメントとベストプラクティスを取得
`--seq`	`--sequential`	Sequential	複雑な推論分析、複数ステップの体系的思考
`--magic`	`--magic`	Magic	21st.dev モダンコンポーネントライブラリに基づく UI コンポーネント生成
`--morph`	`--morphllm`	Morphllm	バッチコード編集、パターンベースの高速修正
`--serena`	`--serena`	Serena	プロジェクトメモリ管理、セマンティックコード理解とセッション永続化
`--play`	`--playwright`	Playwright	ブラウザ自動化テスト、E2E テストと UI 検証

⚙️ 実行制御フラグ

コマンドの実行方法と動作を制御

フラグ	説明	例
`--dry-run`	実際の変更を行わずに実行をシミュレート	`/sc:implement --dry-run`
`--force`	強制実行、確認プロンプトをスキップ	`/sc:cleanup --force`
`--auto-commit`	変更を Git に自動的にコミット	`/sc:implement --auto-commit`
`--no-test`	テストステップをスキップ	`/sc:build --no-test`

💡 組み合わせ使用例

フラグを組み合わせてより強力な機能を実現できます：

/sc:analyze --think-hard --serena --c7 "src/api"
深い思考、プロジェクトメモリ、公式ドキュメントを使用して API コードを分析
/sc:implement --brainstorm --plan --validate "ユーザー認証"
協力して要件を探索し、実装を計画し、結果を検証
/sc:improve --token-efficient --morph --dry-run "src/"
トークン最適化とバッチ編集ツールを使用してコード改善をプレビュー

💡 実用的なヒント

以下は、実際の開発シナリオと推奨されるコマンドの組み合わせです：

📦 ゼロから新機能を開発

/sc:brainstorm "ユーザー認証機能" --depth deep
/sc:design --think
/sc:implement --plan --validate
/sc:test --parallel
/sc:document
/sc:git "feat: ユーザー認証を追加"

ワークフローの説明：

要件の探索：機能の範囲と技術的アプローチを明確化
システム設計：認証フローとデータモデルを設計
機能実装：コードを書き、検証
テスト検証：テストスイートを並行実行
ドキュメント生成：API ドキュメントを自動生成
コードコミット：標準的な Git コミットを作成

🐛 緊急バグ修正プロセス

/sc:troubleshoot --depth deep
/sc:analyze --focus security
/sc:implement --validate
/sc:test --parallel
/sc:git "fix: 認証バイパスを解決"

🔧 コードリファクタリングとパフォーマンス最適化

/sc:analyze --depth deep
/sc:improve --plan
/sc:test --validate
/sc:cleanup

🎨 React コンポーネント開発

/sc:design "ユーザープロフィールカードコンポーネント"
/sc:implement --persona frontend-architect
/sc:test --focus accessibility
/sc:document

🎓 学習リソース

公式ドキュメント

コミュニティリソース

💡 ヒント：

問題が発生しましたか？ FAQ を確認するか、GitHub で Issue を提出してください。