Claude Media
everything-claude-codeの構成を読み解く — agents・skills・hooks・rules
Claude Code解説

everything-claude-codeの構成を読み解く — agents・skills・hooks・rules

GitHubで27万star超の設定集everything-claude-code(現ECC)は、agents・skills・hooks・rulesをどう分けて持つのか。リポジトリ構成と取り込み方を読み解きます。

読了目安 約16分

everything-claude-codeは、Claude Codeの設定一式をまるごと1つのリポジトリにまとめた第三者製のオープンソースです。READMEの自己紹介によると、作者はAnthropicとForum Venturesのハッカソンで2025年9月に優勝しており、その運用で磨いた設定を公開したものです。以下の記述は、特に断らない限りこのREADMEに基づきます。現在のリポジトリ名はaffaan-m/ECCで、旧名のURLからリダイレクトされます。プロジェクト名もECCに改まっています。

ECCは第三者のコードなので、自分の環境で何が動くかは、取り込む前に中身を読んで確かめる必要があります。以下では構成と取り込み方を順に示します。

ECCとは何か — 設定集というより「道具箱」

ECCは「agent harness performance optimization system」を名乗ります。Claude Code向けのagents、skills、hooks、rulesを同梱し、Codexや各種エディタ向けのアダプターも持ちます。MITライセンスで、Claude Codeでの利用が最も作り込まれています。

規模は冒頭の表記で、68のagents、293のskills、94のcommandsです。注釈付きカタログには「67 specialized subagents」と書かれた箇所もあり、agentsの数は節によって1つずれています。

数字

READMEが示す同梱物の規模

  • agents

    68

    計画・レビュー・ビルド修復など

  • skills

    293

    TDD・セキュリティ・調査など

  • commands

    94

    skills中心への移行期の入口

READMEの冒頭表記。注釈付きカタログではagentsが67と書かれた箇所があります

数字より重要なのは設計の考え方です。中心にあるのは「plan → test → implement → review → verify → remember → improve」という流れです。毎回のプロンプトで手順を組み直す代わりに、一度入れて作業の型にすることを狙いとしています。

リポジトリの構成 — 役割ごとに6つのディレクトリ

ルートは次の役割で分かれています。

ディレクトリ役割
agents/役割委任先になる専門サブエージェント
skills/役割必要になったときに読み込まれる手順書
commands/役割スラッシュコマンドの互換入口
rules/役割常時読み込まれる規約(言語別)
hooks/役割ツール実行などのイベントで走る自動処理
.claude-plugin/役割Claude Codeのマーケットプレイス用マニフェスト

このほか、インストーラーや検査を置くscripts/、Codex・OpenCode・Cursor向けの.codex/・.opencode/・.cursor/があります。ルートが唯一の正で、各プラットフォーム向けは同じ内容を包装または対応づけたものです。Claude Code用に作った資産を他のツールへ流用する設計です。

4種類の部品はコンテキストに載る時期が違う

「Skills keep the context focused」の表が、構成を読む鍵になります。同じ「設定」でも、いつモデルの目に入るかが部品ごとに違います。

役割分担

部品ごとのコンテキストの扱い

  • skills

    TDDやセキュリティレビューのような再利用できる手順です。作業に必要になったときに読み込まれます。

  • agents

    独自のコンテキストとツール権限を持つ作業者です。計画・実装・レビューを分離します。

  • rules

    プロジェクトや言語の恒久的な基準で、常時読み込まれます。入れる数は絞るのが前提です。

  • hooks

    ハーネスのイベントで動くスクリプトです。モデルのコンテキストの外で実行されます。

rulesが常時読み込みになる点は、Claude Code側の仕様とも一致します。Claude Codeは.claude/rules/の.mdファイルを再帰的に探し、~/.claude/rules/に置いた個人用の規約はどのプロジェクトにも適用します。分量を増やすほど毎回のコンテキストを食うので、commonと自分の言語1つから始めるのが現実的です。

agents — 1ファイル1役割のサブエージェント

agentsは、次の形のmarkdownです。

---
name: code-reviewer
description: Reviews code for quality, security, and maintainability
tools: Read, Grep, Glob, Bash
model: opus
---
 
You are a senior code reviewer...

カタログにはplanner.md、architect.md、tdd-guide.md、code-reviewer.md、security-reviewer.md、build-error-resolver.mdといった汎用の役割が並びます。加えて、python-reviewerやgo-reviewer、rust-build-resolverのような言語別のレビュー担当とビルド修復担当が続きます。同梱のagentにはmodelが書かれているものがあるため、取り込む前に自分の契約や既定モデルと合うかを見ておくと、想定外のモデルで動く事態を避けられます。

skills — 領域別に293本

