Claude CodeやCodexのskill集が、この数か月で異様に伸びています。現時点では
obra/superpowers が26万スター affaan-m/ECC が23万スター mattpocock/skills が18.8万スター
日本語の紹介記事はどれも個別に書かれていて、「排他ではないので両方読むと効果的」といった一文で併用に触れているものが多々ありましたが、実際に3つとも入れて確かめた記事が見つかりませんでした。
そこで同じプロジェクトへ順に重ねて入れ、同じバグ修正をさせてみました。
結論
- 3つ同時に入れても衝突しません。スキル名称がぶつからないうえ、そもそも動かし方が違うので競合しません
- 選ぶ基準は性能ではありません。入れっぱなしにしたいのか、
/を打って呼びたいのかで決まります - superpowersが謳う「自動で動くから何もしなくていい」は、7回試して2回しか起きませんでした
この記事は、すでにskillを入れていて他も足すべきか迷っている人向けではありますが、結果として導入を考えている方にも有益だと思います。
そもそもskillとは何か
先に前提を揃えておきます。
skillは、AIに読ませる手順書です。SKILL.md というファイル1枚に「こういうときはこう進めろ」と書いておくと、AIがそれに従って動きます。公式ドキュメントの説明はこうです。
Create a
SKILL.mdfile with instructions, and Claude adds it to its toolkit. Claude uses skills when relevant, or you can invoke one directly with/skill-name.
大事なのは動かし方が2通りあることです。
- AIが自分で判断して起動する（勝手に使ってくれる）
- 人が
/スキル名称と打って起動する（明示的に呼ぶ）
今回の3つは、このどちらを前提にしているかが違いました。それが記事の結論に直結します。
そして「skill集を入れる」というのは、こうした SKILL.md が何十個〜何百個も入ったフォルダを、自分のプロジェクトに置くことを指します。今回は3つを重ねて置いていきました。
| 構成 | 中身 | skillの数 |
|---|---|---|
| A | superpowers だけ | 14 |
| B | A ＋ mattpocock | 51 |
| C | B ＋ ECC | 330 |
なお構成CのECCは全部入れていますが、ECCは本来、用途別に構成を選んで入れるものでした。これは検証したあとに気づいた点で、後半で改めて触れます。
3つとも入れてもスキル名称は衝突しない
まず心配になるのは「同じスキル名称のskillがぶつかるのでは」という点です。
全部のスキル名称を突き合わせました。
| skillの数 | 他の2つとのスキル名称の重複 | |
|---|---|---|
| superpowers | 14 | 0件 |
| mattpocock/skills | 37 | 0件 |
| ECC | 279 | 0件 |
3つの間で同じスキル名称は1つもありませんでした。
330個を1つのフォルダにまとめても、上書きは起きません。
公式ドキュメントでも、プラグインとして入れる限り仕組みの上でも衝突しないと書かれています。プラグイン経由なら superpowers:tdd のように提供元の名前が頭に付くためです。
Plugin skills use a
plugin-name:skill-namenamespace, so they cannot conflict with other levels.
ただし短い呼び方は、導入が先のものが対象になる
注意点が1つあります。上のように頭に提供元が付く一方で、短い /tdd という打ち方も使えます。そしてこちらは早い者勝ちです。
The bare
/fancyalso invokes the skill unless another command already uses that name.
つまり /tdd と打ったとき、そのスキル名称をすでに別のskillが使っていたら、後から入れた方は反応しません。
呼びたい方を確実に動かすには mattpocock-skills:tdd のように提供元込みで打つ必要があります。
3つとも似た内容のskillを持っているので、これは実際に起こります。
スキル名称は違っても、役割は6つの領域で被る
スキル名称がぶつからないことと、役割が重複しないことは別の話です。
| 領域 | superpowers | mattpocock | ECC |
|---|---|---|---|
| テスト先行開発 | test-driven-development | tdd | tdd-workflow ＋言語別5種 |
| コードレビュー | requesting-code-review / receiving-code-review | code-review | security-review 他 |
| デバッグ | systematic-debugging | diagnosing-bugs | agent-introspection-debugging |
| 完了前の確認 | verification-before-completion | — | verification-loop ＋言語別4種 |
| 計画立て | writing-plans / executing-plans | — | plan-canvas / plan-orchestrate |
| 調査 | — | research / grill-with-docs | deep-research / research-ops |
同じ仕事に対して、2〜3通りの手順書が同時に置かれることになります。
決定的な違いは、動かし方だった
ここが今回いちばんの発見です。3つは同じ土俵にいません。
skillの設定には、AIが自分で起動するのを禁止する項目があります。
| 前提 | 自分から起動しない設定のskill | |
|---|---|---|
| superpowers | AIが勝手に起動 | 0 / 14 |
| mattpocock/skills | 人が / で呼ぶ | 24 / 37 |
| ECC | 両方 | 0 / 279 |
superpowersのREADMEはこう書いています。
because the skills trigger automatically, you don’t need to do anything special. Your coding agent just has Superpowers.
一方 mattpocock は37件中24件を「AIからは起動できない」設定にしていて、/スキル名称 と打つまで動きません。
READMEも /setup-matt-pocock-skills、/grill-with-docs、/tdd とコマンド中心の書き方です。
つまり superpowersは裏で走らせる道具、mattpocockは呼んで使う道具。superpowersを入れたまま /tdd と打てば後者が動きます。
競合しないのは当たり前で、そもそも用途が違います。
skill同士の参照も、それぞれの中で閉じている
skillの本文が他のskillを名指しすることがあります。「このあと test-driven-development を使え」といった具合です。この参照関係も数えました。
| 参照する側 | 同じ配布元のskillへ | 他の配布元のskillへ |
|---|---|---|
| superpowers | 19 | 0 |
| mattpocock/skills | 27 | 0 |
| ECC | 505 | 1 |
ECCの1件だけが例外で、click-path-audit というskillが superpowers を名指ししています。
Run AFTER
/superpowers:systematic-debuggingRun BEFORE/superpowers:verification-before-completion
279個のうち1個だけが併用を想定して書かれている、という状態です。
同じバグを9回直させた
静的に調べるだけでは「入れたらどうなるか」は分かりません。バグを仕込んだプロジェクトを用意して、構成を変えながら実際に走らせました。
課題は2つ用意しました。
課題1は20行のパーサです。"1h30m" のような文字列を分に直す関数で、空文字列を渡すとエラーにならず 0 が返る、というバグを仕込みました。読めば分かる規模です。
最初はこれで確認できるかと思ったのですが、途中で「簡単すぎて手順書を使うまでもないのでは」と考え、2つ目を作りました。
課題2は通知の仕組みです。時間のかかるジョブが終わったことを、待っている画面へ一斉に知らせるコードを書きました。
- 画面は「終わったら教えて」と登録しておく
- 通知を1回受け取ったら、その登録は自動で外れる
- ジョブが終わると、登録している全員へ通知が飛ぶ
ここに、配っている最中に受け取った人の登録が外れると、リストがずれて次の人が飛ばされるというバグを仕込みました。
たとえば5つの画面が通知を待っている状態でジョブが終わると、届くのは1つ目・3つ目・5つ目だけ。2つ目と4つ目は待ちっぱなしになります。1つおきに漏れる、という症状です。
コードを読むだけでは見えません。既存テストは8件とも通ってしまいます。実際に複数の画面を登録して動かさないと出てこない、隠れたバグです。
依頼文は症状だけを伝え、どのファイルが悪いかは言わずに、毎回まったく同じにしました。
ジョブ完了の通知が、待っている全員に届かないことがあります。原因を特定して修正し、回帰テストを追加してください。毎回セッションを新しく開き、プロジェクトはgitで元の状態に戻してから走らせています。
9回の内訳
条件が2種類あるので、先に整理しておきます。
| 条件 | 依頼文 | 回数 | 何を見たか |
|---|---|---|---|
| 自動 | skill名を出さない | 7回 | AIが自分でskillを選ぶか |
| 名指し | /systematic-debugging などを指定 | 2回 | 名指しなら動くのか |
以降「7回中2回」と出てきたら自動の条件、「名指しの2回」は後半の話です。合わせて9回になります。
まず自動の7回から見ていきます。
自動で起動したのは7回中2回だった
| 課題 | 構成 | 起動したskill |
|---|---|---|
| 1（20行） | superpowers | systematic-debugging |
| 1 | superpowers | なし |
| 1 | ＋mattpocock | なし |
| 2（通知） | superpowers | systematic-debugging → test-driven-development |
| 2 | ＋mattpocock | なし |
| 2 | superpowers | なし |
| 2 | ＋ECC（330個） | なし |
7回中2回しか起動しませんでした。同じ構成・同じ課題・同じ依頼文でも結果が割れます。
設定不備ではなく、systematic-debugging の設定は、自動起動される書き方になっています。
name: systematic-debugging
description: Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes「バグやテスト失敗に出会ったら、修正案を出す前に使え」と書いてあります。
今回の依頼内容も対象に含まれるはずです。
起動しなかった回の理由は毎回同じでした。
「明示的な指示がなく、対象が2ファイル・約90行と読み切れる規模だったので、手順書の助けなしに進めた」。
skillが起動していない回がいちばん踏み込んだ
とくに示唆的だったのが、330個すべて入れた構成Cの回です。ここでも起動はしていませんでした。 AI側の説明はこうです。
該当しそうな候補として
systematic-debuggingやdiagnosing-bugsがあり、説明文だけ見れば発動条件に合致していたので呼ぶ判断もあり得た。呼ばなかったのは、対象が2ファイル・約90行と全体を直接読み切れる規模で、再現→原因特定→修正→回帰テストを手順書の助けなしに進められると判断したため。
手順書が330個そろっていて、しかも条件に合致していると自覚したうえで、使わない判断をしています。
そしてこの回は、私が仕込んでいない別のバグまで見つけました。「受け取った画面の1つがエラーを起こすと、そこで配信が止まって残りの画面に通知が届かない」というものです。私が仕込んだのとは別の道筋で、同じ「全員に届かない」症状が起きます。
さらに、これを直すのはエラーの扱い方の仕様変更にあたるとして依頼の範囲外と判断し、直さずに代案だけ添えて報告していました。skillを1つも読まずにです。
手順書を大量に積んでも使われるとは限らず、使わなくても踏み込んだ仕事はできる。
この回がいちばん端的にそれを示しています。
「難しい課題なら起動するのでは」という仮説も立てましたが、起動したりしなかったりなので、難しさでは説明がつきませんでした。
課題を増やすことでまた変化があるかもしれませんが、起動させるのが目的ではありませんでしたので、条件を増やすことはしませんでした。
名指しすれば確実に動く（残り2回）
ここからが9回のうち残り2回、名指しの条件です。
「自分から起動しないだけ」なのか「そもそも動かない」のかを切り分けるため、スキル名称を指定して試しました。superpowersに1回、mattpocockに1回です。
/systematic-debugging を使って、ジョブ完了の通知が待っている全員に届かない問題の原因を特定して修正し、回帰テストを追加してください。2回とも確実に起動しました。動かないのではなく、自分から出てこないだけです。
そして働き方がはっきり違いました。
superpowers の /systematic-debugging は、原因究明から実装まで黙って最後まで走り切ります。
動作内容ですが、まず確認用のスクリプトを書いて、5つの画面が通知を待つ状況を再現しました。そのうえで実際に届いたのは1つ目・3つ目・5つ目だけと実測し、症状を目に見える形にしてから原因の特定に入っています。修正後は同じスクリプトを流し直して、5つ全部に届くことを確かめていました。
推測で直さず、直す前と後の両方を同じ方法で測る、という進め方です。
mattpocock の /tdd は、テストを書く前に止まって聞いてきました。
回帰テストをどの層に置きますか？
- 両方（推奨） 2. 登録を受け付ける側だけ 3. 通知を配る側だけ
「確認していない場所にテストは書かない」というルールが手順書に書かれているためだそうです。さらに補助ファイルまで読み込み、テストをまとめ書きせず1本書いては1つ直す、を2周していました。
極めつけは、修正後に書いたテストについて、いったん修正を退避して本当に失敗することを確かめたことです。「バグがあっても通ってしまうテスト」でないことを自分で証明しています。
成果物をCodexに採点させた
Claudeを使用した修正をClaudeで採点するのではなく、別会社のAIであるCodexに採点させました。 どれがどの構成の結果かは伏せて、順番も入れ替えて渡しています。
対象は課題2（通知の仕組み）の6回分です。9回のうち課題1の3回は別のコードなので、同じ基準では比べられません。この6回は全部まったく同じコード・同じ依頼文に対する解答なので、横に並べられます。
採点基準は5項目、各5点の25点満点です。原因特定・修正の最小性・回帰テストの妥当性・境界条件の網羅・範囲外への目配り。
| 回 | 呼び方 | 原因特定 | 最小性 | テスト | 境界 | 範囲外 | 合計 |
|---|---|---|---|---|---|---|---|
| superpowers 自動（2件起動） | 自動 | 5 | 5 | 4 | 5 | 5 | 24 |
| ＋mattpocock 自動 | 自動 | 5 | 5 | 4 | 5 | 3 | 22 |
| superpowers 自動 | 自動 | 5 | 5 | 3 | 5 | 3 | 21 |
| ＋ECC 自動 | 自動 | 5 | 5 | 4 | 4 | 2 | 20 |
| superpowers 明示 | 明示 | 5 | 5 | 5 | 3 | 2 | 20 |
| mattpocock 明示 | 明示 | 5 | 5 | 5 | 2 | 1 | 18 |
名指しで呼んだ2回が下位です。しかも最高得点の24点は、skillが2件起動した回でした。skillの起動有無と得点に、対応は見られません。
採点基準を1項目直したら、順位が裏返った
実はこの表は2回目の採点です。1回目は名指しの2回が同点トップでした。
差が出たのは「範囲外への目配り」の項目です。最初は「依頼の範囲外を勝手に直していたら減点」と書いたのですが、これだと実装のやり方を選んだ結果ついでに直っただけのケースまで罰してしまいます。そこで「気づいて報告したかどうかで採点し、直したかは問わない」に書き換えて、新しいセッションで採点し直しました。
基準を1つ書き換えただけで、上位と下位が入れ替わります。
余談ですが、AIに採点させた比較結果は、この程度には動くという内容に過ぎません。
今回に限らず、AIの出力を別のAIに点数化させた記事を読むときは、採点基準の書き方まで見ないと意味がないと思っておいた方がよさそうです。
2回とも一貫していたのは、2項目だけ
順位は裏返りましたが、採点し直しても変わらなかった部分があります。
| 項目 | 名指しで呼んだ2回 | 自動の4回 |
|---|---|---|
| 回帰テストの妥当性 | 5、5（2回とも満点） | 2〜4 |
| 境界条件の網羅 | 2〜3 | 4〜5 |
回帰テストについて、Codexは自動で進めた4回はいずれも修正前のコードでも通ってしまうテストを含んでいる、と指摘しました。
バグを直した証拠のつもりで書かれているのに、バグがあっても通ってしまう。回帰テストとして意味がありません。
名指しで呼んだ2回には1本もありませんでした。
これは実際の進め方とも一致します。/systematic-debugging は修正前に5件が失敗することを確認してから直し、/tdd は修正を退避してまで失敗を確かめていました。
境界条件は逆です。自動で進めた回の方が広く押さえていました。名指しの2案は「配っている最中に登録を外された画面にも、その回は通知してしまう」と指摘されています。
「広く押さえた」は「余計なところまで直した」でもある
ただしこの項目、見方を変えると評価が反転します。
報告したバグ以外にも手を入れたかで並べ直すと、こうなります。
| 回 | 呼び方 | 起動したskill | 書き換えた範囲 |
|---|---|---|---|
| superpowers 明示 | 明示 | 1件 | 配信処理だけ |
| mattpocock 明示 | 明示 | 1件 | 配信処理だけ |
| ＋ECC 自動 | 自動 | 0件 | 配信処理だけ |
| superpowers 自動 | 自動 | 0件 | 内部構造・登録・解除まで |
| superpowers 自動 | 自動 | 2件 | 内部構造・登録・解除まで |
| ＋mattpocock 自動 | 自動 | 0件 | 内部構造・登録・解除まで |
上の3回は、報告した症状の原因である配信処理だけを直しています。登録と解除には指一本触れていません。
下の3回は、購読を管理するデータ構造ごと作り替え、登録と解除の挙動まで変えました。差分にはこんなコメントが付いています。
この登録だけを解除する。2回以上呼んでも他の登録には影響しない。
これは解除の仕様変更です。頼んでいません。1回目の採点でCodexも「重複登録時の解除の問題まで黙って直している」と指摘していました。
skillには「手を広げるな」と書いてある
差がはっきり出たので、使われたskillの中身を確認しました。範囲を広げることを明確に禁止していました。
superpowersの systematic-debugging は、修正の段でこう指示しています。
Implement Single Fix
- ONE change at a time
- No “while I’m here” improvements
- No bundled refactoring
「ついでにここも直す」を名指しで禁じています。原因を探す段にも「Make the SMALLEST possible change to test hypothesis」「Don’t fix multiple things at once」とあります。
mattpocockの tdd も同じ方向です。
One slice at a time. One seam, one test, one minimal implementation per cycle. Refactoring is not part of the loop. It belongs to the review stage
リファクタリングは修正のループの外、レビューの段の仕事だと切り分けています。
ただし、起動しただけでは守られなかった
ここが引っかかった点です。表の5行目、skillが2件起動した回も範囲を広げています。
起動したのは systematic-debugging と test-driven-development の2つ。後者にも同じ趣旨の記述があります。
Don’t add features, refactor other code, or “improve” beyond the test.
リファクタリングの段はあるものの、条件付きです。
After green only: Remove duplication / Improve names / Extract helpers Keep tests green. Don’t add behavior.
この回が変えたのは解除の挙動、つまり振る舞いの変更なので、この許可の範囲にも入りません。
起動した2つとも範囲拡大を禁じているのに、守られませんでした。
逆の例もあります。表の3行目、skillを1つも使っていないのに配信処理だけで収めた回があります。
つまり「skillを入れれば範囲が絞られる」ではありません。名指しで呼んだ2回だけが、書いてあるとおりに収まったというのが実際に観測できたことです。起動しただけでは効きませんでした。
これは記事全体の結論とそのまま重なります。入れただけでは足りず、呼んで初めて効く。
境界条件の点差も、この裏返しです。「守備範囲が狭い」と書くこともできますし、「依頼された範囲に絞って直した」と書くこともできます。
私は後者の見方を取ります。バグ修正を頼んだつもりが、気づいたら周辺の仕様まで変わっていた、という方が実務では困るからです。
まとめると、こういうトレードオフでした
- 名指しで呼ぶと: 報告したバグの箇所だけを直し、書いたテストは確実にバグを捕まえる。ただし周辺の弱点は放置される
- 名指しで呼ばないと: 周辺まで手が届き堅牢になるが、頼んでいない仕様まで黙って書き換わる。しかも回帰テストに、バグがあっても通ってしまうものが混ざる
どちらが良いかは、任せたい仕事の性質によります。壊したくない既存コードに手を入れるなら前者、作りかけのものを一気に固めたいなら後者、という使い分けになりそうです。
入れっぱなしの負担は気にしなくてよさそう
「330個も入れたら重いのでは」と思って、こちらも測りました。
公式ドキュメントによれば、skillの中身は使うときまで読み込まれません。
a skill’s body loads only when it’s used, so long reference material costs almost nothing until you need it
常に読み込まれているのは、各skillの1〜2行の説明文だけです。全330個を合計しました。
| 構成 | skillの数 | 常に読み込まれる量 |
|---|---|---|
| superpowers のみ | 14 | 2,448 B |
| ＋ mattpocock | 51 | 10,320 B |
| ＋ ECC | 330 | 94,749 B |
ECCを足すと一気に増えます。この説明文は、skillを1つも使わなくても読み込まれる分です。
330個入れた状態でも、応答が遅くなる様子はありませんでした。 ただしこれは体感で、時間を測ったわけではありません。「明らかに待たされる」ということはなかった、という程度の話です。
なお成果物の質については、この構成から何も言えません。その回はskillを1つも使っていないので、良し悪しはskillの数とは関係がないからです。分かったのは「説明文が94KB常駐しても、目に見えて困ることは起きなかった」という一点だけです。
数字としては大きいものの、入れるのをためらう理由にはならなかった、というのが今回の結果です。
ECCは「全部入れる」前提の配布物ではなかった
ここは検証したあとで気づいた、私の入れ方の問題です。
ECCには7種類のインストール構成が用意されています。
| 構成 | モジュール数 | 位置づけ |
|---|---|---|
| minimal | 5 | 低コンテキスト向け |
| core | 6 | 最小ベースライン |
| developer | 9 | 多くの利用者向けの既定 |
| security / research | 7 / 9 | 用途別 |
| full | 24 | 全部入り |
READMEのクイックスタートは --profile minimal を使っていて、--profile full はコメントアウトされています。設定ファイル類についても、こう明記されています。
Do not copy every rules directory unless you explicitly want all of that context in Claude.
私が入れた279個は full に相当します。 つまりECCについては、作者が勧めていない入れ方で試したことになります。この記事のECCに関する観測は、その前提で読んでください。
ECCは1人の配布物ではなく、寄せ集めのリポジトリだった
もう1つ、当初は「作者個人の仕事環境をそのまま配布している」と考えていたのですが、調べたら違いました。
コントリビューターは281人います。各skillに記録された出どころを数えると、こうなります。
| 出どころ | 件数 |
|---|---|
| ECC（本体） | 199 |
| community | 41 |
| ECCからの移植・改変 | 8 |
| 個人・企業からの寄稿（名前つき） | 5 |
inventory-demand-planning（在庫需要計画）、ito-trade-planner、prediction-market-oracle-research（予測市場の調査）といった業務寄りのskillは確かにありますが、これらは本体側の199個に含まれるもので、全体としては複数人の持ち寄りで育っているリポジトリでした。
full で全部入れると業務寄りのskillまで付いてくる、というだけの話で、用途に合わせて構成を選べば済みます。
そもそも誰向けに作られているのか
「誰に向くか」を書く前に、各リポジトリが自分で誰を対象と言っているかを確認しました。ここが3つでかなり違います。
対応するAIツール
| 記載 | |
|---|---|
| superpowers | README冒頭に11個を列挙。Claude Code / Codex CLI / Codex App / Cursor / Gemini CLI / GitHub Copilot CLI / Kimi Code / OpenCode / Antigravity / Factory Droid / Pi。それぞれに導入手順あり |
| mattpocock/skills | Claude Codeのプラグインが主。「Codexなど他のエージェントはインストーラ経由で今も入る。Codexネイティブ対応はロードマップ」と現状を正直に書いている |
| ECC | Codex / Claude Code / Cursor / OpenCode / Gemini / Zed / GitHub Copilot |
言語・フレームワークの想定
ここが一番はっきり分かれます。言語固有のskillを数えました。
| 言語固有 / 全体 | |
|---|---|
| superpowers | 0 / 14 |
| mattpocock/skills | 0 / 37 |
| ECC | 49 / 279 |
superpowersとmattpocockは言語を選びません。 TDDやデバッグの進め方という、言語に依存しない手順だけで構成されています。どんなプロジェクトに入れても中身は同じです。
ECCだけが言語・フレームワーク固有のskillを持っています。 laravel-tdd、django-tdd、springboot-tdd、rust-testing、flutter-dart-code-review など49個。設定ファイル側も common/ ＋ typescript/ ＋ python/ ＋ golang/ に分かれていて、READMEに「必要な言語だけ入れろ」と書かれています。
前の節で触れた「用途別に選んで入れる」設計の中身がこれです。ECCは対象が広い分、自分に関係ない部分を外す前提になっています。
誰に何が向くか
superpowers が向く人: 入れっぱなしにして、意識せず恩恵を受けたい人。言語を選ばないので、どんなプロジェクトでも同じように使えます。
ただし自動起動は当てにできません（7回中2回）。軽いので入れておく負担はほぼゼロ。名指しすれば確実に動きます。使っているAIツールが11種類の中にあるなら、まず候補に入ります。
mattpocock/skills が向く人: / を打つのが苦にならない人。呼べば確実に動き、書く前に方針を確認してくれます。補助ファイルまで読み込む分だけ手順が丁寧です。
今回は報告したバグの箇所だけを直し、登録や解除の仕組みには触れませんでした。既存コードを不用意に広げたくない場面に向きます。
注意点として、Codexに入れる場合は、現状はインストーラ経由になります。
ECC が向く人: 279個の中身を自分で見て、必要なものを選べる人です。
他の2つと決定的に違うのはここでした。superpowersとmattpocockは、入れれば全部が手元に来ます。14個と37個なので、全部把握したうえで使うことも現実的です。
ECCは違います。7種類の構成があり、言語・フレームワーク別のskillが49個あり、READMEは「必要な言語だけ入れろ」と書いています。カタログから自分で取捨選択する前提の配布物です。
つまり「入れたらいい感じにしてくれる」を期待して入れるものではありません。自分に何が必要かを言語化できていて、279個を見て取捨選択できる人が対象です。Laravel・Django・Spring Boot・Rust・Flutterあたりを書いていて、その専用skillに心当たりがあるなら、他の2つには無いものが入っています。
逆に、まだ何が必要か分からない段階なら、選別のコストがそのまま負担になります。その場合はsuperpowersかmattpocockから始めて、足りないと感じてからECCを見る方が順序として自然だと思います。
なお私自身は評価できていません。1回しか走らせておらず、しかも作者が勧めていない全部入りで試しています。試すなら minimal か developer から始めるのが筋です。「全部入れたら重いか」を心配して見送るのは、たぶん的外れな理由になります。
乗り換える必要があるか: ありません。3つは競合しないので、乗り換えではなく足し算です。
併用していいか: 問題ありません。スキル名称も衝突せず、重くもなりませんでした。
試した結果、私の環境ではこうしました。
superpowers と mattpocock/skills の2つを入れました。ECCは見送っています。
superpowersは軽いので入れっぱなしにして、自動で動くことには期待しない。実際に手順を踏ませたいときは /systematic-debugging と打つ。テスト周りは /tdd を呼ぶ、という使い分けです。
とくに既存コードのバグ修正では名指しで呼ぶようにしました。頼んだ箇所だけが直り、周辺の仕様が黙って書き換わらないためです。
skillは「入れておけば勝手に賢くなる装備」ではなく「必要なときに開く手順書」というのが、9回動かしたあとの実感です。そう割り切ると、mattpocockが3分の2を「呼ばれるまで動かない」設定にしている設計は理にかなって見えます。
第三者の作ったプロンプト集を自分のプロジェクトで検証する話は、Claude Design System Promptを試したでも書きました。あちらは複数のデザイン案を作らせて比べる話です。
この検証で言えないこと
- 併用すると自動起動が減るのかは分かりませんでした。ばらつきが大きく、構成A 2/4・B 0/2・C 0/1 では判定できません
- ECCを入れる価値は評価できていません。1回のみ、自動起動もゼロで、しかも作者が勧めていない全部入りで試しました。用途別の構成（
minimal/developerなど）で試せば別の結果になる可能性があります - どちらが良い成果物かは決められませんでした。採点基準を1項目書き換えただけで上位と下位が入れ替わっています
- 採点はCodex1つに任せたものです。採点する側の偏りは残ります
まとめ
- 3つ同時に入れてもスキル名称は衝突しません。プラグインとして入れるなら仕組みの上でも衝突しません
- superpowersは自動起動が前提、mattpocockは
/で呼ぶのが前提。同じ土俵にいないので併用が成り立ちます - 自動起動は7回試して2回。「入れておけば勝手に効く」は当てになりません
- 名指しすれば確実に動きます。動かないのではなく、自分から出てこないだけです
- 名指しで呼んだ2回は、報告したバグの箇所だけを直しました。呼ばなかった回の多くは内部構造ごと作り替え、頼んでいない仕様まで黙って変えています
- 330個入れても、体感で重くなることはありませんでした。入れる負担より、呼ぶかどうかの方が大事です