mcpField
C
caveman-evidence-review

caveman-evidence-review

github.com/juliusbrusseeデータ・データベース115.8k107.3k 回インストール3 日前に更新
リポジトリ

caveman-evidence-review について

caveman-evidence-reviewは、現在のCavemanプロジェクトデータを読み取り専用で確認するスキルです。コストと節約の区分を分け、範囲を限定したトレースを検索し、通常はペイロードを取得せずに結果を報告します。

主な機能

  1. 01現在のプロジェクトレポートを参照
  2. 02コストと節約の区分を維持
  3. 03条件を限定してトレースを検索
  4. 04ペイロードなしでトレースメタデータを確認
  5. 05トレースIDと時間範囲を明記

活用シーン

  1. 01プロジェクトのコストと節約の証拠を確認
  2. 02範囲を限定したトレースを調査
  3. 03ペイロードを開示せずに結果を報告

MCP 対応

このスキルはCaveman MCPツールの利用を優先します。caveman_context、caveman_report、caveman_plan、caveman_trace_search、caveman_trace_getなどを使い、CLIコマンドを代替手段として記載しています。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/juliusbrussee/caveman --skill caveman-evidence-review

インストール後、Claude Code で/caveman-evidence-reviewを入力して読み込まれたか確認します。

詳細

Caveman のエビデンスを確認する

読み取り専用のオペレーターとして行動します。リポジトリに関する推測ではなく、現在の Caveman データから結論を導きます。このスキルから実験を開始、承認、キャンセル、ロールバックしてはいけません。

厳守するルール

  1. 次の区分を混同しないでください。
    • プロバイダー完了ベースで測定したリスト価格のコスト
    • inferred の日次ヘッドルーム
    • verified の台帳上の節約額
    • エビデンスのコスト 決して合算したり、別の区分として扱ったりしないでください。
  2. ユーザーがペイロードの確認を明示的に求めない限り、プロンプト、完了、ツール、アーティファクトのペイロードを取得してはいけません。通常の確認では、メタデータ、スパン、タイミング、モデル、トークン数、ステータス、オプティマイザーの帰属情報で十分です。
  3. すべての読み取りを、Caveman のコンテキストで選択されたプロジェクトに限定してください。組織 ID は指定しないでください。
  4. 結果が空でも、それは現在シグナルがないことを示すエビデンスであり、コストやリスクがゼロであることを意味しません。
  5. 使用したトレース ID と正確な時間範囲を明記してください。集計値だけを根拠に原因を主張してはいけません。

ステップ 1 — コンテキストを読み込む

MCP を優先します。

caveman_context {}

CLI の代替手段：

caveman cloud whoami
caveman cloud projects list

ログインまたはプロジェクトの選択が済んでいない場合は中止します。ユーザーに caveman login を実行するか、プロジェクトを選択するよう依頼してください。推測してはいけません。

ステップ 2 — ベースラインを確立する

caveman_report を使って、次の項目を確認します。

  • overview
  • costs
  • score
  • workflows
  • verified_savings

次に、caveman_plan を使って、日次ヘッドルームを順位付けします。質問の範囲が狭い場合は、無関係なレポートを省略してください。回答に必要な最小限の情報を読み取ります。

CLI の代替手段：

caveman cloud costs
caveman cloud score
caveman cloud plan --json

傾向を解釈する前に、レポートの期間と算出根拠を明示してください。

ステップ 3 — トレースで有力な説明を検証する

caveman_trace_search を使います。期間を限定し、ワークフロー、エージェント、モデル、プロバイダー、エラーコード、ランタイムモード、キャッシュ状態、最適化 ID、ステータスクラス、トークン数・コスト・レイテンシの範囲、圧縮、モニターの判定など、条件を明確に指定して絞り込みます。

役立つグループ化：

  • workflow — コストや失敗を引き起こしているジョブを特定する
  • model — モデルの構成を比較する
  • session — 再試行やループの挙動を切り分ける
  • グループ化なし — 個別のトレースを特定する

疑わしいコホートを、対照コホートまたは期間を限定した過去のデータと比較します。コストの高いトレースを 1 件見ただけで因果関係を推測してはいけません。

CLI の代替手段：

caveman cloud traces search \
  --workflow <slug> \
  --from <RFC3339> \
  --to <RFC3339> \
  --sort total_cost_usd \
  --dir desc \
  --limit 25

ステップ 4 — 代表的なトレースを確認する

シグナルが強い少数のトレース ID について、caveman_trace_get を呼び出します。リクエストとスパンのメタデータ、レイテンシ、ステータス、トークン数、キャッシュ状態、適用されたオプティマイザー、モデルのルートを確認します。ペイロードの取得は無効のままにしてください。

CLI の代替手段：

caveman cloud traces show <trace-id> --spans

ステップ 5 — 報告する

次の形式を使います。

## Caveman evidence review

Scope: <project> · <from> to <to>
Measured cost: <value and basis>
Verified savings: <ledger value, kept separate>
Inferred headroom: <per-day band, kept separate>

Findings:
1. <finding> — <aggregate evidence> — traces <ids>
2. <finding> — <aggregate evidence> — traces <ids>

Unproven:
- <plausible explanation lacking a control, trace, or eval>

Next read-only check:
- <one bounded query>

Possible action:
- <proposal only; use caveman-manage for read-only lifecycle review and safety gate>

データが不足している場合は、欠けているシグナルを明示し、裏付けられる最も強い主張の範囲で止めてください。カタログの小計を請求額として扱ったり、実験結果を検証済みの節約額として扱ったりしてはいけません。

コメント

Markdown 対応