skillsは「TDD、調査、セキュリティ、ドキュメント、フロントエンド、データ、ML、運用」に及びます。カタログにはtdd-workflow、security-review、verification-loop、search-firstのような工程系のskillが並びます。一方でdjango-patterns、springboot-tdd、laravel-securityのように、フレームワーク別にpatterns・security・tdd・verificationを揃えた系列もあります。TDDの例は次の流れです。

/ecc:plan "Add usage-based billing alerts"
  -> 計画を確認・編集
  -> tdd-workflowを有効化
  -> 実装前にREDの証拠を取る
  -> GREENになるまで実装
  -> 新しいコンテキストでレビュー
  -> 指摘を回帰テスト付きで修正
  -> ビルド・lint・型・テストを検証

成果物はコードだけでなく、「計画、失敗するテスト、通るテスト、レビュー指摘、最終検証」という証跡の列として残ります。

hooks — 定義はhooks.json、実装はNodeスクリプト

hooksは、hooks/hooks.jsonに全イベント(PreToolUse、PostToolUse、Stopなど)の設定を置き、実装をscripts/hooks/のNode.jsスクリプトに分ける構成です。セッション開始時にコンテキストを読み込むsession-start.js、終了時に状態を保存するsession-end.js、圧縮前のpre-compact.js、圧縮を提案するsuggest-compact.jsなどが挙がっています。

説明用の例は、JSやTSのファイルを編集したときにconsole.logの残りを警告するものです。matcherでツール名とファイルパスを絞り、コマンドで検査する書き方になっています。編集時の検査を別の形で書く方法は、hookifyの解説にあります。

rules — commonと言語別に分かれる

rules/はcommon/(言語非依存の原則)と、typescript/、python/、golang/、swift/、php/、arkts/の言語別に分かれます。common/にはcoding-style.md、git-workflow.md、testing.md、security.mdなどが入っています。testing.mdの要点は「TDD、80%カバレッジ」です。

自分の環境に取り込む3つの道

取り込みの道はハーネスごとに1つに絞ります。複数の方法を重ねると、skillsやhooksが二重に入ります。

くらべる

Claude Codeへの取り込み方

READMEの推奨

ガイド付きセットアップ

npx ecc-universal@2.2.3 setupで対話的に進めます。スコープ(ユーザー・プロジェクト・ローカル)とhookプロファイルを選び、ウィザードが既存のインストールを確かめてから反映します。

Claude Code標準

ネイティブのプラグインコマンド

/plugin marketplace addでリポジトリを登録し、/plugin install ecc@eccで入れます。skills・agents・commands・hooksがプラグイン経由で入り、rulesだけは別に手で置きます。

最小構成向け

手動で必要な部品だけ

