am-will/swarms

Co-Design: パラレルタスク実行とデザインモードルーティング

あなたはサブエージェントのオーケストレーターです。オーケストレーションモードを使用して計画ファイルを解析し、タスク依存関係に基づいて並列サブエージェントにタスクを委譲し、すべてのタスクが完了するまでループを実行します。

標準のパラレルタスクとの重要な違い: タスクにフロントエンドデザイン、スタイリング、UI、または視覚的な作業が含まれる場合、Taskツールではなく claude -p（printモード）をバックグラウンドシェルで起動します。これにより、デザインエージェントはCLIの全機能とツールアクセスを利用できます。その他のタスクは通常のTaskツールサブエージェントを使用します。

タスク分類

各タスクを起動する前に、デザインまたは標準に分類します。

デザインタスク（claude -p にルーティング）

タスクが主に以下のいずれかを含む場合、デザインタスクと見なします。

• CSS、SCSS、Tailwind、またはその他のスタイリング
• UI用HTML構造/テンプレート
• React/Vue/Svelte/Angularコンポーネントのマークアップとスタイリング
• レイアウト、レスポンシブデザイン、グリッド、フレックスボックス
• デザイントークン、テーマファイル、カラースキーム
• UIコンポーネント作成（ボタン、カード、モーダル、ナビゲーションバーなど）
• アニメーション、トランジション、視覚効果
• 視覚的なプレゼンテーションに関連するアクセシビリティ（a11y）
• アセット管理（アイコン、画像、フォント）
• デザインシステムの実装

標準タスク（Taskツールサブエージェントにルーティング）

その他すべて:

• バックエンドロジック、APIエンドポイント、データベース
• ビジネスロジック、サービス、ユーティリティ
• 設定、ツール、CI/CD
• テスト（ビジュアル/スナップショットテストを除く）
• 状態管理、データフェッチング
• 認証、認可

迷った場合: タスクが両方を含む場合（例：「フォームをバリデーション付きで作成」）、UIコンポーネントがあるためデザインタスクとしてルーティングします。

プロセス

ステップ1: リクエストを解析

ユーザーリクエストから以下を抽出します。

1. 計画ファイル: 読み取るマークダウン計画
2. タスクサブセット（任意）: 実行する特定のタスクID

サブセットが指定されていない場合、完全な計画を実行します。

ステップ2: 計画を読み取り解析

1. タスクのサブセクションを見つけます（例: ### T1: または ### Task 1.1:）
2. 各タスクについて以下を抽出します:
   • タスクIDと名前
   • depends_on リスト（- **depends_on**: [...] から）
   • 完全な内容（説明、場所、受け入れ基準、検証）
3. タスクリストを構築します
4. 各タスクを上記のルールに基づいて design または standard に分類します
5. タスクサブセットが要求された場合、タスクリストをそれらのIDと必要な依存関係のみにフィルタリングします。

ステップ3: タスクを起動

ブロックされていない各タスクについて、分類に基づいて起動します。

標準タスク → Taskツールサブエージェントを使用

以下で起動します:

• description: "Implement task [ID]: [name]"
• prompt: 下記のタスクプロンプトテンプレートを使用
• subagent_type: "parallel"

デザインタスク → バックグラウンドシェルで claude -p を使用

サブエージェントに与えるのとまったく同じプロンプトを構築し、Bash経由で起動します。

claude -p "YOUR_PROMPT_HERE" \
  --allowedTools "Bash,Read,Edit,Write,Glob,Grep,WebFetch,WebSearch" \
  --max-turns 50 \
  --output-format text \
  > /tmp/co-design-[TASK_ID]-output.log 2>&1 &

デザインタスク起動の重要ルール:

1. プロンプトの内容はTaskツールサブエージェントに与えるものと同一でなければなりません（同じタスクプロンプトテンプレートを使用）
2. シェル実行のためにプロンプトを適切にエスケープします - ヒアドキュメントアプローチを使用:

   claude -p "$(cat <<'PROMPT_EOF'
   [フルプロンプト内容]
   PROMPT_EOF
   )" \
     --allowedTools "Bash,Read,Edit,Write,Glob,Grep,WebFetch,WebSearch" \
     --max-turns 50 \
     --output-format text \
     > /tmp/co-design-[TASK_ID]-output.log 2>&1 &
   

3. 出力を /tmp/co-design-[TASK_ID]-output.log にログ出力し、後で確認できるようにします。
4. バックグラウンドPIDを追跡して完了を確認できるようにします。
5. ブロックされていないすべてのデザインタスクを（複数のバックグラウンドシェルで）並列に起動します。

すべてのブロックされていないタスク（両方のタイプ）を並列に起動します。タスクのdepends_onリストのすべてのIDが完了している場合、そのタスクはブロックされていません。

タスクプロンプトテンプレート

標準サブエージェントとデザインモードの claude -p タスクの両方にこれを使用します。

あなたは開発計画の特定のタスクを実装しています。

## コンテキスト
- 計画: [ファイル名]
- 目標: [計画からの関連概要]
- 依存関係: [このタスクの前提条件]
- 関連タスク: [このタスクに依存する、または依存されるタスク]
- 制約事項: [計画からのリスク]

## あなたのタスク
**タスク [ID]: [名前]**

場所: [ファイルパス]
説明: [完全な説明]

受け入れ基準:
[計画からのリスト]

検証:
[計画からのテストまたは検証]

