Skill lint

Skill 品質チェック（skill-lint）

このスキルがやること

新規・変更された SKILL.md を、リポジトリのテンプレ（templates/SKILL.md 等）と運用ルール（README）に照らして点検する。チェックリストで出した指摘はそのまま報告せず、反証を試みる敵対的検証を通過したものだけを修正可能な形で報告する。

手順

1. 対象を特定する: 引数で指定された Skill、なければ git diff --name-only main...HEAD（または未コミット差分）に含まれる SKILL.md を対象にする。対象が無ければその旨を報告して終了する。
2. リポジトリにテンプレ・運用ルール（README の規約節）があれば読み、下記チェックリストにリポジトリ固有の基準を上乗せする。
3. 検出: 対象ごとにチェックリスト全項目を判定する。❌ は根拠となる行の原文引用と共に「候補」としてメモし、この時点では報告しない。
4. 敵対的検証: ❌ 候補を adversarial-verify Skill（skills/adversarial-verify/SKILL.md）で検証し、生き残った候補だけを ❌ として確定する（→ 敵対的検証への渡し方）。
5. 報告フォーマットで指摘を出す。棄却した候補も棄却理由と共に載せる。修正はユーザーが「直して」と言った場合のみ行い、修正後は再チェックする（再チェックにも敵対的検証を含める）。

敵対的検証への渡し方

反証の 3 点（証拠の実在・基準への紐づけ・反例探し）、仕分け（棄却/参考降格/確定）、独立検証の条件、全 ✅ 時の逆方向反証は adversarial-verify の定義に従う。本 Skill からは次の対応で渡す:

adversarial-verify の入力	skill-lint での対応物
指摘候補	検出フェーズでメモした ❌ 候補（根拠行の引用付き）
対象	点検中の SKILL.md
基準	下記チェックリスト（＋手順 2 で上乗せしたリポジトリ固有基準）

• 独立検証（検証用サブエージェント）の起動条件も adversarial-verify に従う: ❌ 候補が 3 件以上、または Skill 追加 PR 直前の最終ゲートとして使うとき。
• 全項目 ✅ の場合も adversarial-verify の定義どおり、判定が最も際どかった 2 項目に逆方向の反証を試みてから合格を宣言する。

チェックリスト

#	項目	判定基準
1	name 一致	frontmatter の name がディレクトリ名と一致する
2	description にトリガー	「いつ使うか」（状況・ユーザーの言い回し例）と「何をするか」の両方が書かれている
3	構成	手順 / ルール・コツ / 完了条件 の節がある
4	完了条件が検証可能	各項目が実行結果・成果物で確認できる形。「適切に」「十分に」「ちゃんと」等の曖昧語が無い
5	完了条件の前文	「満たせない項目は黙って省略せず理由を報告する」趣旨の一文がある
6	固有情報なし	社名・内部 URL・認証情報・固有プロジェクト名が本文に無い
7	カタログ同期	（新規追加・改名時）README のカタログ表に対応する行がある
8	判断基準	判断が分かれる場面に if/then の基準が書かれている
9	出力フォーマット	報告・成果物に決まった形が要る Skill では、表テンプレ等で形式が固定されている

• 8・9 は該当しない Skill もある。その場合は ⏭️ n/a とし、理由を一言添える。

報告フォーマット

対象 Skill ごとに必ずこの表で報告する（✅ pass / ❌ fail / ⏭️ n/a の 3 値）:

### skills/<name>/SKILL.md

| # | 項目 | 結果 | 指摘（敵対的検証を通過したもののみ） |
|---|---|---|---|
| 1 | name 一致 | ✅ | |
| 2 | description にトリガー | ❌ | ユーザーの言い回し例が無い（L3 原文: 「…」）。例:「◯◯して」を追記 |
| ... | | | |

**棄却した候補**: なし

棄却した候補がある場合は、上の一行の代わりにこの表を付ける:

**棄却した候補**（敵対的検証で誤検出と判定）:

| # | 候補の指摘 | 棄却理由 |
|---|---|---|
| 4 | 完了条件に曖昧語「適切に」がある | 反例探しで再読した結果、該当箇所は良い例/悪い例の引用文中だった（L45） |

• ❌ には必ず根拠行の原文引用と具体的な修正案を添える（何をどう直すか）。
• 全て ✅/⏭️ なら、際どい 2 項目への反証試行の結果を一言添えた上で「PR に進めます」と書く。

ルール・コツ

• 指摘は基準（チェックリストの何番か）に紐づけて出す。基準に無い好みの指摘は「参考」として分け、fail 扱いにしない。
• 敵対的検証は指摘の品質保証であって、指摘を減らすための言い訳探しではない。反証に失敗したら素直に ❌ を確定する。
• 棄却した候補を黙って消さない（棄却理由と共に必ず記録する）。レビューの再現性と、チェックリスト自体の改善材料になる。
• description の判定で迷ったら「このスキルを知らない Claude が description だけ読んで、発動すべき場面を特定できるか」で判断する。
• 長さは基準にしない（短くても項目を満たせば pass）。ただし手順が過度に細分化されている場合は参考指摘として伝える。
• チェック対象の SKILL.md を勝手に書き換えない（修正はユーザー指示があった場合のみ）。

完了条件

以下を全て満たしたら完了。満たせない項目があれば、黙って省略せず理由を報告する。

• 対象の SKILL.md 全てについて、チェックリスト全 9 項目の判定（✅/❌/⏭️）を表で出した
• 全ての ❌ が敵対的検証（反証試行）を経て確定しており、根拠行の原文引用と具体的な修正案を添えた
• 棄却した候補を棄却理由と共に記録した（無い場合は「棄却した候補: なし」と明記した）
• 全て ✅/⏭️ の場合、際どい 2 項目への反証試行を行ってから合格を宣言した
• ⏭️ n/a には理由を一言添えた
• ユーザーの指示なしに対象ファイルを書き換えていない

補足

• 社名・内部 URL・認証情報などの固有情報は扱わない。
• このリポジトリ以外（各プロジェクトの .claude/skills/）の Skill にも同じチェックリスト・同じ敵対的検証で使える。