caveman-discover
自分のアプリの中にある LLM の仕事（問い合わせへの返答、夜間の要約など）を洗い出して名前を付けさせ、Caveman Cloud への呼び出しに仕事の名札を付けさせる。一覧を見せて承認を取ってから書き換え、1 本動かして確かめさせる
npx skills add juliusbrussee/caveman/caveman-discover入れる前にこのスキルがすること・注意点・SKILL.md の原文を確かめてください。解析は安全性の判定ではありません。
- インストール
- 110,681
- 実用度
- 16
- GitHub star
- 117,973
- 最終更新
- 2026/11/6
頼み方の例
そのままコピーして使えますcaveman-discoverを使って、このリポジトリのLLMの仕事を洗い出してください。まず仕事の名前・中身・場所・名札の付け方の表だけを出し、私が承認するまでコードは書き換えないでください。
対象のファイルや状況は、ご自身の作業に合わせて置き換えてください。
このスキルがすること
SKILL.md の記述から機械的に抽出- 外部通信・シェル実行・ファイル操作の記述は見つかりませんでした
これは安全性の判定ではありません。 SKILL.md にそう書かれているという事実だけを並べています。実際に問題があるかは使い方と文脈で決まるため、当サイトでは断定しません。導入前に SKILL.md の原文を確認してください。
SKILL.md の規模
いつ使うか
自分のアプリを Caveman Cloud につないだものの、費用が 1 つの箱にまとまっていて、どの仕事にいくらかかっているか分からないときのスキルです。名札の無い通信は、すべて unlabeled-workflow という 1 つの箱に入ります。
caveman-setup でアプリ単位につないだあとの、次の一歩にあたります。setup の最後の報告も、用途ごとに分けたいなら「discover workflows」と言うよう案内しています。
- 洗い出しから報告まで
- 5 段
- 名札の付け方
- 4 通り
- SKILL.md（2026-10-23 時点）
- 5,276 バイト
「仕事」とは何か
本文の言う仕事（workflow）は、技術の名前ではなく、コードがこなしている仕事です。例に挙がっているのは「問い合わせに返答する」「夜間の要約を作る」「評価の一式を流す」です。
数え方にも決まりがあります。1 つの要求の処理の中に呼び出しが 10 か所あっても、仕事は 1 つです。逆に、共通の llm.ts を 3 つの仕事が使っているなら仕事は 3 つで、名札は共通の部品ではなく呼び出す側に付けます。
5 段で進める
- 洗い出す依存関係からではなく、入口（HTTP の処理、定時の仕事、CLI、評価、エージェントの定義）からたどる
- 名前を付ける仕事を表す短い名前を決める。目的が読めないものは「review」の印を付ける
- 表を見せる仕事・中身・場所・名札の付け方の表を出し、進めてよいか聞く
- 付けて確かめる承認のあと名札を付け、名札を付けた経路を 1 本動かす
- 報告する付けた仕事、確かめた内容、つながっていないもの、印を付けたものを並べる
洗い出しの入口は 5 種類が挙がっています。LLM を呼ぶ HTTP や RPC の処理、cron・キューの処理・GitHub Actions などの定時の仕事、scripts/ や bin/ のスクリプト、本物のトークンを使う評価やテストの仕組み、そしてフレームワークの中の個々のエージェントや連鎖です。
名前の付け方
ゲートウェイが受け付ける名前は、小文字の英数字と _ - の 1〜96 文字です。support-reply や nightly-digest のように仕事を表す名前はよく、openai-calls（技術名）・main（何も言っていない）・SupportReply（使えない文字）・johns-test-3（すぐ古びる）は悪い例として挙がっています。
名前を後で変えると費用の履歴が 2 つに割れる、と本文は注意しています。コードから目的が読めないときは、目的をでっち上げず、ファイル名から名前を作って表に「review」と付けます。
名札の付け方は 4 通り
| 呼び出しの形 | 付け方 |
|---|---|
| Caveman の SDK | 呼び出しごとの workflow か、1 つの仕事だけのサービスならクライアントの defaultWorkflow |
| プロバイダーの SDK（OpenAI・Anthropic・LangChain・LiteLLM・Vercel） | x-cave-api-key が入っているヘッダーの欄に x-cave-workflow を足す |
caveman wrap で包んだコーディングエージェント | 起動する場所で --workflow か環境変数 CAVE_WORKFLOW |
| 直接の HTTP | 要求に x-cave-workflow のヘッダーを足す |
1 つのクライアントを複数の仕事が共有しているなら、呼び出しごとにヘッダーを渡すか、仕事ごとに薄いクライアントを分けます。差分は小さく、リポジトリの書き方に合わせる決まりです。
使わないほうがいいとき
アプリがまだゲートウェイにつながっていないとき
名札はゲートウェイを通る通信にしか付きません。ゲートウェイを通っていない呼び出しには名札を付けず、報告の「つながっていない」に並べるだけです。つなぐのは caveman-setup の仕事だと本文は分けています。
LLM の入口が 1 つも見つからなければ、表をでっち上げずにそう報告し、導入の文書を案内して終わります。
費用の原因を調べたいとき
このスキルは名札を付けるところまでで、費用を読んで原因を探すことはしません。名札が付いて記録がたまったあと、どの仕事が重いかを読むなら caveman-evidence-review が向いています。
Caveman の観察に言われたから、という理由で動かしたいとき
本文は、このスキルは人が呼び出すものだと明記しています。Caveman 側の「名札の無い通信がある」という観察は確認用で、どの呼び出しを直すかを選んだことにも、書き換えを許したことにもならない、と書かれています。観察が出ていても、リポジトリを自分で洗い出し、表を見せて承認を待つ手順は変わりません。
注意点
コードを書き換える
SKILL.md には、ファイル書き換え（呼び出し箇所へのヘッダーや設定の追加）とシェル実行（確かめのためのテストや開発用スクリプト、curl など）の記述があります。確かめの 1 本は、名札を付けた経路で本物の要求を送ることになるので、外部への通信と、アプリが使うプロバイダーへの課金が起こりえます。
やり直しても何も変わらないのが正しい
すでに名札を付け終えたリポジトリで流し直しても、何も変えないことが求められています。2 回目で差分が出たら、名前の付け方か洗い出しのどこかがぶれています。
名札が画面に出るまで時間がかかる
ダッシュボードには、それぞれの仕事が次に動いたときに名札付きで現れます。定時の仕事は、その時刻が来るまで出ません。本文は、それをまだ出ていないと正直に報告に書くよう求めています。
名前に使えない文字が入っていると、ゲートウェイは 400 の cave_invalid_request_header で拒否します。そのときは名前を直します。
同梱ファイルは無い
スキルのフォルダーには SKILL.md しかありません（2026-10-23 時点）。
インストール数の推移
日次で記録10月14日 〜 11月7日（24日分）
インストール数と 1 日あたりの増加は Skillselion が に集計した値です。上流の更新は数日おきなので、前日比ではありません。GitHub star と最終更新は に GitHub から取得しました。
併用すると強いスキル
よくある質問
仕事の数はどう数えればいいですか
人が名前で呼ぶ仕事 1 つを 1 つと数えます。1 つの要求の処理の中にある 10 か所の呼び出しは 1 つ、共通の部品を 3 つの仕事が使っていれば 3 つです。名札は共通の部品ではなく、呼び出す側に付けます。
名前は後から変えられますか
変えることはできますが、本文は名前を「ほぼずっと使うもの」と考えるよう書いています。変えると、その仕事の費用の履歴が古い名前と新しい名前に割れるからです。迷う名前には「review」の印を付けて、人の判断に回します。
確かめで 400 が返りました
ゲートウェイが名前を受け付けなかった場合で、エラーは cave_invalid_request_header です。名前が小文字の英数字と _ - の 1〜96 文字になっているかを確かめて直します。
Codex でも使えますか
使えます。Caveman の CLI の文書は、caveman setup --agent-native codex（Claude Code なら claude）で、このスキルを含む一式を Codex か Claude Code に組み込む手順を載せています。