scコマンド3,000回の使い分け実践：Claude Codeのカスタムコマンド活用データ

1
/sc:implement     801回  ████████████████████████████████████████  (25.6%)
2
/sc:design        682回  ██████████████████████████████████        (21.8%)
3
/sc:analyze       599回  ██████████████████████████████            (19.2%)
4
/sc:git           385回  ███████████████████                       (12.3%)
5
/sc:document      270回  █████████████                             ( 8.6%)
6
/sc:troubleshoot  218回  ██████████                                ( 7.0%)
7
/sc:save           68回  ███                                       ( 2.2%)
8
/sc:improve        64回  ███                                       ( 2.0%)
9
/sc:test           29回  █                                         ( 0.9%)
10
/sc:brainstorm     10回  ▏                                         ( 0.3%)
11
                ──────
12
合計            3,126回  108セッション / 2,390ユーザーメッセージ

1
session_stats = {
2
    "total_sessions": 108,
3
    "total_commands": 3126,
4
    "avg_per_session": 28.9,
5
    "total_user_messages": 2390,
6
    "command_ratio": 3126 / 2390,  # 1.31: メッセージ1回あたり1.3回のコマンド
7
}

1
使用タイミング:
2
  - 設計が固まった後の実装フェーズ
3
  - バグ修正
4
  - 新機能追加
5
  - リファクタリング
6

7
使用パターン:
8
  /sc:design → (設計承認) → /sc:implement → /sc:test

1
使用タイミング:
2
  - 新機能の実装前
3
  - 既存機能の大規模リファクタリング前
4
  - データパイプラインの変更前
5

6
出力例:
7
  - モジュール構成図
8
  - データフロー図
9
  - インターフェース定義
10
  - 影響範囲分析

1
使用タイミング:
2
  - デプロイ前の品質チェック
3
  - 大規模変更後の影響分析
4
  - 定期的なコードベース品質監査
5
  - QAワークフローの第1ステップ
6

7
出力例:
8
  品質: 循環的複雑度 最大19、関数行数 最大45行
9
  セキュリティ: ハードコードされたシークレット 0件
10
  パフォーマンス: N+1クエリパターン 0件

1
# /sc:git が生成するコミットメッセージの例
2
commit_messages = [
3
    "feat(pipeline): リトライ制御の状態機械を実装",
4
    "fix(api): 外部API認証エラー時のリトライロジック修正",
5
    "refactor(common): commonLogger のProtocolパターン適用",
6
    "test(pipeline): 安定期における処理判定のエッジケーステスト追加",
7
]

1
使用タイミング:
2
  - テスト失敗時
3
  - 本番エラー発生時
4
  - ビルドエラー時
5
  - 原因不明の挙動変化時
6

7
分析フロー:
8
  1. エラーメッセージの解析
9
  2. 関連ファイルの確認
10
  3. 変更履歴の確認
11
  4. 根本原因の特定
12
  5. 修正案の提示

1
使用例:
2
  "新しいエラーフィルターのアイデアが欲しい"
3
  "エラーハンドリング戦略を根本的に見直したい"

1
/sc:analyze → /sc:test → /sc:improve → /sc:document
2
   ↓              ↓           ↓              ↓
3
 品質分析      テスト実行   改善提案     ドキュメント更新
4
 599回          29回        64回          270回

1
テスト実行の内訳（推定）:
2
  /sc:implement 内での個別テスト:    ~400回
3
  /sc:test での正式QAテスト:           29回
4
  /sc:troubleshoot 内での検証テスト:  ~100回

1
# /sc:analyze - コード分析と品質評価
2

3
## Triggers
4
- コード品質評価のリクエスト
5
- セキュリティ脆弱性のスキャン
6
- パフォーマンスボトルネックの特定
7

8
## Actions
9
1. 変更されたファイルを特定
10
2. 品質メトリクス（循環的複雑度、関数行数、ネスト深度）を計算
11
3. セキュリティパターンをスキャン
12
4. パフォーマンスアンチパターンを検出
13

14
## Output
15
- 品質スコア
2 collapsed lines
16
- セキュリティ検出事項
17
- パフォーマンス改善推奨

1
# /sc:troubleshoot - エラー診断と解決
2

3
## Triggers
4
- テスト失敗時
5
- エラーメッセージの調査依頼
6
- 原因不明の挙動変化
7

8
## Actions
9
1. エラーメッセージを解析
10
2. スタックトレースから関連ファイルを特定
11
3. 最近の変更履歴（git log）を確認
12
4. 根本原因を推定
13
5. 修正案を複数提示
14

15
## Output
3 collapsed lines
16
- 根本原因分析
17
- 修正案（優先度付き）
18
- 再発防止策

1
command_design_principles = {
2
    "single_responsibility": "1コマンド = 1つの明確な目的",
3
    "clear_triggers": "いつ使うべきかが明確",
4
    "structured_output": "出力フォーマットが統一されている",
5
    "composable": "コマンド同士を連鎖できる",
6
}

1
Phase 1（開始時）:
2
  /sc:analyze のみ
3
  → 「品質チェックを定型化したい」というニーズから
4

5
Phase 2（1ヶ月後）:
6
  + /sc:implement, /sc:design
7
  → 「設計と実装を明確に分離したい」
8

9
Phase 3（2ヶ月後）:
10
  + /sc:git, /sc:test, /sc:troubleshoot
11
  → 「Git操作とテスト実行も構造化したい」
12

13
Phase 4（3ヶ月後）:
14
  + /sc:document, /sc:improve, /sc:save
15
  → 「QAワークフローを完成させたい」
4 collapsed lines
16

17
Phase 5（4ヶ月後）:
18
  + /sc:brainstorm
19
  → 「要件探索もコマンド化してみよう」（結果: あまり使わなかった）

1
施策実装セッション（典型的な30メッセージのセッション）:
2
  /sc:design      ×3  設計議論
3
  /sc:implement   ×8  実装
4
  /sc:test        ×1  テスト実行
5
  /sc:analyze     ×2  品質チェック
6
  /sc:improve     ×1  改善提案
7
  /sc:document    ×1  ドキュメント更新
8
  /sc:git         ×3  コミット・PR作成
9
  自然言語対話    ×11 議論・確認・方針決定
10

11
バグ修正セッション（典型的な15メッセージのセッション）:
12
  /sc:troubleshoot ×3  原因調査
13
  /sc:implement    ×4  修正
14
  /sc:test         ×1  検証
15
  /sc:git          ×2  コミット
1 collapsed line
16
  自然言語対話     ×5  状況説明・確認

1
co_occurrence = {
2
    ("design", "implement"): 0.85,    # designの85%はimplementが続く
3
    ("analyze", "improve"): 0.72,     # analyzeの72%はimproveが続く
4
    ("troubleshoot", "implement"): 0.68,  # troubleshootの68%はimplementが続く
5
    ("implement", "git"): 0.91,       # implementの91%はgitが続く
6
}