mcpField
P
parallel-task-spark

parallel-task-spark

github.com/am-willエージェントワークフロー1.0k1.1k 回インストール15 週間前に更新
リポジトリ

parallel-task-spark について

parallel-task-sparkは、Markdown計画のタスクをSparkyサブエージェントに割り当てる開発者向けのオーケストレーションスキルです。依存関係に基づいて並列実行の波を組み、完了ログを計画に記録します。

主な機能

  1. 01Markdown計画からタスクと依存関係を解析
  2. 02未ブロックのタスクを波状に並列実行
  3. 03結果と検証証拠を確認
  4. 04コミットと計画ログを完了条件に設定

活用シーン

  1. 01複数タスクを含む開発計画の実行
  2. 02依存関係に沿ったタスク subset の実行
  3. 03計画ファイルで検証済みの完了状況を追跡

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/am-will/codex-skills --skill parallel-task-spark

インストール後、Claude Code で/parallel-task-sparkを入力して読み込まれたか確認します。

詳細

並列タスク実行ツール(Sparky)

あなたはサブエージェントのオーケストレーターです。オーケストレーションモードを使用して計画ファイルを解析し、タスクの依存関係に基づいて、すべてのタスクが完了するまでループしながら、並列で動作する Sparky サブエージェントにタスクを委任します。あなたの役割は、サブエージェントが正しい順序(ウェーブ)で起動され、タスクを正しく完了することを確認し、各タスクの完了後に計画ドキュメントがログで更新されるようにすることです。

プロセス

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

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

  1. 計画ファイル:読み込む Markdown 計画
  2. タスクのサブセット(任意):実行する特定のタスク ID

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

ステップ 2:計画を読み込んで解析する
  1. タスクの小見出しを探します(例:### T1: または ### Task 1.1:)
  2. 各タスクについて、以下を抽出します。
    • タスク ID と名前
    • depends_on リスト(- **depends_on**: [...] から)
    • 全内容(説明、場所、受け入れ基準、検証)
  3. タスクリストを作成します
  4. タスクのサブセットがリクエストされた場合は、タスクリストをその ID と必要な依存関係のみに絞り込みます。
ステップ 3:サブエージェントを起動する

ブロックされていない各タスクについて、以下を指定してサブエージェントを起動します。

  • agent_type:sparky(Sparky ロール)
  • description:"Implement task [ID]: [name]"
  • prompt:以下のテンプレートを使用

ブロックされていないタスクはすべて並列で起動し、Sparky ロールのサブエージェントのみを使用します。depends_on リスト内のすべての ID が完了していれば、そのタスクはブロックされていません。

すべての起動で agent_type: sparky を指定する必要があります。このスキルでは、他のロールは無効です。

タスクプロンプトのテンプレート
You are implementing a specific task from a development plan.

## Context
- Plan: [filename]
- Goals: [relevant overview from plan]
- Dependencies: [prerequisites for this task]
- Related tasks: [tasks that depend on or are depended on by this task]
- Constraints: [risks from plan]

## Your Task
**Task [ID]: [Name]**

Location: [File paths]
Description: [Full description]

Acceptance Criteria:
[List from plan]

Validation:
[Tests or verification from plan]

## Instructions
- Use the `sparky` agent role for this task; do not use any other role.
1. Read the working plan and fully understand this task before coding.
2. Read all relevant files first, then do targeted codebase research (related modules, tests, call sites, and dependencies) to confirm the approach.
3. Default to TDD RED phase first using a `tdd_test_writer` subagent:
   - Pass task context and acceptance criteria.
   - Require tests-only edits.
   - Require command output proving the new/updated tests fail for the expected behavior gap.
   - If the task is not a good TDD candidate, explicitly record `reason_not_testable` and define alternative verification evidence (for example `manual_check`, `static_check`, or `runtime_check`) with an exact command or concrete validation steps.
4. Review RED-phase tests (or approved non-testable verification plan) as the implementation contract. Do not weaken or remove tests unless requirements changed.
5. Implement production changes for all acceptance criteria.
6. Run validation:
   - For testable tasks, run the exact new/updated test command(s) until GREEN (passing).
   - For non-testable tasks, run the agreed alternative verification and capture evidence.
   - Run any additional validation steps from the plan if feasible.
7. Commit your work.
   - Stage only files for this task because other agents are working in parallel.
   - NEVER PUSH. ONLY COMMIT.
8. After the commit, update the `*-plan.md` task entry with:
   - Completion status
   - Concise work log
   - Files modified/created
   - Errors or gotchas encountered
9. Return summary of:
   - Files modified/created
   - Changes made
   - How criteria are satisfied
   - Verification evidence: RED -> GREEN or documented non-testable alternative
   - Validation performed or deferred

## Important
- Be careful with paths
- Stop and describe blockers if encountered
- Focus on this specific task

RED → GREEN のテスト証拠、またはテスト不可能であることを明示的に確認した証拠のいずれかが提示され、タスクがコミットされ、計画が更新されるまでは、タスクを完了と見なさないでください。

ステップ 4:確認と検証

サブエージェントが作業を完了した後、以下を行います。

  1. 出力が正確かつ完全であることを確認します。
  2. 期待される結果に照らして成果を検証します。
  3. タスクが正しく完了している場合は、タスクのコミットが存在することを確認し、タスクがログ付きで完了としてマークされていることも確認します。
  4. タスクが成功していない場合は、エージェントに再試行させるか、問題をエスカレーションします。
  5. 次のウェーブのタスクに進む前に、作業ウェーブがローカルでコミットされていることを確認します。
ステップ 5:繰り返す
  1. 計画を再確認し、新たにブロックされていないタスクのセットを確認します。
  2. 計画が完了するまで、ブロックされていないタスクを並列で起動し続けます。
  3. すべてのタスクがエラーなく完了し、検証(RED → GREEN、またはテスト不可能であることを記録した検証)が行われ、コミットされ、ログに記録されるまで、このプロセスを繰り返します。

エラー処理

  • タスクのサブセットが見つからない場合:利用可能なタスク ID を一覧表示します
  • 解析に失敗した場合:試した内容を示し、説明を求めます

使用例

'Implement the plan using parallel task skill'
/parallel-task-spark plan.md
/parallel-task-spark ./plans/auth-plan.md T1 T2 T4
/parallel-task-spark user-profile-plan.md --tasks T3 T7

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

# Execution Summary

## Tasks Assigned: [N]

### Completed
- Task [ID]: [Name] - [Brief summary]

### Issues
- Task [ID]: [Name]
  - Issue: [What went wrong]
  - Resolution: [How resolved or what's needed]

### Blocked
- Task [ID]: [Name]
  - Blocker: [What's preventing completion]
  - Next Steps: [What needs to happen]

## Overall Status
[Completion summary]

## Files Modified
[List of changed files]

## Next Steps
[Recommendations]

コメント