Claude Code Skillsテンプレート集

変更範囲が広がり、テストを削って成功したように見える。
最短の解決策は、1つのSkillを1つの検証可能な工程に限定し、発動条件、入力、停止条件、受け入れ結果をSKILL.mdに固定することです。

この記事を読むべき人

個人用のClaude Skillsライブラリを早く整えたい開発者向けです。チームの実装、レビュー、テスト、文書化の手順を揃えたい開発責任者にも適しています。
また、テストやビルドを遠隔Agentに任せたいプラットフォームチームは、実行環境の分離条件まで確認してください。

最初に押さえるべき結論は、最良のClaude Code Skillsテンプレートは長文の万能指示ではないということです。コードレビュー、テスト修正、制御されたリファクタリング、変更文書、リリース確認を別々に作り、それぞれに「何をしてよいか」と「いつ止まるか」を記述します。

Last updated

最終更新：2026年8月12日。内容は、Agent Skillsの仕様、Claude Codeの公式導入要件、公式のSkill作成・評価資料を確認して整理しています。テンプレートは編集の出発点であり、実行結果を保証するものではありません。最小のサンプルプロジェクトで発動、停止、出力を検証してから、実際のリポジトリへ導入してください。

まず決めるべきSKILL.mdの最小構造

Agent Skillsの仕様では、SkillはSKILL.mdを中心とするディレクトリで、nameとdescriptionを持つ構成が基本です。nameは親ディレクトリ名と一致させ、説明には「何をするか」だけでなく「どの依頼で使うか」まで書きます。詳細はAgent Skillsの仕様で確認できます。

公式仕様は、必要になった時点でSkillの詳細を読み込む段階的な利用を前提にしています。本文を無制限に膨らませず、API仕様や例外処理はreferences/へ、繰り返し使う検査処理はscripts/へ分ける設計が安全です。

説明文は短ければよいのではなく、発動範囲を狭く正確にする必要があります。広すぎる説明は不要な場面でSkillを起動させ、狭すぎる説明は必要な依頼を取りこぼします。発動条件を見直す際は、Skillの説明文を最適化する公式資料も参考になります。

手順A：Claude Code Skillsテンプレートをコードレビュー専用にする

コードレビュー Skillには何を含めるか

コードレビュー用のSkillは、コードを修正するSkillではありません。入力として差分、変更理由、関連テスト、対象ブランチを受け取り、指摘だけを返す構造にします。

---
name: code-review
description: 差分の不具合、互換性、セキュリティ上の懸念を確認する。プルリクエストのレビュー依頼で使用する。
---

## 手順
- 変更されたファイルと関連テストを先に読む
- 指摘を重大度、対象ファイル、行、根拠、修正案に分ける
- 静的な懸念と、ツールで確認済みの結果を区別する
- 根拠が不足する場合は推測と明記する

## 停止条件
- 差分またはテスト結果が取得できない
- 秘密情報を含むログをそのまま出力しそう
- 仕様が不明で重大度を判断できない

「コードレビュー Skill」を書くときの要点は、指摘の形式を揃えることです。「危険そうです」ではなく、証拠の場所、影響範囲、再現条件、推奨対応を分けます。静的な提案を、実際に検査ツールを通過した脆弱性の発見として扱わないことも重要です。

向いている使い方

• 変更差分の読み落としを減らす
• レビューコメントの形式をチームで統一する
• セキュリティ上の懸念を人間の確認へ回す

避ける使い方

• レビュー中に無断でコードを書き換える
• テスト未実行のまま「問題なし」と断定する
• 仕様確認なしで大規模な設計変更を提案する

手順B：テスト修正は再現から始める

テスト修正Skillに必要な工程

テスト修正Skillは、失敗を消すのではなく、失敗の意味を確認するために使います。次の順序をテンプレートへ組み込みます。

• 失敗したコマンド、ログ、対象テストを記録する
• 同じ失敗を最小条件で再現する
• 実装、設定、依存関係のどこで期待値と実値が分かれたか確認する
• 最小のコード変更を行う
• 既存テストと関連する回帰テストを実行する
• 解決しない場合は、変更済みファイルと未解決理由を報告する

禁止事項は明示してください。テストファイルの削除、断言の弱体化、テストのスキップ、タイムアウトの延長による見かけ上の成功は、修正完了の条件に含めません。

Claude Codeを使う環境では、認証とAI処理のためにインターネット接続が必要です。ローカルと遠隔の実行環境でログや依存関係が異なる場合、Skillの検証結果を同一視しないでください。公式の導入要件で環境条件を確認できます。

