Workflow Expert

ワークフローとマルチエージェント連携の設計を支援するスキルです。

目的

このスキルは以下を提供します：

• •ワークフロー設計原則: 複雑なタスクをPhase構造に分解する原則
• •マルチエージェント連携パターン: エージェント間の責務分担と連携の5パターン
• •スキル連携設計: スキルプリロードとデータフローの設計

いつ使用するか

プロアクティブ使用

1. •

   新しいコマンドの設計

   • •複数ステップを持つコマンドを新規作成する
   • •複数エージェントが連携する処理を設計する
2. •

   既存ワークフローの改善

   • •コマンドやエージェントの効率化が必要
   • •エラーハンドリングの強化が必要
3. •

   システム設計の議論

   • •「〜の処理フローを設計して」
   • •「〜を自動化したい」

明示的な使用

• •/workflow-expert コマンド
• •「ワークフローを設計して」などの直接的な要求

プリロード使用

以下のエージェントにプリロードされます：

---
name: command-expert
skills:
  - workflow-expert
---

ワークフロー設計原則

1. Phase設計原則

Phase 0 → Phase 1 → Phase 2 → Phase 3 → ...

各Phaseに以下を明確に定義すること：

2. エージェント連携原則

3. エラーハンドリング原則

4. ユーザーインタラクション原則

マルチエージェント連携パターン

パターン1: シーケンシャル（パイプライン）

ステージ1 → ステージ2 → ステージ3 → ステージ4

適用ケース: 依存関係が線形、各ステップが前のステップに依存

実装例: /new-project (パッケージモード)

prd-writing → functional-design → architecture-design → repository-structure → development-guidelines → glossary → task-decomposer

特徴:

• •各ステージの出力が次ステージの入力
• •失敗時は前ステージに戻ってリトライ
• •依存関係が明確で理解しやすい

パターン2: ファンアウト/ファンイン（並列）

        ┌── ワーカーA ──┐
データ ─┼── ワーカーB ──┼─ 集約
        └── ワーカーC ──┘

適用ケース: 独立した処理が複数存在、効率化が必要

実装例: /collect-finance-news

オーケストレーター(データ準備)
    │
    ├── finance-news-index ─────┐
    ├── finance-news-stock ─────┤
    ├── finance-news-sector ────┼── 結果サマリー
    ├── finance-news-macro ─────┤
    ├── finance-news-ai ────────┤
    └── finance-news-finance ───┘

特徴:

• •独立した処理を並列実行（50%以上の時間短縮）
• •各ワーカーは同じ入力データを受け取る
• •結果を集約して報告

パターン3: オーケストレーター + ワーカー

オーケストレーター
├── Phase制御
├── ワーカー並列起動
│   ├── ワーカーA
│   ├── ワーカーB
│   └── ワーカーC
└── 結果集約・エラーリカバリー

適用ケース: 複雑なPhase制御が必要、エラーリカバリーが重要

実装例: test-orchestrator

test-orchestrator
├── test-planner → テスト設計
├── 並列実行
│   ├── test-unit-writer
│   └── test-property-writer
└── test-integration-writer → 統合テスト

オーケストレーターの種類:

パターン4: ルーター + 専門家

入力 → ルーター → 専門家A
              → 専門家B
              → 専門家C

適用ケース: 入力に応じて処理を分岐

実装例: /issue-implement

Issue情報 → タイプ判定 → python → Phase 1-5 (Python ワークフロー)
                     → agent → Phase A1-A4 (Agent ワークフロー)
                     → command → Phase C1-C4 (Command ワークフロー)
                     → skill → Phase S1-S4 (Skill ワークフロー)

特徴:

• •入力に基づいて適切な処理パスを選択
• •各専門家は特定ドメインに特化
• •判定ロジックは AskUserQuestion でユーザー確認可能

パターン5: 批評・修正ループ

初稿生成 → 批評（並列）→ 修正 → 最終確認
              ├── 批評A
              ├── 批評B
              └── 批評C

適用ケース: 品質保証が重要、複数観点からの検証が必要

実装例: /finance-edit

finance-article-writer → 批評エージェント群 → finance-reviser
                            ├── fact（事実確認）
                            ├── compliance（コンプライアンス）
                            ├── structure（構成）
                            ├── data（データ検証）
                            └── readability（可読性）

