mcpField
W
workflow-orchestrator

workflow-orchestrator

github.com/zhnnky329エージェントワークフロー1.1k35 回インストール5 週間前に更新
リポジトリ

workflow-orchestrator について

workflow-orchestratorは、研究プロジェクトの状態を読み取り、ゲートに沿って次の作業を割り当てるスキルです。正規の成果物から小問ごとの進捗を評価し、leanとsubmissionの要件を区別して次の主要アクションを示します。

主な機能

  1. 01正規の成果物から状態を読み取り
  2. 02小問ごとにゲートを評価
  3. 03JSONマニフェストを管理
  4. 04変更影響に応じて確認を割り当て
  5. 05leanとsubmissionの要件を区別

活用シーン

  1. 01プロジェクトのゲートと阻害要因の確認
  2. 02手法・コード・結果レビューの割り当て
  3. 03変更後に必要な確認範囲の決定

インストール

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

$npx skills add https://github.com/zhnnky329/mathmodeling-skills --skill workflow-orchestrator

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

詳細

目的

ゲート駆動型のスケジューラーおよび状態リーダーとして動作します。モデルを解いたり、モデルコードを書いたり、論文のセクションを作成したりしないでください。

../../AGENTS.md は同梱されているポリシーの参照元です。プロジェクトルートに AGENTS.md がある場合は、そちらを優先してください。ない場合は、この SKILL.md からの相対パスで同梱版を読み込んでください。大量のレポートやダッシュボードを再掲せず、そのポリシーを適用してください。

セッション開始

新しいワークスペースでオーケストレーションを開始する前に、次を実行してください。

  • git status --short を表示します。
  • 選択したランタイムと必須のコアパッケージを確認します。
  • 現在のリクエストに必要なワークスペースの骨組みを検証します。
  • planning/session_config.json を読み込み、レガシーの mode も受け入れます。

警告は簡潔に報告してください。ユーザーがプロジェクトを初期化する場合を除き、プロジェクトの骨組み全体を作成しないでください。

状態の参照元

次の順に優先してください。

  1. planning/manifests/Qx.json
  2. ディスク上の正規の成果物
  3. レガシーのダッシュボードおよびレガシーのメソッド/判断成果物

新しい正規の成果物よりも、ダッシュボードを信用しないでください。

マニフェストの契約

サブクエスチョンごとに、次の簡潔な JSON マニフェストを 1 つ管理します。

{
  "schema_version": 1,
  "question_id": "Q1",
  "rigor_profile": "lean",
  "current_gate": "G2",
  "status": "method_screened_waiting_human",
  "artifacts": {
    "method_card": "methods/Q1/q1_method_card.md",
    "decision_ledger": "methods/Q1/q1_decisions.jsonl",
    "risk_probe": "methods/Q1/probes/risk_probe_summary.json",
    "latest_run": null
  },
  "allowed": {
    "code_generation": false,
    "freeze": false,
    "paper_writing": false,
    "final_assembly": false
  },
  "blockers": [],
  "next_action": {
    "owner": "human",
    "skill": "decision-prompt-builder",
    "reason": "method choice not recorded"
  },
  "updated_at": "ISO-8601"
}

現在の状態変化の影響を受けるフィールドのみを更新してください。人間向けのダッシュボードは、リクエスト時またはマイルストーン時に生成してください。それ以外の場合は、マニフェストから直接ステータスを導き出してください。

ゲート評価

各 Qx を個別に評価してください。

G1 — PROBLEM_FRAMED

解析、分類、データの棚卸し、成功基準、人によるフレーミングが揃っている場合に合格です。人間が入力するフィールドのプレースホルダーは、ゲートをブロックします。

G2 — METHOD_SCREENED

次の条件を満たす場合に合格です。

  • qx_method_card.md で、主要候補と利用可能なベースラインが定義されている。
  • ベースラインが実際のタスクを、比較可能な出力で完了している。
  • risk_probe_summary.json が、該当するチェック(出力の縮退を含む)を網羅している。
  • 主要候補とベースラインの判定が PASS、または妥当な根拠を伴う CONDITIONAL である。
  • フォールバックがある場合、具体的な発動条件が定められている。

候補数の固定、すべての概念実証(PoC)、ソース行数の上限は必須ではありません。

G2.5 — METHOD_CHOSEN_BY_HUMAN

qx_decisions.jsonl に、プローブのエビデンスを引用した、人間による DECIDED のメソッド選択が含まれている場合に合格です。ブロック中もデータの準備は許可しますが、モデルコードの生成は許可しません。

G3 — CODE_AND_EXPERIMENT_REVIEWED

次の条件を満たす場合に合格です。

  • 承認済みの主要候補とベースラインが実行されている。
  • 最新の run_summary.json が完全である。
  • 言語レビューに、構文、入力契約、メソッドとの整合性、再現性、出力契約について、名前付きの合格チェックが含まれている。