手順C：リファクタリングの前に変更範囲を固定する

リファクタリング用のSkillでは、最初に現状の動作基準を作ります。対象テスト、公開インターフェース、代表的な入出力、エラーパターンを記録し、その基準を満たさない変更は次の作業へ進めません。

リファクタリングSkillはどうすれば範囲を制御できるか

対象ディレクトリ、変更してよいファイル、変更してはいけない境界を入力欄として用意します。さらに、各変更単位の後でテストを実行し、失敗したら直前の単位まで戻す条件を記述します。

無関係な命名変更、依存関係の更新、ディレクトリ再編を同時に許可すると、失敗原因を追跡できなくなります。リファクタリングが設計刷新へ変わりそうになった時点で停止し、別の計画として承認を取り直してください。

手順D：機能開発と変更文書を分ける

機能開発Skillは、要件確認、実装計画、許可された変更、検証結果の順に進めます。受け入れ基準がない場合は、Agentに不足部分を補わせず、質問を返して停止させます。

変更文書Skillは、差分、インターフェース、実行したテストの結果から生成します。未検証の機能を説明文へ追加したり、実装されていない動作を例として書いたりしてはいけません。文書の更新だけが成功しても、実装の受け入れ条件を満たしたことにはならないためです。

手順E：リリースSkillは自動処理と承認を分ける

リリース確認は、ビルド、テスト、版番号、変更概要を自動で確認し、公開操作だけを手動承認へ回す構成が扱いやすいです。コマンドを実行するSkillでは、相対パスと補助スクリプトの位置を明示してください。スクリプト利用の公式ガイドでは、Skillのルートから相対パスで実行する方法が示されています。

• 自動実行に向くもの：形式確認、テスト、ビルド、差分取得、版番号の照合
• 手動開始に向くもの：本番公開、データ移行、権限変更、外部通知
• 必ず停止するもの：テスト失敗、未承認の差分、秘密情報を含む成果物

実装後は、最小サンプルプロジェクトで各Skillを検査します。発動しなかった依頼、誤って起動した依頼、停止条件が働かなかった依頼、受け入れ結果が曖昧だった依頼を記録し、説明文と本文を別々に修正してください。Skillの評価方法も、指示どおりに実行できたかを確認する際に役立ちます。

Claude Skillsテンプレートをチームで再利用する条件

チーム共有では、テンプレート本文よりも入力と出力の契約を揃えることが先です。Skillごとに所有者、対象リポジトリ、必要な権限、利用するコマンド、失敗時の報告先を記録し、変更履歴をレビュー対象にします。

プロジェクトごとに命名が衝突する場合は、プロジェクト側のSkillを優先する運用を決めておくと、個人設定による予期しない上書きを抑えられます。共有用の詳細資料はreferences/へ分離し、本文には「どの条件で読むか」だけを残す設計が適しています。

条件分岐で選ぶテンプレート

• 受け入れ基準がなく、仕様も不明なら、機能開発Skillを実行せず質問テンプレートへ戻します。
• 差分とテスト結果が揃っているなら、コードレビューSkillを先に実行します。
• 再現可能なテスト失敗があるなら、テスト修正Skillを使い、断言を弱める提案は拒否します。
• 公開APIを維持した局所変更なら、リファクタリングSkillを選びます。複数モジュールの設計変更なら、先に人間の承認を取ります。
• ビルドとテストが通り、変更概要が確認済みなら、リリース確認Skillへ進みます。公開操作そのものは手動承認に戻します。

現在のローカル環境だけで十分なのは、物理デバイスへの接続や長時間の安定稼働が必要ない個人作業です。一方、チームで同じテスト、ビルド、リリース確認を繰り返す場合は、依存関係、権限、ログ保存先を固定できる実行環境が必要になります。

その場合は、まず注文前の環境設定ガイドで必要条件を整理し、作業を分離したいチームはMacの利用に関するヘルプも確認してください。Macstripeのレンタル環境は、短期の検証、別環境でのテスト、チーム共有用の作業場所を用意したいケースでは、自前端末を増やすより判断しやすい選択肢です。

ただし、長期にわたり同じ高負荷処理を常時動かす場合や、特定の物理インターフェースを直接使う場合は、自分でMacを所有する方が適しています。反対に、Claude Code Skillsの動作確認、テスト環境の一時確保、リリース前の隔離作業が目的なら、端末購入に伴う初期費用、共有時の権限管理、環境差分の調整を抱えずに済むため、Macstripeをレンタルして検証環境を分ける方が運用しやすいでしょう。