agents/*.md、rules/、skillsを自分の~/.claude/配下へコピーします。hooksを入れないので、一番影響範囲が小さくなります。

プラグインとして入れる手順

Claude Code側の仕様から見ると、/plugin marketplace addはGitHubのowner/repo形式やGitのURLを受け付け、登録後に/plugin installで入れる流れです。ECCのREADMEが示すコマンドは次のとおりです。

/plugin marketplace add https://github.com/affaan-m/ECC
/plugin install ecc@ecc

識別子が3つあることには注意が要ります。GitHubのソースはaffaan-m/ECC、マーケットプレイスとプラグインの識別子はecc@ecc、npmパッケージはecc-universalで、互いに置き換えられません。古い記事に旧名が残っていても、旧名は過去の別名にすぎません。

settings.jsonに宣言で書く方法もあります。READMEの例を引くと、次の2つのキーで/pluginの2コマンドと同じ結果になります。

{
  "extraKnownMarketplaces": {
    "ecc": {
      "source": { "source": "github", "repo": "affaan-m/ECC" }
    }
  },
  "enabledPlugins": { "ecc@ecc": true }
}

Claude Codeのドキュメントでも、enabledPluginsとextraKnownMarketplacesはsettings.jsonに置くキーとして挙げられています。

rulesだけは手で置く

Claude Codeのプラグインはrulesを配布できないため、必要な分だけを手でコピーします。

git clone https://github.com/affaan-m/ECC.git
cd ECC
mkdir -p ~/.claude/rules/ecc
cp -R rules/common ~/.claude/rules/ecc/
cp -R rules/typescript ~/.claude/rules/ecc/  # 自分の言語に置き換え

特定のリポジトリにだけ効かせたいなら、コピー先を.claude/rules/ecc/に変えます。コピーするときは、ファイルではなくディレクトリごと(rules/common)にします。相対参照を保つためです。

手動でコピーするときの注意

手動で取り込む場合、skillsは~/.claude/skills/<skill名>/の直下に置きます。~/.claude/skills/ecc/のような入れ子にはしません。

mkdir -p ~/.claude/agents
cp agents/*.md ~/.claude/agents/
 
mkdir -p ~/.claude/skills
cp -r skills/search-first ~/.claude/skills/

hooksを手動で入れる場合は、hooks/hooks.jsonをsettings.jsonへそのまま貼らず、インストーラー経由で入れます。このファイルはプラグインとリポジトリ向けで、コマンドのパスはインストーラーが書き換える前提だからです。プラグインで入れた場合も、hooksをsettings.jsonに重ねるとhookが二重に走ります。

hooksを入れる前に決めておくこと

hooksは、取り込む部品のなかで最も影響範囲が大きい部分です。ツールの実行前後に任意のスクリプトが走るので、何が自分の環境で動くのかを先に把握しておく必要があります。

判断材料は3つあります。

  • フック抜きの最小構成: npx ecc-universal@2.2.3 install --profile minimal --target claudeは、hooks-runtimeを含まないプロファイルです
  • 明示的な決定: hookのランタイムを含むインストールは、--enable-hooksか--no-hooksの指定がないと、できることを表示して書き込む前に止まります
  • 後から追加: ./install.sh --target claude --modules hooks-runtime --enable-hooksで、あとからランタイムだけ足せます

バージョンを固定しても、「固定はセキュリティ監査でも整合性検査でもない」点は変わりません。実行前に、リリースの中身とレジストリの整合性を自分で確かめる前提です。この考え方は、外部の設定を取り込むすべての場面に当てはまります。同じ観点で隔離環境を設計する例は、devcontainerのinit-firewall.shにあります。

取り込みの前後で見ておく点

導入後にやることは、取り込み方に関係なく共通です。順に並べると次のとおりです。

手順

導入後の確認の流れ

  1. 1

    読み込み状況を確かめる

    新しいセッションを開き、/plugin listでecc@eccが有効かを見ます。READMEが導入直後の確認として示している手順です。

  2. 2

    重複がないか見る

    READMEのトラブル対処に従えば、二重の導入で重複が疑われるときはlist-installed、doctor、repairの順に実行します。

  3. 3

    撤去の経路を把握する

    uninstall --dry-runで消える対象を確かめてから、uninstallを実行します。消えるのはインストール状態に記録されたファイルだけで、無関係なファイルには触れません。

一覧で確かめるコマンドの例は次のとおりです。

npx ecc-universal@2.2.3 list-installed
npx ecc-universal@2.2.3 doctor
npx ecc-universal@2.2.3 uninstall --dry-run

全部は入れず、段階的に取り込む読み方

方針は「Start with the workflow you need, not the full catalog」(全カタログではなく、必要なワークフローから始める)です。293のskillsと68のagentsを一度に入れても、使わない部品の説明文までが候補としてモデルに見え続けます。「Platform Support」の表も、Claude Code向けのプラグインはインストールした一式をモデルに知らせるため、コンテキストの大きさが気になるなら、選択式または手動のプロファイルを使うよう書いています。

影響範囲の小さい部品から順に足すと、問題が起きたときに原因を絞りやすくなります。取り込みの順は次の流れが組みやすいでしょう。

  1. 自分が使う言語のrules/commonと言語別の1つだけを置く
  2. code-reviewerなど、レビュー系のagentを数本だけ入れる
  3. 使う場面が決まったskill(tdd-workflow、security-reviewなど)を個別に足す
  4. hooksは最後にして、最小のプロファイルで動作を観察してから広げる

hooksの失敗時の扱いを自分で決めたいなら、失敗したhookで操作を止められるようになったClaude Code v2.1.295のonFailureも、取り込む前の判断材料になります。

今も動いているプロジェクトとしての注意点

リリース2.2.3は2026年10月1日付で、2.2系の中心はガイド付きセットアップ、doctor、repair、uninstallです。一方、Windowsネイティブでは継続学習のobserverデーモンなどに未解決の不具合が表に載っており、プラットフォームごとに機能の完成度が揃っていません。

次の点は取り込み前に目を通す価値があります。

  • MCPの扱い: プラグインで入れてもMCPサーバー定義は自動では有効にならず、必要なものを自分で足す仕組みです。同梱の既定コネクターはchrome-devtoolsの1つだけです
  • マルチモデル系のcommands: /multi-planなどは別途ccg-workflowの実行環境が必要で、基本のプラグインやrulesの導入だけでは動きません
  • 設定自体の検査: 同梱のAgentShieldは、プロンプト、hooks、MCP設定、権限、秘密情報を走査します

まとめ

ECCの構成は、「常に読むrules、必要なときだけ読むskills、役割を分けて動くagents、コンテキストの外で走るhooks」という4層の分担として読めます。取り込むなら、プラグインでskillsとagentsを入れ、rulesを手で足し、hooksは最小構成から試す、という段階が、影響を見極めやすい組み合わせです。数が多い分、全部ではなく自分の作業に合う部品だけを選ぶことが、この設定集をいちばん活かす使い方になります。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →