Claude Skills（SKILL.md）設計「6法則」と自分の環境を照合したら、2点で先を行っていた話
はじめに
先日、Claude Code の Skills を100個リバースエンジニアリングした分析記事が流れてきた。「動くSkillsと動かないSkillsを分ける6つの設計法則」というもので、Erik Schluntz（Anthropic）の「Vibe Coding in Prod」とも関連付けられた内容だった。
読んでいて気になったのは「これ、自分の環境にどこまで取り込まれているか？」という点だ。今回はその照合結果と、逆に外部分析より先に自分の環境が実装していたことを共有する。
6法則とは
外部分析が提唱する、動くSkillsを設計するための6法則は以下のとおり：
| # | 法則 | ポイント |
|---|---|---|
| 1 | descriptionに「いつ使うか」を書く | トリガーキーワード必須。50文字未満は呼び出し頻度が3〜5倍低下 |
| 2 | 発注書スタイル（命令形） | 会話調ではなく番号付きステップ＋出力形式を明示 |
| 3 | 出力フォーマットを厳密に指定する | テンプレートを定義し毎回同じ構造を得る |
| 4 | 「まず既存ファイルを読め」を入れる | 汎用出力と自環境フィット出力の差がここで決まる |
| 5 | Out of Scope（範囲外）を明記する | 高品質Skillsの70%が実践。代替スキルも明示 |
| 6 | コンパクトに保つ | 入り口50行以内・全体500行以内。超える場合は references/ に分離 |
自分の環境との照合結果
# 環境概要
~/.claude/skills/ # アクティブスキル 40件（上限50件）
~/.claude/commands/ # スラッシュコマンド 30件
~/.claude/skills-archive/ # アーカイブ済み
| 法則 | 実装状況 | 根拠 |
|---|---|---|
| ① description にトリガー | ✅ 取り込み済み |
frontend-designのTRIGGER/DO NOT TRIGGERパターンが標準化済み |
| ② 発注書スタイル | ✅ 取り込み済み |
Step 0 / Step 1 / Step 2... 番号付きフロー、DO/DON'T形式 |
| ③ 出力フォーマット指定 | △ 部分的 | 一部スキルでは指定あり。テンプレートが統一されていない |
| ④ まず読め | ✅ 取り込み済み | 構成案・既存レポートの先読みステップが標準パターン |
| ⑤ Out of Scope | △ 部分的 | 一部スキルのみ。scaffold に節がなかった |
| ⑥ コンパクト | ⚠️ 一部超過 | 3件が500行超（最大565行）。うち1件は外部ライブラリの自動生成 |
結果は「骨格は実装済み、細部がバラつく」という状態だった。
外部分析より先を行っていた2点
照合して驚いたのは、記事が「次の一手」として推奨する水準をすでに超えていた部分が2つあったことだ。
1. description品質を「制度化」している
6法則の法則①が指摘するのは「descriptionに何を書くか」という設計論だ。しかし筆者の環境では、それをチェックリストとして制度化している：
_vibecoding/guides/description-checklist.md
このファイルには10パターンのメンタルテストが定義されており、新規スキル作成時に「トリガー率90%以上」を目標として検証する仕組みになっている。
外部分析は「descriptionをこう書け」と言うが、こちらは「書いた後にこう検証せよ」まで踏み込んでいる。
2. 使用頻度に基づくローテーション運用
6法則はスキルの「作り方」を語るが、**「整理の仕方」**には触れていない。しかし実際には、スキルは増え続ける。
筆者の環境では：
# 使用頻度トラッキング
~/.claude/skills-usage.json
# ローテーション管理コマンド
/skill-rotate
skills-usage.json に各スキルの実行回数・スコアを記録し、上限50件を超えそうになったら /skill-rotate で低頻度スキルをアーカイブに退避する仕組みを運用している。アーカイブは187件に達しており、「コレクション」ではなく「循環するシステム」として機能している。
外部分析が「動かないSkillsを直せ」と言う一方で、こちらは「動かなくなったSkillsを定期的に入れ替える」という次の問いに答えていた。
残課題と対応
照合で分かった残課題への対応：
法則⑤（Out of Scope）の徹底
スキル作成コマンドのscaffoldテンプレートに ## 範囲外 (Out of Scope) 節と、description への DO NOT TRIGGER when: パターンを追加した。新規作成スキルから自動的に適用される。
---
description: "[何をするか]。...DO NOT TRIGGER when: [除外条件]（→ [代替スキル名]を使う）。"
---
## 範囲外 (Out of Scope)
- [担当外のケース1] → [代替スキル名]
- [担当外のケース2] → [代替スキル名]
法則⑥（コンパクト）の一部未達
外部ライブラリが自動生成したスキル（565行）は触らない方針。残り2件（527・541行）はそれぞれ27〜41行のオーバーで実害がないため、次回のローテーション時に references/ 分離を検討する優先度で管理する。
まとめ
- 6法則の①②④は設計に埋め込み済み。③⑤は部分的、⑥は一部超過
- 外部分析が「設計の質」を論じる一方、自環境は「検証の制度化」と「ライフサイクル管理」まで進んでいた
- Skillsは「作ったら終わり」ではなく「整理・ローテーション・アーカイブ」を含むシステムとして設計する必要がある
- scaffoldを直せば、新規作成スキルは「最初から正しい構造」を持つ
記事が提唱する6法則は正しい。ただし、長期運用を見据えると「設計の法則」だけでなく「整理の仕組み」がセットで必要だ。