pipeline

Pipeline スキル

概要

pipeline スキルでは、複数のエージェントを定義済みのワークフローで連携させ、あるエージェントの出力を次のエージェントの入力として渡すことができます。これにより、Unix パイプに似た、AI エージェントのオーケストレーション向けに設計された強力なエージェントパイプラインを構築できます。

基本概念

1. 順次パイプライン

最も単純な形式です。エージェント A の出力がエージェント B に渡され、さらにエージェント C に渡されます。

explore -> architect -> executor

フロー：

1. Explore エージェントがコードベースを検索し、調査結果をまとめます
2. Architect が調査結果を受け取り、分析と推奨事項を作成します
3. Executor が推奨事項を受け取り、変更を実装します

2. 分岐パイプライン

出力条件に基づいて、異なるエージェントに処理を振り分けます。

explore -> {
  if "complex refactoring" -> architect -> executor-high
  if "simple change" -> executor-low
  if "UI work" -> designer -> executor
}

3. 並列実行後に統合するパイプライン

複数のエージェントを並列で実行し、その出力を統合します。

parallel(explore, document-specialist) -> architect -> executor

組み込みパイプラインプリセット

Review パイプライン

目的： 包括的なコードレビューと実装

/pipeline review <task>

ステージ：

1. explore - 関連するコードとパターンを探します
2. architect - アーキテクチャと設計への影響を分析します
3. critic - 分析をレビューし、批評します
4. executor - すべてのコンテキストを踏まえて実装します

用途： 大規模な機能、リファクタリング、複雑な変更

---

Implement パイプライン

目的： テストを伴う計画的な実装

/pipeline implement <task>

ステージ：

1. planner - 詳細な実装計画を作成します
2. executor - 計画を実装します
3. test-engineer - テストを追加または検証します

用途： 要件が明確な新機能

---

Debug パイプライン

目的： 体系的なデバッグワークフロー

/pipeline debug <issue>

ステージ：

1. explore - エラー箇所と関連コードを特定します
2. architect - 根本原因を分析します
3. build-fixer - 修正を適用し、検証します

用途： バグ、ビルドエラー、テスト失敗

---

Research パイプライン

目的： 外部調査と内部分析

/pipeline research <topic>

ステージ：

1. parallel(document-specialist, explore) - 外部ドキュメントと内部コードを調査します

2. architect - 調査結果を統合します

3. writer - 推奨事項を文書化します

用途： 技術選定、API 統合

---

Refactor パイプライン

目的： 安全性を検証しながら行うリファクタリング

/pipeline refactor <target>

ステージ：

1. explore - すべての使用箇所と依存関係を探します
2. architect-medium - リファクタリング戦略を設計します
3. executor-high - リファクタリングを実行します
4. qa-tester - リグレッションがないことを検証します

用途： アーキテクチャの変更、API の再設計

---

Security パイプライン

目的： セキュリティ監査と修正

/pipeline security <scope>

ステージ：

1. explore - 脆弱性の可能性がある箇所を探します
2. security-reviewer - 監査して問題を特定します
3. executor - 修正を実装します
4. security-reviewer-low - 再検証します

用途： セキュリティレビュー、脆弱性の修正

---

カスタムパイプラインの構文

基本的な順次実行

/pipeline agent1 -> agent2 -> agent3 "task description"

例：

/pipeline explore -> architect -> executor "add authentication"

モデルの指定

/pipeline explore:haiku -> architect:opus -> executor:sonnet "optimize performance"

分岐を含む場合

/pipeline explore -> (
  complexity:high -> architect:opus -> executor-high:opus
  complexity:medium -> executor:sonnet
  complexity:low -> executor-low:haiku
) "fix reported issues"

並列ステージを含む場合

/pipeline [explore, document-specialist] -> architect -> executor "implement OAuth"

データ受け渡しプロトコル

パイプライン内の各エージェントは、前のステージから構造化されたコンテキストを受け取ります。

{
  "pipeline_context": {
    "original_task": "user's original request",
    "previous_stages": [
      {
        "agent": "explore",
        "model": "haiku",
        "findings": "...",
        "files_identified": ["src/auth.ts", "src/user.ts"]
      }
    ],
    "current_stage": "architect",
    "next_stage": "executor"
  },
  "task": "specific task for this agent"
}

エラー処理

再試行ロジック

エージェントが失敗した場合、パイプラインでは次の処理を行えます。

1. 再試行 - 同じエージェントを再実行します（最大 3 回）
2. スキップ - 部分的な出力で次のステージに進みます
3. 中止 - パイプライン全体を停止します
4. フォールバック - 別のエージェントに処理を振り分けます

設定：

/pipeline explore -> architect -> executor --retry=3 --on-error=abort

エラー復旧パターン

パターン 1：上位ティアへのフォールバック

executor-low -> on-error -> executor:sonnet

パターン 2：Architect への相談

executor -> on-error -> architect -> executor

パターン 3：人間を介した確認

any-stage -> on-error -> pause-for-user-input

パイプラインの状態管理

パイプラインの状態は .omc/pipeline-state.json に保持されます。

