taskflow-inbox-triage

TaskFlow の受信トレイの振り分け

skills/taskflow/examples/inbox-triage.lobster を、skills/taskflow/SKILL.md に記載された管理対象の Lobster 実行／承認／再開手順で使用します。デフォルトのバッチは合成データで、すでに分類されています。このワークフローはすべての項目を business、personal、later の ID リストに振り分け、実際の承認のために一時停止した後、送信を行わずにそれらのリストを返します。

入力と結果

各項目には、空でない id（長さは最大 80 文字）と route（business、personal、later のいずれか）が必要です。バッチの上限は 20 項目です。無効な入力は明示的に失敗し、空のバッチでは 3 つの空リストが返されます。初回実行時に argsJson を指定すると、デフォルト値を上書きできます。たとえば、次のようにします。

{
  "items": [
    { "id": "demo-business-1", "route": "business" },
    { "id": "demo-personal-1", "route": "personal" },
    { "id": "demo-later-1", "route": "later" },
    { "id": "demo-business-2", "route": "business" }
  ]
}

このオブジェクトをシリアライズし、argsJson 文字列として渡します。この例を試すときは、合成 ID を使用してください。承認によって確認されるのはプレビューのみであり、実際の配信は許可も実行もされません。

実際の受信トレイ処理を明示的に接続する

実際のコントローラーには、上記の制約に従った入力を生成する受信トレイリーダーと分類器に加え、各ルートに対応するアダプターが必要です。

ルート	実際のコントローラーに必要な処理
business	認可済みの Slack アダプター経由で投稿し、返されたスレッド ID を保存してから、関連付けられた人間の返信を待ちます。
personal	認可済みのチャネルアダプター経由で所有者に通知し、配信結果を記録します。
later	明示的にスケジュールされた一日の終わりの実行に向けて、上限付きの要約参照を保持します。

これらのアダプターは、この例には含まれていません。振り分ける前にすべての項目を分類してください。先頭の要素だけを見て、混在するバッチの処理を決めてはいけません。想定上の組み込み openclaw.invoke ブリッジではなく、直接利用可能な分類ツールまたは実際のアダプターを使用してください。実際の副作用が発生する前に承認を得てください。

業務上の返信については、コントローラーがイベントリスナーを登録し、waitJson にスレッドとの関連付けを上限付きで指定して setWaiting を呼び出し、該当する返信が届いた後にのみ再開します。Lobster の承認トークン、エコーされた待機用 JSON、または setWaiting の呼び出しだけでは、そのリスナーは設定されません。組み込みの Lobster 入力／ask リクエストはサポートされていません。

分類で切り離された処理を使う場合は、runTask で関連付ける前に、公開されているリクエスター紐付けプラグインパスを通じて起動してください。結果を解釈する前に、実際の完了を待ってください。pending や観測タイムアウトは、終端状態の失敗ではありません。失敗した場合は、フローの結果を失敗またはブロックとして記録し、報告してください。起動または関連付けが拒否された後に、子処理を捏造してはいけません。

継続に必要な ID、小さな要約、カーソルのみを保存してください。再起動後またはリビジョン競合後は、所有者に紐付けられたフローを再読み込みし、次の遷移を適用する前に調整してください。finish を含むすべての変更を確認してください。確認していない結果から成功を報告してはいけません。コントローラーによる再開とキャンセルについては、Task Flow を参照してください。