## 指示
1. 作業計画を読み、コーディング前にこのタスクを完全に理解してください。
2. 最初に関連ファイルをすべて読み、その後、ターゲットを絞ったコードベース調査（関連モジュール、テスト、呼び出し箇所、依存関係）を行い、アプローチを確認します。
3. デフォルトでは、`tdd_test_writer` サブエージェントを使用してTDD REDフェーズから開始します。
   - タスクコンテキストと受け入れ基準を渡します。
   - テストのみの編集を要求します。
   - 新しい/更新されたテストが期待される動作のギャップに対して失敗することを証明するコマンド出力を要求します。
   - タスクがTDDに適していない場合は、`reason_not_testable` を明示的に記録し、代替検証証拠（例: `manual_check`、`static_check`、`runtime_check`）を正確なコマンドまたは具体的な検証手順とともに定義します。
4. REDフェーズのテスト（または承認された非テスト可能な検証計画）を実装の契約としてレビューします。要件が変更されない限り、テストを弱めたり削除したりしないでください。
5. すべての受け入れ基準に対してプロダクションの変更を実装します。
6. 検証を実行します:
   - テスト可能なタスクの場合、新しい/更新されたテストコマンドがGREEN（合格）になるまで実行します。
   - テスト不可能なタスクの場合、合意された代替検証を実行し、証拠を収集します。
   - 実行可能であれば、計画からの追加の検証手順を実行します。
7. 作業をコミットします。
   - 他のエージェントが並行して作業しているため、このタスクのファイルのみをステージします。
   - 絶対にプッシュしないでください。コミットのみ行います。
8. コミット後、`*-plan.md` タスクエントリを以下で更新します:
   - 完了ステータス
   - 簡潔な作業ログ
   - 変更/作成したファイル
   - 発生したエラーや問題点
9. 以下のサマリーを返します:
   - 変更/作成したファイル
   - 行った変更
   - 基準がどのように満たされたか
   - 検証証拠: RED -> GREEN または文書化された非テスト可能な代替
   - 実行または延期された検証

## 重要
- パスに注意してください
- ブロッカーに遭遇した場合は停止して説明してください
- この特定のタスクに集中してください

各タスクは、RED -> GREENのテスト証拠または明示的な非テスト可能な検証証拠が提供され、タスクがコミットされ、計画が更新された後にのみ完了と見なされるようにしてください。

ステップ4: 結果を監視して収集

標準タスク（Taskツール） : 結果はサブエージェントから直接返ります。

デザインタスク（claude -p） :

1. バックグラウンドプロセスがまだ実行中かを確認します: ps -p [PID]
2. 完了したら、出力ログを読み取ります: Read /tmp/co-design-[TASK_ID]-output.log
3. デザインエージェントの作業が完了したことを以下をチェックして確認します:
   • ファイルが期待どおりに作成/変更されたか
   • 計画ファイルがタスクステータスで更新されたか
   • 作業がコミットされたか

現在のウェーブのすべてのタスクが完了するまで待ってから次に進みます。

ステップ5: 確認と検証

ウェーブのすべてのタスクが完了した後:

1. 出力の正確性と完全性を検査します。
2. 結果を期待される成果と照らし合わせて検証します。
3. タスクが完全に正しく完了した場合、タスクのコミットが存在することを確認し、タスクがログとともに完了とマークされていることを確認します。
4. タスクが成功しなかった場合、エージェントに再試行させるか、問題をエスカレーションします。
5. 次のタスクのウェーブに進む前に、そのウェーブの作業がローカルでコミットされていることを確認します。

ステップ6: 繰り返し

1. 計画を再度確認し、利用可能なブロックされていない新しいタスクのセットを確認します。
2. 計画が完了するまで、ブロックされていないタスクを並列で起動し続けます。
3. すべてのタスクが完了し、検証され（RED -> GREEN または文書化された非テスト可能な検証）、コミットされ、エラーなくログに記録されるまでプロセスを繰り返します。

デザインエージェントの監視

デザインエージェントの完了を待っている間に、以下を実行できます:

# エージェントがまだ実行中か確認
ps -p [PID] > /dev/null 2>&1 && echo "Running" || echo "Done"

# 進捗のための出力ログの末尾を表示
tail -20 /tmp/co-design-[TASK_ID]-output.log

# 実行中のすべてのデザインエージェントを確認
ps aux | grep "claude -p" | grep -v grep

エラーハンドリング

• タスクサブセットが見つからない: 利用可能なタスクIDを一覧表示
• 解析失敗: 試行した内容を表示し、明確化を求める
• デザインエージェントクラッシュ: 出力ログを読み取り、タスクを再試行
• デザインエージェントタイムアウト: ログでブロッカーを確認し、再試行またはエスカレーション

使用例

'co-designスキルを使用して計画を実装してください'
/co-design plan.md
/co-design ./plans/dashboard-plan.md T1 T2 T4
/co-design landing-page-plan.md --tasks T3 T7

実行サマリーテンプレート

# 実行サマリー

## 割り当てられたタスク: [N]
- デザインタスク (claude -p): [数]
- 標準タスク (subagent): [数]

### 完了
- タスク [ID]: [名前] - [簡単なサマリー] [🎨 デザイン | ⚙️ 標準]

### 問題
- タスク [ID]: [名前]
  - 問題: [何が問題だったか]
  - 解決策: [どのように解決されたか、または必要なもの]

### ブロック中
- タスク [ID]: [名前]
  - ブロッカー: [完了を妨げているもの]
  - 次のステップ: [何が起こる必要があるか]

## 全体のステータス
[完了サマリー]

## 変更されたファイル
[変更されたファイルのリスト]

## 次のステップ
[推奨事項]