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法則は正しい。ただし、長期運用を見据えると「設計の法則」だけでなく「整理の仕組み」がセットで必要だ。