mcpField
W
workflow-orchestration

workflow-orchestration

github.com/vxcozyエージェントワークフロー117252 回インストール27 週間前に更新
リポジトリ

workflow-orchestration について

workflow-orchestrationは、計画、作業分担、検証、修正からの学習を通じて複雑な作業を整理するエージェント向けスキルです。実装とレビューのタスク管理方法も示します。

主な機能

  1. 01確認可能な手順で計画
  2. 02調査や並行分析の分担
  3. 03修正後の教訓の記録
  4. 04完了前の結果検証
  5. 05進捗管理とレビュー記録

活用シーン

  1. 01複数段階の実装作業の計画
  2. 02サブエージェントへの調査分担
  3. 03検証失敗後のタスク再計画
  4. 04繰り返すミスや教訓の記録

インストール

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

$npx skills add https://github.com/vxcozy/workflow-orchestration --skill workflow-orchestration

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

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

LICENSE
.gitignore
README.md
docs/
explanation.md
howto.md
tutorial.md
references/
task-templates.md
lessons-format.md
REFERENCE.md

詳細

ワークフローオーケストレーション

規律を保ち、高品質にタスクを実行するために、以下のプラクティスを適用してください。

クイックリファレンス

プラクティス適用するタイミング
プランモード3 ステップ以上のタスク、またはアーキテクチャ上の判断が必要なタスク
サブエージェント調査、探索、並行分析
教訓ユーザーから修正を受けた後は必ず
検証タスクを完了とする前
エレガンスチェック自明でない変更のみ

1. デフォルトでプランモードを使う

  • 自明でないタスク（3 ステップ以上、またはアーキテクチャ上の判断が必要なタスク）では、必ずプランモードに入ります
  • 何か問題が起きたら、作業を中断してすぐに再計画します
  • プランモードは、実装だけでなく検証のステップにも使用します
  • 曖昧さを減らすため、最初に詳細な仕様を書きます

2. サブエージェント戦略

メインのコンテキストウィンドウをすっきり保ちます。

  • 調査、探索、並行分析はサブエージェントに任せます
  • 複雑な問題では、サブエージェントを使って計算資源を増やします
  • 集中して実行できるよう、サブエージェントごとにタスクを 1 つ割り当てます

テンプレート：

Agent({
  description: "Search auth patterns",
  prompt: "Find all authentication middleware in src/ and list file paths with a one-line summary of each."
})

3. 自己改善ループ

ユーザーから修正を受けた後は、必ず次の対応を行います。

  1. tasks/lessons.md にパターンを記録します
  2. 同じ間違いを防ぐルールを書きます
  3. セッション開始時に教訓を確認します

インラインの例（完全なテンプレートは references/lessons-format.md を参照してください）：

## 2024-01-10 - Testing
**Mistake**: Mocks hid real API behavior; production broke
**Pattern**: Over-mocking created false confidence
**Rule**: Include at least one integration test hitting real services
**Applied**: All API endpoints, external service integrations

4. 完了前に検証する

  • 動作を確認せずにタスクを完了としてはいけません
  • 該当する場合は、main と変更内容の動作を比較します
  • 「スタッフエンジニアなら承認するだろうか？」と自問します
  • テストを実行し、ログを確認し、修正内容を実証します
  • 検証に失敗したら、再試行する前にプランのステップに戻って修正します

5. エレガンスを追求する（バランスよく）

  • 自明でない変更では、いったん立ち止まり、「もっとエレガントな方法はないか」と考えます
  • 修正がその場しのぎに感じられたら、「今知っていることをすべて踏まえて、エレガントな解決策を実装する」と考えます
  • 単純で明白な修正では、この手順を省き、過剰に設計しないようにします

6. 自律的なバグ修正

  • バグ報告を受けたら、手取り足取りの指示を求めずに修正します
  • ログ、エラー、失敗したテストを確認し、問題を解決します
  • ユーザーにコンテキスト切り替えを求めません

タスク管理プロトコル

  1. 最初に計画する：チェック項目を tasks/todo.md に記述します
  2. 計画を確認する：実装を始める前に確認を取ります
  3. 進捗を記録する：作業を進めながら項目を完了にします
  4. 変更を説明する：各ステップで概要を説明します
  5. 結果を検証する：完了とする前にテストを実行し、動作を確認します
  6. 失敗に対処する：検証に失敗したら、無理に進めず再計画します（ステップ 1）
  7. 結果を記録する：レビューを tasks/todo.md に追加します
  8. 教訓を記録する：修正を受けた後は tasks/lessons.md を更新します

インラインの例（完全なテンプレートは references/task-templates.md を参照してください）：

# Task: Fix memory leak in WebSocket handler
## Plan
- [ ] Reproduce the issue locally
- [ ] Identify leak source with profiler
- [ ] Implement fix
- [ ] Verification: Memory stable over 1000 connections

基本原則

  • シンプルさを第一に：変更はすべて、可能な限りシンプルにします
  • 怠惰にならない：根本原因を見つけます。一時しのぎの修正はしません。シニア開発者としての基準を守ります
  • 影響を最小限に：必要な箇所だけを変更し、バグの混入を避けます

コメント

Markdown 対応