特徴:

• •異なる観点からの並列批評
• •批評結果を統合して修正
• •品質スコアによる判定

スキル連携パターン

skills: フィールドによるプリロード

エージェントのフロントマターで skills: を指定すると、スキルの完全なコンテンツがコンテキストに注入されます。

---
name: feature-implementer
skills:
  - coding-standards
  - tdd-development
  - error-handling
allowed-tools: Read, Edit, Bash, Grep, Task
---

# 機能実装エージェント

プリロードされたスキルの規約とパターンに従って実装してください。

重要な特性:

• •スキル名のリスト形式（配列）で指定
• •各スキルの完全なコンテンツがコンテキストに注入される
• •サブエージェントは親の会話からスキルを継承しない - 明示的にリストする必要がある

スキル設計のベストプラクティス

プロセス

0. Sequential Thinking による段階的計画（必須）

ワークフロー設計では、必ず Sequential Thinking を使用して段階的に計画します。

# MCP ツール: mcp__sequential-thinking__sequentialthinking
thought: "現在の思考ステップ"
thoughtNumber: 1
totalThoughts: 6  # 予想思考数（調整可能）
nextThoughtNeeded: true

推奨思考フロー:

Thought 1: 要件の分析（目的、入力、出力、制約）
Thought 2: パターン候補の検討（各パターンの適合性評価）
Thought 3: パターン選択と理由（選択根拠の明確化）
Thought 4: Phase 構造の設計（各Phaseの入出力定義）
Thought 5: エージェント割り当て（責務分担）
Thought 6: 仮説の検証と最終確認

詳細な使用例は ./guide.md の「Sequential Thinking による段階的計画」を参照。

1. 要件分析

ワークフロー設計前に以下を確認：

# 既存の類似ワークフローを調査
ls -la .claude/commands/
cat .claude/commands/similar-workflow.md

確認項目:

• •処理の目的: 何を達成したいか
• •入力/出力: 何を受け取り、何を生成するか
• •制約: 時間、リソース、依存関係
• •並列化可能性: 独立した処理はあるか

2. パターン選択

要件に基づいて適切なパターンを選択：

3. Phase設計

各Phaseを詳細に定義：

## Phase N: [Phase名]

### 入力
- [入力データ1]
- [入力データ2]

### 処理内容
1. [処理ステップ1]
2. [処理ステップ2]

### 出力
- [成果物1]
- [成果物2]

### 完了条件
- [ ] [検証項目1]
- [ ] [検証項目2]

### エラーハンドリング
| エラー | 対処 |
|--------|------|
| [エラー1] | [対処法1] |

4. エージェント設計

各エージェントに以下を定義：

• •責務（単一責任）
• •入力/出力
• •使用ツール
• •スキル参照（skills: フィールド）

リソース

このスキルには以下のリソースが含まれています：

./guide.md

ワークフロー設計の詳細ガイド:

• •ワークフロー設計手順（8ステップ）
• •スキル連携パターン（静的/動的/カスケード/リソース参照）
• •オーケストレーション設計（軽量/完全オーケストレーター）
• •エラーハンドリングパターン（リトライ/フォールバック/部分成功/ロールバック/エスカレーション）
• •品質チェックリストとトラブルシューティング

使用例

例1: Issue自動実装ワークフローの設計

状況: GitHub Issueから自動的にコードを実装してPRを作成したい

処理:

1. •パターン選択: シーケンシャル + ルーター（開発タイプ分岐）
2. •Phase設計:
   • •Phase 0: Issue検証・タイプ判定
   • •Phase 1-5: Python ワークフロー（テスト作成→実装→品質保証→PR作成→完了処理）
   • •Phase A1-A4: Agent ワークフロー
   • •Phase C1-C4: Command ワークフロー
   • •Phase S1-S4: Skill ワークフロー
3. •エージェント設計: test-writer, feature-implementer, quality-checker, code-simplifier

出力: /issue-implement コマンド

## Phase 2: 実装

### 入力
- Issue情報
- Red状態のテストファイル

### 処理内容
1. feature-implementer でTDDサイクル実行
2. 各タスク完了時にIssueチェックボックス更新

