alamops/skills は、個人が公開しているAgent Skillsの詰め合わせです。★45と規模は小さく、収録スキルも9本。それだけなら数ある個人スキル集のひとつですが、このリポジトリには同梱されたevals（発動テスト）のほうに読む価値があります。そこには、Anthropic公式の測り方に対する具体的な反論が書かれています。
- ・正体：個人が公開するAgent Skills 9本。★45・MIT・最終push 2026-08-20
- ・読みどころ：スキル本体より同梱evals。公式skill-creatorのeval手法への反論が書かれている
- ・公式への指摘：一意化した名前でテストすると正しい発動がmissとして数えられる
- ・代替手法：実名のまま全スキルを入れた状態で「どのスキルが勝つか」を測る。1実行約10秒・数セント
- ・実測：9本を公式バリデータにかけると5本が不合格（3本が1,024字超過、2本が山括弧）
- ・導入の罠：Claude Codeではnpx skillsでなくマーケットプレイス経由。CLIのシンボリックリンク不具合で見えなくなる
スキルの仕組みそのものは Claude Skillsとは｜「スキル=フォルダ」の仕組みと作り方・使い方を徹底解説 に、Claude Code全体の導入は Claude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き にまとめてあります。
alamops/skillsに収録された9本は何をするか
まず中身です。9本すべてのdescriptionが (alamops) という接頭辞で始まっており、他のスキル集と混ざったときに出所が分かるようになっています。個人スキル集では有効な工夫です。
| スキル | 何をするか（SKILL.md要約） | desc字数 | 本文 |
|---|---|---|---|
implement |
機能を計画から出荷まで一気通貫で作る「主力スキル」 | 1,066 | 67KB |
appstore-seo |
iOS/Google Play向けASO。ストア掲載情報の作成・改稿・監査 | 1,300 | 32KB |
create-tasks |
PRDやチケットから、深く実行可能な開発タスク群へ落とす | 1,007 | 29KB |
break-fix |
動作中のアプリを敵対的に操作してバグを探すE2E探索 | 1,043 | 23KB |
to-prd |
各種インプットからPRD（製品要求仕様）を起草する | 795 | 22KB |
business-review |
LP・価格・オンボーディング等の公開物から事業を分析 | 872 | 17KB |
code-review |
PR・diff・未コミット変更に対する読み取り専用レビュー | 843 | 17KB |
appstore-review |
iOSアプリをApple審査ガイドラインに照らして点検 | 1,006 | 15KB |
rpg-persona |
懐疑的な買い手を演じ、営業トークやポジショニングを詰める | 795 | 16KB |
構成に個性があります。iOSアプリ開発と事業サイドの両方に寄っていて、appstore-review（審査ガイドライン適合）と appstore-seo（ASO）、business-review と rpg-persona（買い手ロールプレイ）が並ぶのは、汎用的なスキル集ではあまり見ない組み合わせです。READMEも「個人的なコレクション。有用なものだけフォークして、残りは無視してくれ」と明言しており、万人向けを狙っていません。
break-fix の「敵対的・混乱した・せっかちなユーザーとして本物のアプリを操作する」という定義や、rpg-persona の「懐疑的な買い手を演じて圧をかける」という発想は、AIに意地悪をさせるタイプの使い方で、読み物としても面白い部類です。
① 何ができる：iOS開発と事業レビューに寄った9スキルが入る。ただし本命は同梱evalsの手法。② 何を解決する：「スキルの説明文を直したが、本当に発動精度が上がったのか」を測れない問題。③ 何を代替できる：公式 skill-creator の `run_eval`。作者はその測り方が特定条件で機能しないと具体的に指摘している。
alamops/skillsの本命はevals——公式skill-creatorのeval手法への反論
evals/trigger_race.py の冒頭コメントに、このリポジトリで一番読む価値のある部分があります。Anthropic公式 skill-creator の run_eval に対する、具体的な批判です。
要約すると主張はこうです。公式の手法は、テスト対象の説明文を myskill-skill-a1b2c3d4 のような一意化された名前のコマンドとして導入し、Claudeがその名前を呼んだときだけ発動とみなします。ところが——
・Claudeが自力で対応できてしまうスキルでは、その不自然な名前自体が発動を抑制する。Claudeはスキルを参照せずBashを呼んで作業を始めてしまう
・結果、正しく発動すべきケースがすべてmissとして数えられる
・本物のスキルを外しても解決しない。一意化されたコマンドしか無い状態では、そもそも何も発動しない
この指摘が正しいかどうかは、公式実装を読んで各自で確かめるべき性質のものです。ただ議論の立て方は具体的で、「精度が悪い」といった曖昧な不満ではなく、測定手順のどこで何が起きるかを名指ししています。
代わりに何を測っているのか
作者の代替案は明快です——「そのクエリで、どのスキルが勝つか」を測る。
python3 evals/trigger_race.py \
--skill skills/implement \
--eval-set evals/implement/trigger_eval.json \
--cwd ~/code/some-real-app \
--runs 3
実装の要点はREADMEとソースから読み取れます。
| 論点 | trigger_race.py のやり方 |
|---|---|
| インストール名 | 実名のまま。~/.claude/skills/<name> を一時的にテスト対象へ向ける |
| 他スキルの扱い | 全部入れたまま。競合状態を再現する |
| 判定 | claude -p で各クエリを実行し、最初のツール呼び出しを記録 |
| 打ち切り | スキル選択は1ターン目で決まるので、最初の呼び出しで即kill |
| コスト | 1実行あたり約10秒・数セント。タスクを最後まで実行しない |
| 安全性 | try/finally・シグナルハンドラ・atexit で復元。削除せず退避のみ |
「実名のまま」「他スキルも入れたまま」の2点が肝です。実運用ではスキル同士が同じクエリを取り合うので、単体テストでは意味のある数字が出ない——という発想になっています。
A/Bも回せます。手元にインストール済みの版をベースラインに指定して、変更版と競わせる形です。
python3 evals/trigger_race.py \
--skill skills/implement --baseline ~/.agents/skills/implement \
--eval-set evals/implement/trigger_eval.json --runs 8
eval セットの作り方——価値があるのはニアミス
evals/README.md の説明も実務的です。eval セットとは「現実的なクエリと、そのスキルが発動すべきかどうか」の対応表であり、価値があるのはニアミスだと書かれています。
価値があるのはニアミス——スキルと語彙を共有しているが、別のスキルに属するクエリ。それが、静かに欲張りになりすぎた description を捕まえる。
[
{"query": "start a time-boxed spike to figure out whether ...", "should_trigger": false},
{"query": "add SSO via okta to the admin portal ...", "should_trigger": true}
]
「時間を区切った調査（spike）を始めたい」は implement が拾ってはいけないクエリで、「管理画面にOkta経由のSSOを追加して」は拾うべきクエリ。語彙は近いのに正解が逆、という組み合わせを集めるわけです。
実際のeval セットの規模も見ておきます。
| eval セット | クエリ数 |
|---|---|
evals/implement/trigger_eval.json |
27 |
evals/appstore-seo/trigger_eval.json |
22 |
evals/appstore-review/trigger_eval.json |
20 |
9本中3本にしか用意されていないので、網羅されているわけではありません。ただ20〜27件というのは、手で書くには十分に骨の折れる量です。
候補版へ一時的に向ける"] B --> C["eval セットの各クエリを
claude -p で実行"] C --> D["最初のツール呼び出しを記録
→ 即座にkill（約10秒）"] D --> E{"どのスキルが勝ったか"} E -- "狙い通り" --> F["should_trigger と一致"] E -- "別スキルが勝った" --> G["ニアミス失敗として記録"] F --> H["try/finally で元の版へ復元"] G --> H H --> I["ベースライン版とスコア比較"]
9本を公式バリデータにかけると5本落ちる
evalsまで作り込む作者のスキル集は、公式の形式要件をどれくらい満たしているのか。Anthropic公式の quick_validate.py を9本すべてに走らせました。
# 公式バリデータを取得して alamops/skills を検査する
git clone --depth 1 https://github.com/anthropics/skills.git /tmp/anthropic-skills
git clone --depth 1 https://github.com/alamops/skills.git /tmp/alamops-skills
for d in /tmp/alamops-skills/skills/*/; do
printf "%-18s " "$(basename "$d")"
python3 /tmp/anthropic-skills/skills/skill-creator/scripts/quick_validate.py "$d"
done
結果は9本中5本が不合格でした。
| スキル | 判定 | 理由 |
|---|---|---|
| appstore-seo | ✗ | description 1,300字（上限1,024字を276字超過） |
| implement | ✗ | description 1,066字（42字超過） |
| break-fix | ✗ | description 1,043字（19字超過） |
| create-tasks | ✗ | descriptionに山括弧を含む |
| to-prd | ✗ | 同上 |
| appstore-review / business-review / code-review / rpg-persona | ✓ | 合格 |
5本落ちたからといって「壊れている」わけではありません。1,024字上限と山括弧禁止が効くのはアップロード型カスタムスキルの検証で、このリポジトリが使っているマーケットプレイス配布や
npx skills 経由では、現状これらのチェックは掛かりません。実際に9本ともインストールして動作します。ただし将来アップロード経路へ載せたくなったときには、5本を書き直す必要が出ます。上限の詳細と削り方は SKILL.mdのdescriptionは1024字上限｜Claude Skill命名規則と公式19本の検査結果 にまとめました。なお公式スキル集自身も19本中1本（claude-api）が同じ上限で落ちるので、この線を守れていないのはalamops側だけではありません。
本文サイズにも触れておきます。9本の合計は約238KB、最大の implement は67,458バイトで、Anthropic公式19本で最大の skill-creator（33,168バイト）の2倍以上あります。ただしこれは常駐コストには効きません。毎セッション読まれるのはdescriptionだけで、本文は発動時にしか読まれないためです。本文をいくら厚く書いても固定費は増えないという構造を、この集まりは素直に使っている形になります。
9本のうち何から見るか
全部読む必要はありません。スキルの書き方の参考としてなら、性格の違う3本を見ると傾向がつかめます。
・code-review（17KB / desc 843字） — 「読み取り専用」を明示している数少ない1本。PR・diff・未コミット変更のいずれも入力に取れるよう入口を広く定義しつつ、書き込まないことを宣言している。権限の線引きをdescriptionに書く書き方の例として参考になる
・implement（67KB / desc 1,066字） — 逆に「計画もレビューもでなく、機能を丸ごと作って出荷する主力」と役割を強く宣言している。本文67KBは9本で最大だが、descriptionは1,066字。本文を厚く、descriptionは絞るという配分が実際にどう見えるかの実例
・rpg-persona（16KB / desc 795字） — 9本で最短のdescription。「懐疑的な買い手を演じて営業トークに圧をかける」という、他と取り違えようのない役割定義。短くても区別がつくdescriptionの見本
3本を並べると、descriptionの長さが役割の広さに対応していることが分かります。入口の広い implement は1,066字、役割が一意な rpg-persona は795字。長くすべきかどうかは、そのスキルが取りうる入力の幅で決まるという見方ができます。
導入手順と、npx skillsの落とし穴
導入経路は3つ用意されています（Claude Codeのプラグインマーケットプレイス、npx skills CLI、手動コピー）。ただしClaude Codeユーザーは選択肢が実質1つです。手動コピーは各スキルの skills/<name>/ フォルダをエージェントのスキルディレクトリへそのまま置くだけで、SKILL.md仕様に従う任意のエージェントで動きます。
# 推奨：Claude Code はプラグインマーケットプレイス経由
/plugin marketplace add alamops/skills
/plugin install alamops-skills@alamops-skills
導入後は /alamops-skills:<スキル名> で明示的に呼べるほか、descriptionからの自動発動もします。
他エージェント（Codex・Cursor・Gemini CLI など）向けには npx skills が使えます。
# リポジトリの中身を一覧する
npx skills add alamops/skills --list
# Codex へ全スキルを入れる
npx skills add alamops/skills --skill '*' --agent codex
問題はClaude Codeで npx skills を使った場合です。READMEが理由まで含めて警告しています。
・npx skills CLIはスキルの正本を ~/.agents/skills/ に置き、各エージェントのフォルダへシンボリックリンクを張る
・Claude Codeは ~/.claude/skills/ しか読まない
・スキルが ~/.agents/skills/ には入るのに ~/.claude/skills/ のリンクが作られない不具合が報告されている（vercel-labs/skills の issue #744・#693・#851）
・結果、「インストールできたのにClaude Codeからは見えない」状態になる
CLIを使ってしまった場合の確認方法も書かれています。
# インストールが実際にリンクされたか確認する
npx skills list -g
ls -la ~/.claude/skills/
~/.claude/skills/ に見当たらなければ、プラグイン経由で入れ直すのが早道です。個人スキル集のREADMEがここまで具体的に外部CLIの不具合と回避策を書いているのは珍しく、実際に踏んだ痕跡が見えます。
自分のスキル集へどう持ち込むか
trigger_race.py はMITなので流用できますが、そのまま動かす前に前提を確認しておくと事故が減ります。
・~/.claude/skills/<name> を一時的に差し替えるため、同名スキルを常用している場合は実行中そちらが使えなくなる。復元は try/finally・シグナルハンドラ・atexit の三重で担保され、削除ではなく退避のみだが、大事なスキルがある環境ではまずバックアップを取る
・実際にAPIを呼ぶ。1実行あたり数セント。27件のeval セットを3回ずつ回せば81実行になるので、桁を把握してから走らせる
・--cwd に実プロジェクトを指定する設計になっている。スキル選択は文脈に依存するため、空のディレクトリで測っても本番と違う結果になりうる
・判定は最初のツール呼び出しのみ。「発動したか」は測れるが「発動したあと役に立ったか」は測れない。品質評価は別の話として残る
自作スキルに応用するなら、順序はこうなります。
| 手順 | やること |
|---|---|
| 1 | 現行descriptionのまま eval セットを作る。ニアミスを優先して20件前後 |
| 2 | ベースラインとして1回測り、いま何件外しているかを記録する |
| 3 | descriptionを書き換える。個別列挙を足すのではなく、意図のカテゴリで括り直す |
| 4 | --baseline に旧版を指定してA/Bで測る |
| 5 | 改善していれば採用。1,024字を超えていないかも同時に確認する |
3の「個別列挙を足さない」は、Anthropic公式の improve_description.py も同じことを言っています。失敗したクエリを1件ずつ description に書き足していくと、際限なく伸びたうえ他スキルとの区別が曖昧になる。測れるようになると、この誘惑に抗いやすくなるというのがevalを持つ本当の利点でしょう。
公式スキル側の実物を読みたい場合は、19本すべてが1コマンドで手元に落ちます。何が「良い description」とされているかの実例として使えます。どれが公式に含まれるかは Anthropic公式スキルは17個ではなく19個｜日本語解説の空白地帯を全数調査した に一覧を載せました。
なお eval セットそのものはスキルに強く依存するので、alamops のセットをそのまま流用しても意味がありません。持ち帰るのはハーネスと考え方で、データは自分で書く必要があります。
ライセンスと開発状況
ライセンスは MIT です。実測値は次のとおりです。
| 項目 | 実測値（2026-08-24時点） |
|---|---|
| ★ | 45 |
| フォーク | 4 |
| オープンIssue | 0 |
| リポジトリ作成 | 2026-05-07 |
| 最終push | 2026-08-20 |
| 収録スキル | 9本 |
| ライセンス | MIT |
★45という数字は小さく、人気を理由に選ぶ類のリポジトリではありません。作者自身がREADMEで「個人的なコレクション」「有用なものだけフォークして、残りは無視してほしい」と書いているとおりです。
一方で最終pushは2026-08-20と新しく、evalsの実装を見る限り手は動いています。9本のスキルをそのまま使うより、trigger_race.py の考え方を自分のスキル集へ持ち込むほうが得るものが大きいタイプのリポジトリでしょう。MITなのでスクリプトを流用することにも制限はありません。
まとめ
・個人のAgent Skills集9本。iOS開発と事業レビューに寄った構成で、★45・MIT
・本命は同梱evals。公式skill-creatorの `run_eval` が「正しい発動をmissと数える」条件を具体的に指摘している
・代替手法は「実名のまま全スキルを入れて、どれが勝つか測る」。1実行約10秒・数セント、復元は try/finally で担保
・eval セットで価値があるのはニアミス——語彙が近いのに正解が逆のクエリ
・9本を公式バリデータにかけると5本が不合格。ただし配布経路が違うため実害はない
・Claude Codeでは必ずマーケットプレイス経由。npx skills はシンボリックリンク不具合で見えなくなることがある
個人スキル集を読むときの見方
alamops/skills に限らず、個人が公開するスキル集は玉石混交です。★の数はほとんど当てになりません——このリポジトリ自体が★45で、中身の質とは釣り合っていない例になっています。判断材料として実際に使えるのは次のあたりです。
| 見るところ | 何が分かるか |
|---|---|
| evalsやテストの有無 | 発動精度を測る習慣があるか。この集まりの差別化点はまさにここ |
| description の書き方 | 個別クエリの羅列か、意図のカテゴリで括られているか |
| SKILL.md の粒度 | 1本が何でも屋になっていないか。役割が切れているか |
| READMEの但し書き | 既知の不具合や制約を正直に書いているか（本リポジトリは npx の不具合を明記） |
| 最終push | 手が入り続けているか |
このリポジトリは、★以外の項目では良好な部類です。とくに外部CLIの不具合を issue 番号つきで書き、回避策まで示している点は、実際に使って踏んだ人の書き方です。
スキルを書いていると、descriptionの書き換えが当て推量になりがちです。少し足せば拾ってくれる気がする、削れば余計な発動が減る気がする——けれど確かめる手段が無い。このリポジトリが提示しているのは、その感覚を数字に変えるための最小限の道具立てです。
★45のリポジトリを紹介する理由もそこにあります。9本のスキルが自分に合うかは人それぞれですが、「どのスキルが勝つかを測る」という発想は、スキルを2つ以上持っている人全員に関係します。公式の測り方に不満があるなら、まず trigger_race.py を読んでみる価値はあるはずです。
参照ソース
・alamops/skills（公式リポジトリ・README・evals） — 9スキルの構成、trigger_race.py の設計思想、npx skills の不具合と回避策の出典
・anthropics/skills — skill-creator — 批判対象の公式 run_eval、および本記事の検査に使った quick_validate.py の所在
・vercel-labs/skills — npx skills CLI — シンボリックリンク不具合として挙げられている issue #744 / #693 / #851 の一次情報
