Claude CodeのSkillsの書き方｜テンプレ7選

Claude CodeのSkills機能、存在は知っているけれど「結局何を書けばいいのか」がわからない——という声をよく聞きます。

今回は、実際に効果が出やすい項目を、テンプレートとして7つ紹介します。その前に、よく混ざるCLAUDE.mdとSkillsの違いから整理しておきます。ここを押さえると、「どこに書くか」で迷わなくなります。

まず整理：CLAUDE.mdとSkillsは、読まれ方が違います

公式ドキュメントの言葉を借りると、Skillsを作るタイミングは「同じ指示やチェックリストを何度も貼り付けているとき」、そして「CLAUDE.mdの一部が、事実ではなく手順に育ってきたとき」です。

どちらも「プロジェクトの暗黙知を言語化して、AIに渡す仕組み」であることは同じ。以下の7つは、それぞれどちらに置くと効くかも添えています。

1. 命名規則 ［置き場所：CLAUDE.md］

AIは「正しく動くコード」は書けても、「そのプロジェクトらしい名前」は知りません。

## 命名規則
- コンポーネント名: PascalCase（例: UserProfileCard）
- 関数名: camelCase、動詞から始める（例: fetchUserData）
- 真偽値の変数: is/has/can で始める（例: isLoading, hasError）
- 定数: UPPER_SNAKE_CASE

これを書いておくだけで、AIが生成するコードがプロジェクトの既存コードと馴染むようになります。どの作業でも守ってほしいので、常に読まれるCLAUDE.mdが向いています。

2. よくあるバグパターンと対処法 ［置き場所：CLAUDE.md］

過去に踏んだ地雷は、AIにも共有しておくべき情報です。

## 注意すべきバグパターン
- 日付処理は必ずUTCで保持し、表示時にローカルタイムへ変換する
  （過去にタイムゾーン起因の不具合が複数回発生）
- 配列のstateを直接変更しない。必ず新しい配列を作って置き換える
- APIレスポンスのnullチェックを省略しない（外部APIはnullを返すことがある）

「なぜそうするのか」の理由まで書いておくと、AIが似たような場面で自分で判断できるようになります。

3. コードレビューの基準 ［置き場所：Skill］

レビューで毎回指摘している観点は、レビューという作業の手順としてSkillにするのが効きます。

---
name: review
description: 変更差分をRJCのレビュー基準でチェックする。PR作成前やレビュー依頼時に使う
---

## 手順
1. git diff で変更内容を確認する
2. 以下の基準で問題点を洗い出し、ファイル名と行番号つきで報告する

## コードレビューの基準
- 1つの関数は1つの責任に絞る（50行を超えたら分割を検討）
- マジックナンバーは定数化する
- エラーハンドリングを省略しない
- テストが書かれていない変更は指摘する

.claude/skills/review/SKILL.md に置けば、/review で呼び出せます。冒頭の description は「いつ使うか」をAIが判断する材料なので、具体的に書くのがコツです。AIが自分のコードを自己チェックする基準としても機能します。

4. アーキテクチャ上の制約 ［置き場所：CLAUDE.md］

「なぜこの構成になっているか」を知らないAIは、良かれと思って構成を壊すことがあります。

## アーキテクチャ上の制約
- ビジネスロジックはservice層に書く。コンポーネントに書かない
- DBアクセスはrepository層を経由する。直接クエリを書かない
- 外部APIとの通信は必ずタイムアウトとリトライ処理を入れる

5. ドメイン固有の用語集 ［置き場所：CLAUDE.md（長くなったらSkillへ）］

業務知識が必要なプロジェクトでは、用語の意味を揃えておくことが重要です。

## 用語集
- 「確定」: ユーザーが入力内容を保存し、編集不可になった状態
- 「保留」: 承認待ちで、まだ確定していない状態
- 「アーカイブ」: 削除ではなく、表示上は隠すが履歴は保持する状態

これがないと、AIが「確定」と「保留」を意味的に混同したコードを書くことがあります。数十語を超える大きな用語集になったら、Skillの参考資料として切り出すと、毎回のトークンを抑えられます。

6. テストの書き方のルール ［置き場所：Skill］

テストの「型」を決めておくと、AIが生成するテストの質が安定します。「テストを書く」という作業の手順なので、Skill向きです。

---
name: write-tests
description: 対象ファイルの単体テストを書く。テスト追加を頼まれたときに使う
---

## テストの書き方
- テストファイルは対象ファイルと同じディレクトリに .test.ts で配置
- テストケース名は日本語で、何を検証しているか明確にする
- 1つのitブロックでは1つの観点に絞る
- モックは最小限に。実際のロジックをできるだけ通す

7. リリース前のチェックリスト ［置き場所：Skill］

人間が忘れがちなことは、AIにも忘れさせないようにしておきます。

---
name: release-check
description: リリース前の確認項目を1つずつ点検する
disable-model-invocation: true
---

## リリース前チェックリスト
- 環境変数の差分を確認したか
- マイグレーションファイルは本番環境でも実行可能か
- ログに個人情報が出力されていないか
- ロールバック手順は明確か

disable-model-invocation: true を付けると、AIが勝手に実行せず、人間が /release-check と呼んだときだけ動きます。リリースのような大事な場面向けの設定です。

大事なのは「育てる」という発想

CLAUDE.mdもSkillsも、一度書いたら終わりではありません。

AIを使う → 気づく → 追記する → チームで共有する。このサイクルを繰り返すことで、プロジェクトの成長と一緒に育っていきます。.claude/skills/ ごとリポジトリにコミットすれば、チーム全員が同じSkillを使えます。

最初から完璧な内容を目指す必要はありません。「これ、毎回同じことをAIに説明している気がする」と思った瞬間が、書くタイミングです。

RJCでは、こうした実践知をチームで共有しています

AIをどう使うかは、個人の工夫だけでなく、チームで蓄積していくものだと考えています。RJCでは、こうしたAI活用の知見を実際のプロジェクトの中で育てながら、エンジニアの成長につなげています。

この記事はRJC Techチームが執筆しました。