mcpField
C
cavecrew

cavecrew

github.com/rheinmirエージェントワークフロー10262 回インストール2 週間前に更新
リポジトリ

cavecrew について

cavecrewは、コード調査、小規模な編集、レビュー向けの3種類のサブエージェント設定を提供し、圧縮した構造化形式で結果を返します。メインエージェントのコンテキスト使用量を抑えたい委任作業に適しています。

主な機能

  1. 01調査・ビルダー・レビュアーの設定
  2. 02圧縮された構造化サブエージェント結果
  3. 03ファイルパスと行番号付きの調査結果
  4. 04検証状況付きの範囲限定編集
  5. 05ファイルと行番号順のレビュー指摘

活用シーン

  1. 01定義や呼び出し元の特定
  2. 02範囲が明確な小規模編集の委任
  3. 03コード差分のバグ確認
  4. 04コードベースの並行調査

インストール

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

$npx skills add https://github.com/rheinmir/setup --skill cavecrew

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

詳細

Cavecrew は、洞人風の出力を生成する 3 つのサブエージェントプリセットです。Anthropic のデフォルト(Explore、編集スタイルのエージェント、レビュアー)と同じ役割を担います。違いは、返されるツール結果が圧縮されるため、委任ごとにメインコンテキストの消費量を抑えられることです。

cavecrew と代替手段の使い分け

タスク使用するもの
「X はどこで定義されているか/Y を呼び出しているのは何か/Z の使用箇所を列挙」cavecrew-investigator
同じ調査だが、提案やアーキテクチャに関するコメントも必要Explore(標準)
対象範囲が明確な、2 ファイル以内の局所的な編集cavecrew-builder
新機能/3 ファイル以上/横断的なリファクタリングメインスレッドまたは feature-dev:code-architect
差分、ブランチ、ファイルのバグをレビューcavecrew-reviewer
根拠と代替案を含む詳細なコードレビューCode Reviewer(標準)
答えがすでにわかっている一行の質問サブエージェントを使わず、メインスレッド

目安:サブエージェントの出力を 1/3 のトークン数で得たいなら cavecrew を選びます。文章による説明が必要なら標準のものを選びます。

なぜこれがあるのか(実際の利点)

サブエージェントのツール結果は、そのままメインコンテキストに挿入されます。文章 2,000 トークンを返す標準の Explore は、実行するたびにメインコンテキストの予算を 2,000 トークン消費します。同じ調査結果でも、cavecrew-investigator なら約 700 トークンで返します。1 回のセッションで 20 回委任した場合、この差によってコンテキスト不足になるか、タスクを完了できるかが決まります。

出力仕様

各エージェントについて、メインスレッドが期待できる内容:

cavecrew-investigator

<Header>:
- path:line — `symbol` — short note
totals: <counts>.

または No match.。常にファイルパスを先頭にし、行番号を付け、シンボルをバッククォートで囲みます。path:\d+ で安全に grep できます。

cavecrew-builder

<path:line-range> — <change ≤10 words>.
verified: <re-read OK | mismatch @ path:line>.

または次のいずれか:too-big. / needs-confirm. / ambiguous. / regressed.(先頭のトークンで状態を示します)。

cavecrew-reviewer

path:line: <emoji> <severity>: <problem>. <fix>.
totals: N🔴 N🟡 N🔵 N❓

または No issues.。指摘事項はファイル、次に行番号の昇順で並びます。

連携パターン

場所を特定 → 修正 → 検証(最も一般的):

  1. cavecrew-investigator が該当箇所の一覧を返します。
  2. メインスレッドが 1~2 箇所を選び、パスを cavecrew-builder に渡します。
  3. cavecrew-reviewer が差分を監査します。

並行して調査(調査範囲が広い場合): 1 つのメッセージで cavecrew-investigator を 2~3 回呼び出します(定義、呼び出し元、テストなど、それぞれ異なる観点で)。メインスレッドで結果をまとめます。

単発の編集(対象箇所がすでにわかっている場合): investigator は使わず、正確な path:line を直接 cavecrew-builder に渡します。

やってはいけないこと

  • ファイルがわからない状態で cavecrew-builder を使わないでください。先に investigator を呼び出してください。そうしないと、メインスレッドでコンテキストを渡すためにトークンを消費します。
  • 5 ファイルのリファクタリングで cavecrew-investigator → cavecrew-builder と連携しないでください。builder は too-big. を返すため、1 ターン無駄になります。
  • cavecrew-reviewer に「全般的なフィードバック」を求めないでください。指摘事項だけを返し、アーキテクチャに関する意見は返しません。その場合は Code Reviewer を使ってください。
  • 文章での説明を期待しないでください。Cavecrew の出力は構造化されており、ときには極端に簡潔で、意味を読み取りにくいことがあります。人が直接読む場合は、言い換えてください。

自動的な明瞭化(継承)

セキュリティ警告、取り消せない操作の確認、断片的な表現だと誤解される可能性のある出力では、サブエージェントは洞人風の表現から通常の英語に切り替えます。その後、洞人風の表現に戻ります。


出力レポート

メインスキルのタスクがすべて完了したら、wiki にドラフト案を書きます。

手順

1. ファイル名を作成します:

  • 形式:DDMMYY-<ten>.md
  • DDMMYY = 今日の日付(例:2026 年 6 月 2 日なら 020626)
  • <ten> = 実施内容を要約する 2~4 語の kebab-case(例:landing-page-coteccons、brand-kit-fintech、ingest-auth-spec)

2. llmwiki/wiki/draft/cave/DDMMYY-<ten>.md に書き込みます:

# DDMMYY-<ten>
**Type:** draft
**Status:** proposed
**Tags:** <skill-name>, output-report
**Proposed:** YYYY-MM-DD

## What
<One sentence — what this skill invocation produced or decided>

## Output
<Key artefacts, files created/modified, or decisions made>

## Files
| File | Action |
|------|--------|
| `path/to/file` | created / modified |

## Notes
- Invoked via: `/<skill-name>` skill

## Origin
- **Draft:** `wiki/draft/cave/DDMMYY-<ten>.md`
- **Commit:** _(filled by verify-before-commit)_
- **Date promoted:** _(filled by verify-before-commit)_

3. wiki のインデックスとログを更新します:

  • llmwiki/wiki/index.md — 次の 1 行を追加します:| [DDMMYY-<ten>](draft/cave/DDMMYY-<ten>.md) | draft | YYYY-MM-DD |
  • llmwiki/wiki/log.md — 次の行を追加します:## YYYY-MM-DD — <skill-name> — <ten>

スキルが成果物も判断事項も生成しない場合に限り、スキップします(例:/caveman-stats のような表示専用モード)。

コメント