{
  "pipeline_id": "uuid",
  "name": "review",
  "active": true,
  "current_stage": 2,
  "stages": [
    {
      "name": "explore",
      "agent": "explore",
      "model": "haiku",
      "status": "completed",
      "output": "..."
    },
    {
      "name": "architect",
      "agent": "architect",
      "model": "opus",
      "status": "in_progress",
      "started_at": "2026-01-23T10:30:00Z"
    },
    {
      "name": "executor",
      "agent": "executor",
      "model": "sonnet",
      "status": "pending"
    }
  ],
  "task": "original user task",
  "created_at": "2026-01-23T10:25:00Z"
}

検証ルール

パイプラインを完了する前に、次の点を検証してください。

• すべてのステージが正常に完了している
• 最終ステージの出力が元のタスクに対応している
• どのステージにも未処理のエラーがない
• 変更したすべてのファイルが lsp_diagnostics を通過している
• 該当する場合、テストが成功している

高度な機能

条件分岐

エージェントの出力に基づいて、異なる経路に処理を振り分けます。

explore -> {
  if files_found > 5 -> architect:opus -> executor-high:opus
  if files_found <= 5 -> executor:sonnet
}

ループ構造

条件を満たすまでステージを繰り返します。

repeat_until(tests_pass) {
  executor -> qa-tester
}

マージ戦略

並列エージェントの処理が完了したとき：

• concat：すべての出力を連結します
• summarize：architect を使用して調査結果を要約します
• vote：critic を使用して最適な出力を選びます

使用例

例 1：機能の実装

/pipeline review "add rate limiting to API"

→ 実行される処理：explore → architect → critic → executor

例 2：バグ修正

/pipeline debug "login fails with OAuth"

→ 実行される処理：explore → architect → build-fixer

例 3：カスタムチェーン

/pipeline explore:haiku -> architect:opus -> executor:sonnet -> test-engineer:sonnet "refactor auth module"

例 4：調査に基づく実装

/pipeline research "implement GraphQL subscriptions"

→ 実行される処理：parallel(document-specialist, explore) → architect → writer

キャンセル

実行中のパイプラインを停止します：

/pipeline cancel

または、実行中のパイプラインを検出する汎用キャンセルコマンドを使用します。

他のスキルとの連携

パイプラインは他のスキル内で使用できます：

• Ralph：検証が完了するまでパイプラインを繰り返します
• Ultrawork：複数のパイプラインを並列実行します
• Autopilot：パイプラインを構成要素として使用します

ベストプラクティス

1. プリセットから始める - カスタムパイプラインを作成する前に、組み込みパイプラインを使用します
2. 複雑さに応じてモデルを選ぶ - 単純なタスクに opus を使って無駄にしないでください
3. ステージの役割を絞る - 各エージェントに明確な責任を 1 つ持たせます
4. 並列ステージを活用する - 独立した作業を同時に実行します
5. チェックポイントで検証する - architect または critic を使用して進捗を検証します
6. カスタムパイプラインを文書化する - 成功したパターンを保存して再利用します

トラブルシューティング

パイプラインが停止する

確認： 現在のステージを .omc/pipeline-state.json で確認します 対処： /pipeline resume で再開するか、キャンセルして再起動します

エージェントが繰り返し失敗する

確認： 再試行回数とエラーメッセージを確認します 対処： より上位のエージェントに割り当てるか、architect による相談を追加します

出力が引き継がれない

確認： エージェントのプロンプトでデータを渡す構造を確認します 対処： 各エージェントのプロンプトに pipeline_context が含まれていることを確認します

技術的な実装

パイプラインオーケストレーターは、次の処理を行います：

1. パイプライン定義を解析する - 構文とエージェント名を検証します
2. 状態を初期化する - pipeline-state.json を作成します
3. ステージを順番に実行する - Task ツールでエージェントを起動します
4. ステージ間でコンテキストを渡す - 次のエージェント向けに出力を構成します
5. 分岐ロジックを処理する - 条件を評価して処理を振り分けます
6. 並列実行を管理する - 並行エージェントを起動し、結果をマージします
7. 状態を保持する - 各ステージの後に状態ファイルを更新します
8. 検証を徹底する - 完了前にチェックを実行します

完了時の状態クリーンアップ

重要：完了時に状態ファイルを削除してください。active: false に設定するだけではいけません

パイプラインが完了したとき（すべてのステージが完了したとき、またはキャンセルされたとき）：

# Delete pipeline state file
rm -f .omc/state/pipeline-state.json

これにより、今後のセッションで状態をクリーンに保てます。active: false の古い状態ファイルを残さないでください。

スキルの呼び出し

このスキルは次の場合に有効になります：

• ユーザーが /pipeline コマンドを入力したとき
• ユーザーが「agent chain」、「workflow」、「pipe agents」と言及したとき
• 「X then Y then Z」とエージェント名を含むパターンを検出したとき

明示的な呼び出し：

/oh-my-claudecode:pipeline review "task"

自動検出：

"First explore the codebase, then architect should analyze it, then executor implements"

→ パイプラインを自動的に作成します：explore → architect → executor