mcpField
U
using-workflows

using-workflows

github.com/ohyehエージェントワークフロー0243 回インストール今日更新
リポジトリ

using-workflows について

Claude Code と Codex 向けのワークフロールーティングスキルで、タスクにレシピが必要かを判断し、選択して実行ループを管理します。単発タスクと複数段階の作業を分け、実行ディレクトリ、レビューゲート、ランタイム間の実行規則を定めています。

主な機能

  1. 01タスクの形に応じたワークフローレシピの選択
  2. 02範囲の限られた単発タスクの直接処理
  3. 03レシピの引数と実行経路の指定
  4. 04レビューゲートと人による承認の管理
  5. 05Claude と Codex のランタイム間実行の制約
  6. 06必要に応じた実行記録ディレクトリの作成

活用シーン

  1. 01監査や根本原因調査に適切なレシピを割り当てる
  2. 02計画から実装までの複数段階作業の手順選択
  3. 03複数ラウンドにわたる調査情報収集の管理
  4. 04定められた規則に沿った Claude Code と Codex 間のレシピ実行

インストール

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

$npx skills add https://github.com/ohyeh/agent-scripts --skill using-workflows

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

同梱ファイル

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

references/
codex-adapter.md
scripts/
install.sh
workflows/
consensus-gate.workflow.js
design-vs-code-audit.workflow.js
docs-vs-code-audit.workflow.js
feature-lifecycle-auto.workflow.js
feature-plan-consensus.workflow.js
findings-triage.workflow.js
haiku-research-round.workflow.js
plan-pipeline.workflow.js
pr-review-triage-resolve.workflow.js
project-direction-review.workflow.js
README.md
root-cause-deep-dive-audit.workflow.js
spec-implement-dual-review-verify.workflow.js
workflow-manifest.workflow.js
workflows/_lib/
findings-schema.js
safe.js
worker-doctrine.md

詳細

using-workflows

状況に応じてどのレシピが必要かを選び、引数を埋めて実行し、閉じたループを進めます。あなた自身はレシピではありません。

BYPASS — まず確認

単一コンテキストで完結する、範囲が限定されたタスクで、段階も収束条件もない場合は、直接実行してください(その場で行うか、using-tmux-agent-tools を使ってワーカーを 1 人だけ起動します)。レシピも実行ディレクトリも不要です。迷った場合はバイパスしてください。レシピが必要なのはループのためであり、形式のためではありません。例外:複数の情報源やラウンドにまたがる調査(検索、価格の比較、情報源の収集など)はバイパスせず、haiku-research-round に進みます。1 回のツール呼び出しで済む事実確認は、その場で行ってください。

実際に問題を引き起こした警告サイン(理由を明示せずに挙げて先へ進むのは禁止です):

  • 「あのレシピの内容は覚えている」— レシピは変わります。実行前にヘッダーコメント(引数の仕様)を読んでください。引数を推測してはいけません。
  • 「先に完了してから実行記録を補う」— 以下の実行ディレクトリの基準に該当する場合は、まず作成してください。
  • 「この小さな変更にゲートは不要」— どのレシピであっても、動作に関わる階層の編集には、まずコンセンサスゲートのラウンドが 1 回必要です。

サブエージェントの免除:委任されたワーカーはこのルーターを経由しません。ディスパッチャーがすでに振り分けているため、ワーカーは依頼内容に従ってください。

トリガー

段階と収束条件のある、ループ型の作業です。監査チェーン、コンセンサスレビュー、計画から構築までのライフサイクル、調査結果のトリアージなどが該当します。

Continuity トリガーから(グローバル CLAUDE.md/AGENTS.md)

グローバルルールにより、ループ型の作業はタスク開始時にここへ振り分けられます。到着したら、次の手順に従ってください。

  1. トリガーワード(audit / consensus verification / findings triage / root-cause deep-dive / plan→build)を、以下の SELECT に従ってレシピに対応付けます。
  2. ランタイムの使い分け:Claude は Workflow でレシピをネイティブに呼び出します。Codex は references/codex-adapter.md(claude-workflow-runner)を介して実行します。ランナーは機械的な処理なので、opus の low 労力度(下限。MODEL FLOOR を参照)で実行してください。
  3. 書き戻しの義務:すべてのレシピ成果物と結果を、呼び出し元の .workflow/<YYYYMMDDHHMM>-<slug>/ 実行ディレクトリ(Continuity ルールに従って作成したもの)に保存してください。別の場所に保存してはいけません。1 つのタスクにつき実行ディレクトリは 1 つとし、慣例とレシピで共有します。

SELECT

ライブで探索します。レシピ一覧を記憶からそのまま読み上げてはいけません。

