taskflow

TaskFlow

所有者が 1 人で、状態の範囲が限定され、明示的な待機を含む複数ステップの作業には、管理対象の TaskFlow を使用します。成果物の完了を伴う単一の切り離された ACP／サブエージェント実行には、ミラーリングされたフローが自動的に割り当てられるため、別の管理対象フローは必要ありません。

ワークフローを実行する

Lobster プラグインがインストールされ、有効化され、使用を許可されている非サンドボックスセッションで、利用可能な lobster ツールを使用します。このスキルはガイダンスであり、プラグインを登録するものではありません。api オブジェクトやタスク起動ツールは提供しません。

以下の例では、Gateway ホスト上の Node と、すでに分類済みの合成データが必要です。すべての項目を振り分け、承認のために一時停止した後、振り分け結果を返します。メールの読み取りやメッセージの送信、PR の変更、切り離された子プロセスの起動は行いません。以下のパスは、Gateway の作業ディレクトリがリポジトリルートであることを前提としています。それ以外の場合は、例のファイルの絶対パスを使用してください。

{
  "action": "run",
  "pipeline": "skills/taskflow/examples/inbox-triage.lobster",
  "flowControllerId": "lobster/inbox-triage",
  "flowGoal": "Review synthetic inbox routing",
  "maxStdoutBytes": 8192
}

PR の受付には、代わりに skills/taskflow/examples/pr-intake.lobster とコントローラー lobster/pr-intake を使用してください。インテントは close、request_changes、refactor、maintainer_review です。GitHub のアクションは実行されません。

承認して再開する

ツール結果の details を読み取ります（JSON テキストとしても表示されます）。ここには status、requiresApproval、flow、mutation が直接含まれており、入れ子になった envelope の中にはありません。

1. キャンセルされていない結果では、mutation.applied === true であることを確認します。そうでない場合は、その code を報告して停止します。ワークフローが成功しても、フローの更新が永続化されたとは限りません。
2. needs_approval の場合は、requiresApproval.prompt と items を提示し、ユーザーの判断を待ちます。
3. 同じ所有者セッションで、action: "resume" の呼び出しを別途作成します。mutation.flow.flowId を flowId に、mutation.flow.revision を flowExpectedRevision に設定し、ユーザーの判断を approve に設定します。token と approvalId を省略すると、ツールは保存済みのチェックポイントを取得します。指定する場合は、チェックポイントと一致している必要があります。再開時も maxStdoutBytes: 8192 を維持してください。

古いトップレベルの flow.revision ではなく、更新後のリビジョンを使用します。approve: false を設定するのは、ユーザーが拒否した場合に限ります。承認された場合は、新しい mutation.applied とフローのステータスを確認します。キャンセルされた場合は、mutation.cancelled を確認します。エラー、拒否された更新、保留中のキャンセルを報告し、完了したと主張しないでください。リビジョン競合の後に副作用をむやみに再試行しないでください。まず再読み込みして、状態を照合してください。

サブエージェントを連携させる

調査やレビューの並列実行、ハンドオフの実装や検証、再起動後の照合、または任意の共有ワークスペースの確保については、references/subagent-workflows.md を読んでください。依頼に合った手順を使用します。小規模な委任に Workboard や別のフローは必要ありません。手順では、別個のスケジューラーではなく、既存のツールと現在の実行記録を使用します。

目標を完了する

リンクされた子プロセスが終端状態に達しても、管理対象フローは完了しません。その結果をフローの目標と照合し、対象範囲内の次のステップを予定します。目標の受け入れ条件を検証してから、finish(...) を呼び出してください。

終端結果を伴うワークフローでは、受け入れ状態を stateJson に明示的に永続化します。たとえば、PR をマージするフローは、レビューと CI の間は実行中または待機中の状態を維持し、ホスティングサービスが PR のマージを報告した後にのみ完了します。

永続状態はスケジューラーではありません

TaskFlow のレコードは SQLite に保存されます。コントローラーは最新のレコードを再読み込みし、明示的に再開する必要があります。任意の JavaScript や実行中の処理は再実行されません。Lobster の承認による一時停止は、Slack の返信を監視するリスナーではありません。永続化する状態は、全メッセージや履歴ではなく、上限のある ID、ルートの概要、カーソルに限定してください。

プラグインの作成者は api.runtime.tasks.managedFlows を使用します。flows と runs では、所有者スコープの検索ができます。runTask は、所有者と正規の run/session ID が一致する、すでに起動済みの正式な ACP／サブエージェント実行を関連付けます。実行を起動することはありません。ID、タイムスタンプ、バックエンドのレコードを捏造しないでください。プラグインの起動／関連付けの契約 と Task Flow を参照してください。

受信トレイのルーティングと実際のアダプター要件については、skills/taskflow-inbox-triage/SKILL.md をお読みください。ツールのセットアップについては、Lobster を参照してください。