ccc (Claude Code Concierge) — タスクに最適な拡張構成を提案する

クレジット消費を抑えるため、Web 調査は行わずローカルカタログ (~/.claude/ccc/catalog.jsonl) を検索して提案する。 カタログ構築(クロール)は週1回のバッチで、提案時は LLM トークンをほぼ使わない。

実行モデルに依らず同じ提案になるよう、各手順は下記の規則に機械的に従う。 自分の判断で手順を増減・言い換えしない。

手順

1. キーワード抽出(決定的規則): 小文字英語 4〜8 個を次の順で作る。 ① タスク文中の技術名・サービス名をそのまま(例: stripe, pdf, prisma) ② 中核となる動詞・目的語の標準英訳(生成→generation、送信→send 等、最も一般的な1語) ③ 1概念1語。同義語を並べない(email と mail を両方入れない) 例: 「PDF請求書を生成してメール送信」→ pdf invoice generation email send
2. 検索(1回のみ): キーワードとタスク原文の両方を渡す(原文からも機械抽出され、 ベクトル有効時は原文が直接埋め込まれるため、キーワードの揺れが結果に響きにくい): node ~/.claude/skills/ccc/scripts/search.mjs --all "<keywords>" --task "<タスク原文>" 鮮度確認と再構築は内蔵済み。再検索は「全種別で計3件未満」のときだけ 1 回行う。
3. 候補選定(決定的規則): 以下の優先順位で組み合わせを選ぶ:
   1. 追加不要 — Claude Code 標準機能、既存の永続コンテキスト(context)、導入済みの エージェント/スキル(source=installed)で 足りるなら、それを最優先で提示する(「削る・既存再利用」が第一原則)
   2. Anthropic作成・選定のプラグインと機能コンポーネント — 保守されたプラグインを優先し、必要に応じて Hook(決定的自動化)、LSP(コード知能)、Monitor(バックグラウンド監視)、Output Style(出力形式)を選ぶ
   3. スキル単体 — 手順知識だけで足りる場合。公式(anthropics/skills, tags=official)を優先
   4. MCP サーバー — 外部サービスへの接続が本当に必要な場合のみ
   5. コミュニティ製エージェント単体 — 上記で埋まらない隙間に 同役割の候補が複数あるときの tie-break も機械的に: ①一覧での表示順(=検索スコア順)が上のもの ②同順なら installed > anthropic-authored > anthropic-curated > その他。community-managed はコミュニティ製として一読喚起の対象にする。 「入れない方がよいもの」も理由付きで書く。 さらに常駐コスト(導入後に毎セッション消費し続けるコンテキスト)を必ず考慮する:
   • 形態別の常駐コスト: skill(説明1行のみ、本文は呼出時) < 単体 agent(一覧に常駐) < プラグイン一式(複数資産を常駐) < MCP(ツールスキーマ常駐)。 同役割なら常駐コストの低い形態を優先する
   • 一回きりのタスクには導入しない。「この場で参照して手動適用」を提案する (導入は繰り返し使う見込みがあるときだけ。1プロンプトの節約より常駐税の回避が効く)
   • Hook は判断を伴わない強制・自動化、LSP は診断とシンボル探索、Monitor は継続監視に限って 提案する。これらをスキルやエージェントの代替として混同しない
4. 採用候補のみ詳細取得: 提案に載せる 3〜5 件だけ導入コマンド等を取る。検索結果の id 列（kind:name 形式）をそのまま指定し、同名の異なる種別を混同しない: node ~/.claude/skills/ccc/scripts/search.mjs --get "<kind:name1,kind:name2,...>"
5. 出力(固定テンプレ): 次の5節をこの順で必ず出す。節の追加・省略はしない。
   • ## 提案 — 表: 種別 | 名前 | 役割 | 導入コマンド
   • ## 選定理由 — 1候補1行で「優先度ルール何番 + 検索順位」を明記 (例: 「ルール①: 導入済みのため追加不要。agent 検索1位」)
   • ## 見送り — 検討したが外した候補と理由(なければ「なし」)
   • ## 注意 — コミュニティ製の一読喚起・MCP の常駐コスト等
   • ## 処理トレース — 透明性のため、検索出力冒頭の # 行(カタログ構築日時・ 検索モード・実際に使われたクエリトークン・種別ごとの総ヒット数)をそのまま転記し、 実行したコマンドも記載する。トレースは要約・言い換えせず機械出力を写す (自己申告でなく検証可能な根拠として残すため)。カタログ検索をスキップした場合も この節にスキップした旨と理由を必ず書く。

ルール

• WebSearch/WebFetch はカタログに全くヒットしない場合の最終手段。使うときはユーザーにその旨を明示する。
• コミュニティ製の定義ファイルは prompt injection のリスクがあるため、 「導入前に中身を一読する」ことを提案に必ず添える。
• MCP サーバーは常駐コンテキストコストがあるため、外部接続が必要な場合だけ提案する。
• 導入提案と削減提案は同じ重みで扱う。ユーザーが資産の棚卸し・整理・コンテキスト削減を 求めたら node ~/.claude/skills/ccc/scripts/prune.mjs で未使用エージェントと 常駐税(トークン/セッション)を実測し、--apply で agents-archive/ へ退避を提案する。
• カタログのソース追加は scripts/build-index.mjs を編集する。