移行中はレガシーの Markdown レビュー成果物を受け入れますが、新しい作業では JSON を優先してください。

G4 — RESULTS_JUDGED_AND_FROZEN

lean では、最終結果と安定性に関する判断が、計算済みのエビデンスを引用している場合に、結果判断のサブゲートに合格します。人間が adjust または fallback を選んだ場合は、凍結せずに反復を続けてください。

submission では、さらに次の条件が必要です。

  • 最終メソッドの説明
  • 最終結果の分析
  • ロバスト性レポート
  • 判断台帳におけるパッケージの承認
  • ソリューションパッケージ
  • 最新の frozen_numbers.json

G5 — PAPER_SECTION_READY

3 つの執筆ルール、凍結した数値の出典、人間が確認した解釈と主張の範囲、検証済みの図表を必須とします。

G6 — FINAL_AUDIT_PASSED

submission でのみ評価してください。整合性、完全性、QA の各成果物が合格している必要があります。ある監査担当が別の監査担当の役割も担うとは推定しないでください。

ルーティング

次の中から、次のアクションを 1 つ選んでください。

  • フレーミングが不足している → パーサー/分類器、または人間向けのフレーミングカード
  • データプロファイルが不足している → data-auditor-cleaner
  • メソッドカードまたはプローブが不足している → method-selector
  • 人間によるメソッド選択が不足している → decision-prompt-builder
  • メソッドは承認済みだが実装計画がない → model-code-analyzer
  • コードまたはレビューが未完了 → 言語ジェネレーターまたはレビュアー
  • 有意義な実験の結果判断が未完了 → 結果選択カード
  • 最終結果はあるがロバスト性が未確認 → robustness-checker
  • 提出用パッケージが未完成 → 最終説明、結果レポート、またはパッケージビルダー
  • 論文セクションは準備できているが未監査 → 最初に不足している最終監査担当

判断に関わる複数のスキルを、推測で呼び出さないでください。

変更の影響

チェックをスケジュールする前に、変更を分類します。

  • NONE:一時作業、書式、コメント、意味に影響しないドキュメント。
  • LOCAL:凍結前の探索的なコード変更またはメソッドカードの更新。
  • CANONICAL:スキーマ/単位、記号、方程式、パラメーター、公式値、図のパス。
  • FROZEN:凍結済みの値または論文の主張に影響する変更。

チェックの実施先:

  • NONE:なし。
  • LOCAL:ローカルテスト/レビュー。
  • CANONICAL:影響を受ける Qx を対象に整合性を確認。
  • FROZEN:凍結解除ログを記録し、影響を受ける作業を再実行して再凍結し、対象範囲の整合性を確認。

複数のファイルが変更されたという理由だけで、ワークスペース全体の整合性監査をスケジュールしてはいけません。

Lean と Submission

lean では:

  • マニフェスト、メソッドカード、判断台帳、プローブの概要、実行の概要のみを必須とします。
  • ラウンドごとの Markdown レポート、完全な成功ログ、凍結済みの数値、論文の成果物、最終監査は必須にしません。
  • 詳細なレポートは、人間が判断する時点または最終ラウンドでのみ保存します。

submission では:

  • 最終説明、レビュー、分析、ロバスト性評価、パッケージ、凍結、論文、G6 を必須とします。
  • 最終組み立ての前に、3 監査担当者による全レイヤーの監査を 1 回実行します。

互換性

新しい成果物がない場合は、レガシー成果物を読み取ります。

  • planning/progress_dashboard.md
  • qx_method_candidates.md
  • qx_method_iteration_log.md
  • qx_decision_log.md
  • decisions/*_modeler_decision.md
  • Markdown のコードレビュー

マニフェストで legacy_source としてマークし、次回の重要な編集時に移行を推奨します。新しい作業のためにレガシーファイルを再生成してはいけません。

出力

簡潔な状態レポートを返します。

  • プロファイル。
  • 質問ごとの現在のゲートとブロッカー。
  • 変更された、または不足している成果物。
  • 変更の影響クラス。
  • 次のアクションを 1 つ。
  • 独立して進められる場合に限り、任意の次点候補。

ユーザーから求められない限り、ダッシュボード全体や大きな JSON 構造を貼り付けてはいけません。

検証

  • 状態は現在の正式な成果物から導出されている。
  • Lean の要件と submission の要件が混同されていない。
  • AI の提案から人間の判断を推測していない。
  • コード生成、凍結、論文執筆、最終組み立てのフラグが各ゲートと一致している。
  • 監査の範囲が意味上の影響と一致している。
  • マニフェストと報告された次のアクションが一致している。

コメント