ls ~/.claude/workflows/*.workflow.js .claude/workflows/*.workflow.js 2>/dev/null

内側のループ(唯一のループです。スケジューリング用の外側のリングはありません。作り出さないでください)。

audit (docs-vs-code | design-vs-code | root-cause-deep-dive)
  → findings-triage        connector ①: askUser → human VERBATIM ·
  │                        briefs → lifecycle · directFix → partitioned run
  → feature-lifecycle-auto thin shell: feature-plan-consensus | plan-pipeline
  │                        → gate ✋ (autoBuild=false: human reads the plan)
  │                        → spec-implement-dual-review-verify
  → re-run the ORIGINATING audit, SAME args
  │                        connector ②: lives in YOU, not in code
  → confirmed == 0 AND no unverified/unaudited (§9.2) → converged, report · else → back to findings-triage / re-check

ループ外のエントリーポイント:

  • 奇妙なバグ → root-cause-deep-dive-audit · ドキュメントと設計のずれ → 対応する監査
  • 1つの成果物について別モデルの判定が必要 → consensus-gate — 1ラウンドのみ、不可逆な変更または振る舞いに関わる変更に限ります。デフォルトの工程ではありません
  • 「このプロジェクトが次に何をすべきか」 → project-direction-review
  • レシピ群のインベントリ/マシンのずれ → workflow-manifest
  • 調査(事実、価格、情報源。複数ラウンドになることがよくあります) → 各ラウンドで haiku-research-round を実行します。あなたは指揮役のままです。各ラウンドを読み、次の質問を選んでください。 ユーザーがツール名(例:codex-cu)を指定した場合は、自分で対象を1つ実行して動作するレシピを取得してから、そのツールとレシピを args.tools に渡してください。他の対象を自分で調べてはいけません。スカウトのブロッカーは手がかりです(judgment-rubrics §2)。 ツールで直接エラーが発生したら、すぐに報告してください。「対象は X ができない」と報告する前に、スカウトが X を実現する別の方法を1つ確認します。あなたのツール操作がエラーの原因なら、修正してください。その後、スカウトを再実行します。

ステージレシピ(feature-plan-consensus、plan-pipeline、 spec-implement-dual-review-verify)は通常、feature-lifecycle-auto 経由で実行します。そのステージだけを実行したい場合に限り、直接呼び出してください。 Args は自動入力されます。cli は省略可能です(ユーザー判断 2026-09-02:codex に依存してはいけません)。インストール済みの agent-tmux プロファイルはどれもレビューゲートとして有効です — codex、 claude-fable-opus / claude-fable-gate*、cursor(grok)、agy* — 実質的な作成者とは異なるものを選びます。ls ~/.config/agent-tmux/profiles でライブの一覧を確認してください。これを省略すると、各ステージで独立したコンテキストにいる新規の Claude opus レビュアーが実行されます。名前をハードコードしてはいけません。インストールされていない外部 CLI を理由に実行をブロックしてはいけません。context は1行(リポジトリの絶対パス+スタック+スコープ)です。 スクリプトパスより名前での呼び出しを優先してください。 ワークフローエージェントは mod ツールを使って CLI ワーカーを動かします。ワーカーがまだいない場合は mcp__tmux-agent__assign、以前の呼び出しで返されたワーカーがいる場合は tell を使います(consensus-gate の2ラウンド目以降では worker として渡す必要があります。そうしないと新しいワーカーが起動します)。その後、終端結果が返るまで mcp__tmux-agent__await を呼び出します。結果はそのエージェントに返されます(2026-10-11 時点で稼働中、tmux-agent-tools ≥ a68ecd4)。 コレクターは同じ結果について、メインセッションにも通知を1件送信します。agent() 内の runtime: tmux/<profile> 行はインターセプトされません。cli レシピ(consensus-gate、plan-pipeline、feature-plan-consensus)はこの方法で動作します。起動または作業量に関するフラグは、cli が指定する agent-tmux プロファイルの .conf に記述してください。

MODEL FLOOR(ユーザー判断 2026-09-02)

以下に挙げるワーカー、L1/TK レビューロール、機械的な担当(L0 ランナーと CLI コンダクト:sonnet medium)を除き、すべてのレシピエージェントは少なくとも opus effort low で実行します。デフォルトのワーカーは opus effort medium、レビュアーは high です。計画、統合、 修正、判定は決して sonnet や haiku で実行しません。どちらかが作成した計画は計画ではありません。sonnet 5.5+ は、レビューラダーの L1 プレフィルターを実行できます(model-dispatch.md §Review ladder、ユーザー判断 2026-10-09。plan-pipeline と spec-implement-dual-review-verify はこれをスクリプト内で実行し、後者は1回限りの pr-review-toolkit TK ステップも実行します)。判定は opus(L2)または fable(L3)が行います。 それ以外の場合、指揮役の指示により、sonnet/haiku 5.5+ は実装および読み取り専用のデータ収集を実行できます(ユーザー判断 2026-10-10)。レシピの引数で選択します。spec-implement… は model、pr-review-triage-resolve は fixModel、feature-plan-consensus は discoverModel です。

ADVISOR GATE(ユーザーによる裁定、2026-09-02)

レシピからツールを呼び出すことはできません。ゲートを担うのは、指揮役であるあなたです。advisor ツールを利用できる場合、以下の各時点で必ず使用し、次のアクションに進む前に実行ディレクトリへ判定を記録してください。

  1. 最初の Workflow の起動前 — 概要、レシピ、引数(モデルの最低要件、cli を省略するか、その理由、ラウンド上限、厳格な時間制限)。
  2. レシピが返すすべての人間によるゲート(needsUser、autoBuild=false、計画が問題なし → ビルド) — 計画そのもの、その規模、ビルドするかどうか。
  3. 中止後(利用制限、ラダーの上限到達)の再開/再起動前 — 同じ実行のまま続けるか、範囲を狭めるか。 advisor による判定がなければ、起動、再開、ビルドを行ってはいけません。2026-09-02 の quick-share 実行(計画エージェント 32 個、入力トークン 182M、計画 64 KB、3.5 時間にわたりコード生成ゼロ)が見逃されたのは、「計画の改訂 N」と「批評ラウンド N+1」の間にゲートがなかったためです。

ランタイムをまたぐ実行

どちらのランタイムも、このルーターを通じてレシピを実行します。異なるのは実行手段だけです。Claude Code は .workflow.js を Workflow() でネイティブに実行します。Codex は ADAPTED: claude-workflow-runner(1 回の制限付き Claude ランナーカプセル。仕組みは references/codex-adapter.md を参照)を、以下の制約の下で実行します(Codex 作成、gate-v2、2026-07-19)。

  • Codex は、Claude ランナーを 1 つだけディスパッチする前に、レシピ名、引数、受け入れ条件、作成元ランタイム、レビュアープロファイルを必ず確定しなければなりません。
  • ランナーは、ネイティブの Workflow(...) を 1 つだけ呼び出し、その戻り値を recipe_result に保持し、schema-v1 の result.json を書き込んだ後、停止しなければなりません。
  • その後に例外が発生した場合は、ネストの深さを 2 に制限し、子のプロファイル/ラウンド上限を宣言し、一意のセッションと完了待ちが必要な結果を使用し、子の生成を禁止しなければなりません。
  • args.cli は任意です。設定する場合は、レビュー対象の実質的な作成者に基づいて解決してください(Codex が対象を作成した場合は、Codex 以外のプロファイルを指定)。明確でない場合は省略してください。レシピが新規に起動する Claude の opus レビュアーが、デフォルトのセカンドオピニオンになります。
  • 人間によるゲートでは、status: paused と next_action を返し、recipe_result を保持してランナーを停止しなければなりません。再開できるのは、明示的に承認された新たな呼び出しを通じてのみです。
  • 証跡には「recipe executed natively on Claude runtime via runner (commanded by Codex)」と記載しなければなりません。アダプターまたは子の失敗を、レシピの PASS として扱ってはいけません。

ランタイム対応表(Claude Code は 13 個すべてで NATIVE。Codex の列):

レシピCodex
3 件の監査、findings-triage、project-direction-review、workflow-manifest(6 件、内部で tmux を使用しない)ADAPTED: claude-workflow-runner
haiku-research-round(tmux なし)UNTESTED — これまで Claude 上でネイティブ実行したのみ。停止して報告してください
pr-review-triage-resolve(tmux なし。T3 の段階は、externalAgentType が設定されていない場合、新規の Claude opus を使用)UNTESTED — これまで Claude 上でネイティブ実行したのみ。停止して報告してください
consensus-gate(単純な判定結果のみ)ADAPTED: direct-claude-review — references/codex-adapter.md
consensus-gate(レシピとして)、ライフサイクルと cli が設定されている場合のその 3 段階(5 件。内部で tmux-agent mod ワーカーを実行)ネストランナー(深さ 2)のテストに合格するまで UNAVAILABLE-NATIVE — 停止して報告してください。独自に代替手段を作ってはいけません

後回しにする事項

  • レシピの連鎖は最上位からのみ行ってください。workflow() のネスト上限は 1 であり、ライフサイクルシェルがその枠を使います。
  • 実行ディレクトリ(.workflow/<slug>/、codex-dynamic-workflows の規約)を使うのは、作業が数日にわたる場合、2 つ以上のフェーズがある場合、または中断/引き継ぎに耐える必要がある場合に限ります。チャット内で完結する作業には、単一の結果ファイルを使うか、何も作成しません。
  • レシピの編集:動作に関する変更は、まず consensus-gate を 1 ラウンド実行します。文言の変更は直接行います。正本は agent-scripts リポジトリのバンドル(skills/using-workflows/workflows/)です。~/.claude/workflows/ に再配備してください。マシン上で直接編集した場合は、同じ変更の中でバンドルにも反映しなければなりません。

NOT-FOUND

該当するレシピがありません → 作業はおそらくループ形式ではないため、迂回してください。まったく新しいループ形式の場合 → ユーザーに新しいレシピを提案してください。インラインで中途半端なレシピを即興で作ってはいけません。レシピごとのリファレンス:workflows/README.md(正本:agent-scripts バンドルの skills/using-workflows/workflows/README.md、デプロイ先のコピー:~/.claude/workflows/README.md)。

コメント