### 完了条件
- [ ] 全タスクが実装されている
- [ ] make test で Green（成功）状態
- [ ] Issue のチェックボックスが全て [x] に更新

例2: 金融ニュース収集ワークフローの設計

状況: 複数テーマのニュースを並列収集してGitHub Projectに投稿したい

処理:

1. •パターン選択: オーケストレーター + ファンアウト/ファンイン
2. •Phase設計:
   • •Phase 0: 初期化（RSS取得、既存Issue取得）
   • •Phase 1: テーマ別収集（6エージェント並列）
   • •Phase 2: 結果報告
3. •エージェント設計:
   • •軽量オーケストレーター（セッション準備のみ）
   • •6テーマエージェント（index, stock, sector, macro, ai, finance）

出力: /collect-finance-news コマンド

## Phase 1: テーマ別収集

### 並列実行
Task tool で以下を同時起動:
- finance-news-index
- finance-news-stock
- finance-news-sector
- finance-news-macro
- finance-news-ai
- finance-news-finance

### データ渡し（重要）
各エージェントに完全なRSSデータをJSON形式で渡す:
```json
{
  "articles": [...],
  "existing_issues": [...],
  "config": {...}
}

---

### 例3: 記事執筆ワークフローの設計

**状況**: リサーチ→批評→修正のサイクルで高品質な記事を作成したい

**処理**:
1. パターン選択: パイプライン + 批評・修正パターン
2. Phase設計:
   - Phase 1: リサーチ（4データ収集エージェント並列）
   - Phase 2: 初稿作成
   - Phase 3: 批評（5批評エージェント並列）
   - Phase 4: 修正
   - Phase 5: 最終確認
3. HFポイント設計:
   - トピック承認
   - 主張採用確認
   - 初稿レビュー
   - 最終確認

**出力**: `/finance-full` コマンド

```markdown
## Phase 3: 批評

### 並列実行
- finance-critic-fact（事実確認）
- finance-critic-compliance（コンプライアンス）
- finance-critic-structure（構成）
- finance-critic-data（データ検証）
- finance-critic-readability（可読性）

### 集約
批評結果を統合し、改善が必要な項目をリスト化

例4: テスト作成ワークフローの設計

状況: 単体テスト・プロパティテスト・統合テストを効率的に作成したい

処理:

1. •パターン選択: オーケストレーター + ワーカー（一部並列）
2. •Phase設計:
   • •Phase 1: テスト設計（test-planner）
   • •Phase 2: 並列テスト作成（unit & property）
   • •Phase 3: 統合テスト作成（integration）
3. •依存関係:
   • •単体テストとプロパティテストは並列実行可能
   • •統合テストは単体テスト完了後に実行

出力: test-orchestrator エージェント

Phase 1: test-planner
    │
Phase 2: 並列実行
    ├── test-unit-writer
    └── test-property-writer
    │
Phase 3: test-integration-writer

品質基準

必須（MUST）

• • Phase間の依存関係が明確に定義されている
• • 各エージェントの責務が単一である
• • エラーハンドリングが各Phaseに定義されている
• • 完了条件がチェックリスト形式で記載されている

推奨（SHOULD）

• •並列実行可能な処理は並列化する
• •重要な決定点にHFポイントを設置する
• •サブエージェントへのデータ渡しは完全なJSON形式

完了条件

このスキルによるワークフロー設計は以下の条件を満たした場合に完了：

• • 適切なワークフローパターンが選択されている
• • Phase構造が設計されている
• • エージェント間の責務分担が明確
• • データフローが定義されている
• • エラーハンドリングが考慮されている
• • HFポイントが適切に配置されている

関連スキル

• •agent-expert: エージェント単体の設計
• •skill-expert: スキル単体の設計
• •command-expert: コマンドの設計

参考資料

• •CLAUDE.md: プロジェクト全体のガイドライン
• •.claude/rules/subagent-data-passing.md: サブエージェントへのデータ渡しルール
• •.claude/commands/issue-implement.md: シーケンシャル + ルーターパターンの実装例
• •.claude/commands/collect-finance-news.md: ファンアウト/ファンインパターンの実装例
• •.claude/commands/finance-full.md: 批評・修正パターンの実装例
• •.claude/agents/test-orchestrator.md: オーケストレーターパターンの実装例