あなたはこのリポジトリのLLMワークフローをCaveman Cloud向けにラベル付けしています。ワークフローとは、コードが実行するジョブです（例：「サポートチケットに回答する」「ナイトリーダイジェストを構築する」「評価スイートを実行する」）。テクノロジーではありません。すべてのゲートウェイリクエストにはワークフローラベルを付与できます。ラベル付けされていないトラフィックはすべてunlabeled-workflowバケットにまとめられます。あなたの仕事は、ワークフローを見つけ、適切に命名し、ラベルを設定し、何も壊れていないことを確認することです。
これはコードを変更するため、ユーザーの通常のレビュープロセスを経ます。最初にテーブルを提案し、ユーザーが同意した後に適用してください。 既にラベル付けされたリポジトリで再実行しても何も変更してはなりません（冪等性）。
このスキルはオペレーターによって呼び出されます。unlabeled-traffic Cave Planの観察結果はレビューのみであり、アドバイザリファイル、提案、Draft PRを作成してはいけません。テレメトリーがコールサイトを選択したり編集を許可したりしたと推測してはいけません。独立してリポジトリを調査し、ラベル付けテーブルを提示し、コードを変更する前にユーザーの承認を待ちます。
ステップ1 — ワークフローを調査する
リポジトリをインポートからではなく、エントリポイントから確認します：
- HTTP/RPCハンドラでLLMを呼び出すもの（直接またはレイヤーを介して）
- スケジュールジョブ：cron定義、キューコンシューマー、ワーカー、LLMコードを呼び出すGitHub Actions
- CLIコマンドとスクリプト（
scripts/、bin/、package.jsonのscripts） - 実際のトークンを使用する評価/テストハーネス
- フレームワーク内の個別のエージェントまたはチェーン（各LangGraphグラフ、各クルー、各エージェント定義は通常、それ自体が1つのワークフローです）
1つのワークフロー = 人間が名前を付けるであろう1つのジョブです。同じリクエストハンドラ内の10箇所の呼び出し元は1つのワークフローです。1つの共有llm.tsヘルパーを3つのジョブで使用している場合は3つのワークフローです（共有ヘルパーではなく、呼び出し元でラベル付けします）。
ステップ2 — 命名する
スラッグ文法（ゲートウェイで強制）：小文字の[a-z0-9_-]、1〜96文字。テクノロジーではなくジョブの名前を付けます：
- 良い例：
support-reply、nightly-digest、pr-review、eval-suite、onboarding-email - 悪い例：
openai-calls（テクノロジー）、main（意味がない）、SupportReply（無効）、johns-test-3（意味が変わらない）
名前はほぼ永久です。後で名前を変更すると支出履歴が分割されます。コードからジョブの目的が明確でない場合は、ファイル名からスラッグを導出し、目的をでっち上げる代わりにテーブルでreviewとマークします。
ステップ3 — 提案し、適用する
以下のテーブルを提示し、続行するかどうかを尋ねます：
| workflow | job | where | how it gets labeled |
|---|---|---|---|
| support-reply | インバウンドチケットに回答 | src/bot/reply.ts:41 | 返信クライアントのdefaultHeaders |
| nightly-digest | 02:00の要約ジョブ | jobs/digest.ts:12 | ダイジェストクライアントのヘッダー |
| eval-suite (review) | scripts/eval.ts:8 — ファイル名から目的を推測 | scripts/eval.ts:8 | 呼び出し時の環境変数オーバーライド |
次に、各呼び出し元で利用可能な最も軽量なメカニズムを使用してラベルを設定します：
- @caveman-ai/sdk / caveman_cloud SDK：トレースごとの
workflowオプション、またはシングルジョブサービスが構築するクライアントのdefaultWorkflow。 - 生のプロバイダーSDK（OpenAI/Anthropic/LangChain/LiteLLM/Vercel）：既に
x-cave-api-keyを保持しているdefaultHeaders/default_headers/extra_headersブロックに"x-cave-workflow": "<slug>"を追加します。複数のジョブで使用される共有クライアント → 呼び出しごとにヘッダーを渡す（上記のすべてのSDKはリクエストごとのヘッダーオーバーライドをサポート）、または各ジョブに独自のシンクライアントを与えます。 - ラップされたコーディングエージェント（
caveman wrap）：呼び出し元（cron行、CIステップ）で--workflow <slug>フラグまたはCAVE_WORKFLOW=<slug>環境変数。 - 生のHTTP：リクエストに
x-cave-workflowヘッダーを追加します。
呼び出し元にラベルを付け、差分を最小限にし、リポジトリのスタイルに合わせます。呼び出し元がまったくCavemanゲートウェイを経由していない場合は、ラベルを付けず、レポートの「未配線」の下にリストします（ラベルはゲートウェイトラフィック上でのみ移動します。配線はcaveman-setupスキルの仕事です）。
ステップ4 — 検証する
リポジトリがすでに使用しているものを実行して、ラベル付けされたパスを1つテストします（テスト、開発スクリプト、1回のcurl）。その後、以下を確認します：リクエストが依然として成功すること（ゲートウェイは無効なラベルを400 cave_invalid_request_headerで拒否します。その場合はスラッグを修正します）。ラベル付けされた支出がダッシュボードの/activity?tab=workflowsに表示され、各ワークフローが次回実行されたときに確認できます。スケジュールされたジョブは、スケジュールがトリガーされたときに表示されます。これはレポートで述べる価値があり、あたかもライブであるかのように装うべきではありません。
ステップ5 — レポート
## ラベル付けされたワークフロー
| workflow | job | where |
|---|---|---|
| support-reply | インバウンドチケットに回答 | src/bot/reply.ts:41 |
| nightly-digest | 02:00の要約ジョブ | jobs/digest.ts:12 |
検証済み：<実際に実行したラベル付けパスと、観察された内容>
ダッシュボード：<ダッシュボード>/activity?tab=workflows — 各行は、そのワークフローが次回実行されたときに表示されます。まだラベル付けされていないものは`unlabeled-workflow`として表示されます。
未配線（ゲートウェイルーティングなし、そのためラベルなし）：<リストまたは「なし」>
レビューマーク：<ファイル名から目的を推測したスラッグ、または「なし」>
LLMエントリポイントがまったく見つからなかった場合：その旨を正確に述べ、テーブルを作成する代わりにセットアップスキル（<ドキュメントのルート>/docs/agent-setup.md）を参照してください。