workflow-mode-lifecycle について
workflow-mode-lifecycleは、手動・自動モードとai-proxyオーバーレイの動作規則を定める、ワークフロー向けの内部共有スキルです。自動実行の完了または中断後は手動モードに戻り、再度自動モードにするには明示的なトリガーが必要です。
主な機能
- 01手動モードと自動モードの認識
- 02ai-proxyオーバーレイの規則
- 03完了・中断後の手動モードへの復帰
- 04自動モード再開時の明示的なトリガー
- 05バッチ呼び出しでのモード引き継ぎ規則
活用シーン
- 01依存するワークフローのモード切り替えの統一
- 02各段階の終了時に確認を求める一時停止
- 03完了・中断後の手動モードへの復帰
- 04サブ呼び出しごとの終了ポリシーの伝達
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ fudesign2008/ open-skills --skill workflow-mode-lifecycleインストール後、Claude Code で/workflow-mode-lifecycleを入力して読み込まれたか確認します。
詳細
ワークフローモードのライフサイクル
内部共有スキルです。モードの固定化、つまり AI が依然として自動で判断していることにユーザーが気付かない状態を防ぎます。このスキルを参照するワークフローは、フロントマターの
dependenciesでこのスキルを宣言し、見つからない場合は起動時に中止します。
モードの認識
- ai-proxy のトリガーを列挙しているホストでは、オーバーレイを示すフレーズ(「ai-proxy 模式」「AI 代理模式」 / "ai-proxy mode"、または実行中の「切换 ai-proxy」 / "switch to ai-proxy")があれば、まずオーバーレイを要求します(以下のセクションを参照)。オーバーレイのトリガーと「自动*」の両方がある場合は、単独の自動モードではなく、オーバーレイ+フリーズが優先されます。
- それ以外では、トリガーに「自动」(auto)が含まれる場合は 自動モード、それ以外は 手動モード(デフォルト)です。
- 実行中の切り替え:ユーザーが「切换自动模式」 / 「切换手动模式」と言った場合、モードを切り替えます。実行中にオーバーレイへ切り替える場合は「切换 ai-proxy」 / "switch to ai-proxy" です。
- 手動モード:各ステージの終了時に一時停止し、ユーザーの確認を求めます。自動モード:ワークフローで定義された制限(例:レビューのループ上限)でのみ一時停止し、最初から最後まで進めます。
ai-proxy オーバーレイ(3つ目の制御フローモードではありません)
description に ai-proxy のトリガーを列挙しているホストは、手動/自動モードに重ねる オーバーレイ を認識します。
- 「ai-proxy 模式」「AI 代理模式」 / "ai-proxy mode" はオーバーレイを要求します。「切换 ai-proxy」 / "switch to ai-proxy" は実行中に切り替えます。
- オーバーレイは 自動モードを基盤 とし、
Stage-exit policy: ai-proxyを保留状態にします(口頭のトリガーは適用状態ではなく、フリーズによってポリシーが適用されます)。適用状態と簡易フリーズはai-proxy-disciplineで定義されています。このスキルでは、その規約を再掲してはなりません。 - 自動モードのトリガー(「自动*」)とオーバーレイのトリガーが両方ある場合は、単独の自動モードではなく、オーバーレイ+フリーズ が優先されます(名前付きエスケープのパススルー)。
- 全フローの完了時、または中断時には、オーバーレイは手動モードに戻り、
Stage-exit policyもクリアされます(自動モードと同じ復帰表に従います)。オーバーレイに再度入るには、明示的なトリガーが必要です。「继续」「再改一下」「深入分析」のような暗黙の続行によって、オーバーレイを再び有効にしてはなりません。 descriptionに ai-proxy のトリガーがないホスト(write-workflowを含む)は、オーバーレイを無視しなければなりません。「ai-proxy 模式」は、そのホストの2状態の認識を変更しません。
基本ルール:自動モードは必ず手動モードに戻る
自動モードは、次の場合に自動的に手動モードへ戻ります。
| シナリオ | 備考 |
|---|---|
| フローが正常に完了した場合 | 新しいサイクルを開始すると決定した場合も含みます。新しいサイクルはデフォルトで手動モードから開始します |
| フローが何らかの形で中断された場合 | 失敗による中止、ユーザーによる停止、レビュー上限での一時停止後の終了 |
ワークフロー固有の完了時点(例:PR のマージ、アーカイブの完了)は、各ワークフロー独自の差分ブロックで定義します。ただし、モード復帰ルール自体は共通です。
自動モードへの再移行:明示的なトリガーのみ
手動モードに戻った後、自動モードへ再び移行するには、明示的なトリガーが必要です。
- 「自动 xxx」 / 「自动分析」 / 「自动解决」 / 「切换自动模式」
「继续」「再改一下」「深入分析」のような暗黙の続行によって、自動モードを再び有効にしてはなりません。
バッチシナリオ
バッチオーケストレーション(例:goal-driven-queue。jira-fix-queue / opsx-jira-fix-queue は、これにキューイングするトリガーシェルです)では、オーケストレーターが各サブ呼び出しに Stage-exit policy(したがって、オーバーレイ/自動モード/手動モードの別) を明示的に渡します。上記の単一実行時の復帰ルールは、サブ呼び出し間には引き継がれません。
統合ガイド(参照するワークフロー向け)
- ワークフロー本体に残すもの:ワークフローごとに異なるトリガー語の表、ステージごとの手動/自動モードにおける停止ポイントの概要、そして ワークフロー固有の差分 ブロック。
- このスキルに委ねるもの:手動モードへの復帰に関する基本ルール、明示的な再移行、暗黙の続行の禁止、バッチルール、および(ホストが ai-proxy のトリガーを列挙している場合の)オーバーレイ認識。これらの全文をインラインでコピーしてはなりません。
ai-proxy-disciplineの規約をここにコピーしてはなりません。 - 差分ブロックの例(ワークフロー内に記載し、ここへ移動しないでください):
--retryは手動モードにリセットする、--resumeはチェックポイントのモードを維持する、検証失敗時のロールバックは N 回の試行中はモードを維持する、アーカイブの失敗は中断として扱う。