Claude Code Skills入門：コマンド一覧とチームで使える5つのテンプレート

役立つチーム用コマンドには、必要な入力、確認すべき根拠、回答の形式が明記されています。コードと一緒に保管する作業指示書と考えるとわかりやすいでしょう。コマンド名を入力すれば、その指示書に今回の作業内容が当てはまります。

まずは /plan、/diff、/context、/compact から始め、その後で下のテンプレートにある /team-pr-check を追加しましょう。 最初の用途にはレビューが向いています。権限やデータ、テストについて確認すべきことは、変更のたびに繰り返し出てくるからです。

Claude Code コマンド一覧：まず覚えたい標準コマンド

Claude Code内のメッセージの先頭に入力して使います。角括弧は省略可能な引数、山括弧は必須の引数を表します。以下では、2026年10月13日に確認したAnthropicのコマンドリファレンスにある構文をそのまま載せています。利用できるコマンドは、プラットフォーム、プラン、環境によって異なります。

同じ作業を続けるときは /compact、別の作業に移るときは /clear を使います。機能開発を続ける場合は、/compact keep the acceptance criteria, unresolved risks, and exact test commands のように指示すると便利です。

/release-notes が開くのは、Claude Code自体の変更履歴です。開発中のアプリケーションのリリースノートを作るコマンドではありません。そのため、後述のカスタムコマンドには別の名前を付けています。

これらの操作を日々の開発に取り入れる方法は、Claude Codeのベストプラクティスで紹介しています。

コマンドメニューには同梱スキルも表示されます

スラッシュで始まる項目の中には、Claudeに実行手順を渡すものもあります。これらは同梱スキルであり、CLIに組み込まれた固定の操作コマンドとは区別されます。

• /code-review は差分など、対応している対象をレビューします。/review はその別名です。--fix を付けると修正を、--comment を付けるとレビューコメントの投稿を依頼します。
• /simplify は変更したコードを見直し、整理できる箇所を修正します。
• /verify はアプリケーションをビルドして実行し、動作を確認します。
• /doctor はセットアップの問題を診断し、修正案を提示します。

変更を加える前に指摘事項を確認したい場合は、修正を指定せずにレビューを実行しましょう。各コマンドの詳しい構文、前提条件、利用可能な環境は、コマンドリファレンスの同梱スキルの項目で確認できます。

Claude Code Skillsでカスタムコマンドを作る

新しく作る場合は、Markdown形式の指示ファイルをリポジトリの .claude/skills/<name>/SKILL.md に保存します。チームで同じ手順を使えるよう、ファイルをコミットしましょう。個人用の手順は ~/.claude/skills/<name>/SKILL.md に置きます。

従来の .claude/commands/<name>.md 形式も引き続き使えます。どちらの形式でも /<name> コマンドが作成されます。スキルのディレクトリには、テンプレート、参考資料、スクリプトも置けます。手順が複雑になってきたら、こちらの形式を選ぶとよいでしょう。Anthropicのスキルガイド

プラグインとMCPのコマンドはどこから来るのでしょうか

プラグインは、再利用できるように機能をまとめたパッケージです。 skills/<name>/SKILL.md フォルダから、/plugin-name:skill-name のような名前空間付きのコマンドが作られます。従来形式のプラグインコマンドは commands/ に置きます。これらのフォルダは、マニフェストを格納する .claude-plugin/ ディレクトリの中ではなく、それと同じ階層のプラグインルートに配置します。管理には /plugin を使い、変更後は /reload-plugins を実行します。プラグインの構成要素

手順を使うコードベースが1つなら、まずはプロジェクトのスキルから始めましょう。同じ手順を複数のリポジトリで保守・配布する必要が出てきたら、プラグインを検討します。自作する前に評価しておきたい既存のパッケージは、おすすめのClaude Codeプラグインで紹介しています。

MCPプロンプトは、接続先のサーバーが提供します。 MCPはModel Context Protocolの略で、Claude Codeを外部のツールやデータにつなぐ仕組みです。サーバーは、再利用可能なプロンプトも公開できます。メニューには /servername:promptname (MCP) と表示され、/mcp__servername__promptname でも呼び出せます。表示されるのは、接続先のサーバーがそのプロンプトを公開している場合だけです。ツール連携があるからといって、必要なプロンプトがすべて用意されているとは限りません。MCPプロンプトのドキュメント

MCPプロンプトの引数は空白で分割され、サーバー側で定義されたパラメーターに従います。プロンプトの結果は会話に取り込まれます。引数の扱いがローカルのスキルと同じだとは考えないでください。

ファイルの書き方と引数の渡し方

フロントマターは、Markdownの指示文より前に置く短いYAML形式の設定ブロックです。開始を示す --- は、必ずファイルの先頭行に置きます。以下は、この記事のテンプレートに関係するフィールドです。

allowed-tools は権限を付与する設定であり、使用できるツールをその一覧だけに制限するものではありません。フロントマターのフィールドはすべて省略可能ですが、description の記載は推奨されています。従来のコマンドファイルでも、name と paths を除く同じフィールドが使えます。フロントマターのリファレンス

引数： $ARGUMENTS には入力文字列全体が入ります。$0 または $ARGUMENTS[0] は最初の引数、$1 は2番目の引数を表します。名前付き引数は、定義した順に位置引数へ対応します。複数の単語からなる値を1つの位置引数として渡す場合は、引用符で囲みます。argument-hint は入力の説明を表示するだけなので、手順の中でも入力を確認する必要があります。引数の置換

以下のテンプレートでは name を省略しているため、フォルダ名がコマンド名になります。フロントマターは従来のコマンドファイル形式でも使えます。リポジトリについて長く参照する情報はチームの共有メモリであるCLAUDE.mdに、特定の作業の手順はそのスキルに記述しましょう。

チームで使えるカスタムコマンドのテンプレート5選

以下に示すフォルダをそれぞれ作成し、コードブロックの内容を SKILL.md に貼り付けてください。作成後は /reload-skills を実行して新しいファイルを再スキャンします。いずれも用途に合わせて調整するための独自テンプレートであり、Anthropicが同梱するコマンドでも、テスト結果を示したものでもありません。

繰り返し行う開発上のチェックを先に、情報共有の作業を後に並べています。可能な限り、ローカルのリポジトリにある情報を根拠として使います。実用的な結果を得るために、課題管理ツールやPRサービスへの接続は必要ありません。

顧客データに関わる変更を確認するPRレビュー

小規模なSaaSチームなら、人によるレビューを依頼する前に使えます。作成者が急いでいるときでも、テナントの分離、認可、テストの網羅性について同じ観点で確認できます。各指摘に該当箇所と問題が起きる条件を添えることで、レビューへの引き継ぎを安定させます。

.claude/skills/team-pr-check/SKILL.md として保存します。/team-pr-check main で呼び出すと、main とのマージベースを基準に現在のブランチをレビューします。

---
description: Review a branch against the team's business-risk checklist
argument-hint: "[base-ref]"
disable-model-invocation: true
---

Review the current branch against this base ref: $ARGUMENTS
If no base is supplied, ask for it. Confirm it exists locally.
Read CLAUDE.md and any repository review guidance first.
Inspect the diff from the merge base to HEAD. Report uncommitted
changes separately; do not silently mix them into the branch review.

Check:
- Authorization and tenant boundaries on every changed data path.
- Validation, failure handling, retries and duplicate side effects.
- Schema compatibility, rollout assumptions and rollback options.
- Regression coverage for the changed behavior.
- Secrets, sensitive logs and changes to public contracts.

For each finding: severity, file and line, triggering scenario,
user impact and a concrete repair or test. Separate verified findings
from questions. Mark checks you could not assess as unknown.
Return findings first, then the checklist with pass/fail/unknown
and supporting evidence. If none are found, say so and name gaps.
Review only. Do not edit files, post comments, approve or merge.

チェックリストに価値があるのは、実際に起き得る問題を反映しているときです。汎用的な項目を、アカウントの所有関係、請求の状態、チーム経由で継承される権限など、自社のプロダクトで重要な境界の確認に置き換えましょう。

再現できるバグを、失敗するテストから修正する

稼働中のプロダクトを自ら保守する創業者なら、具体的な再現手順があるバグ報告に使えます。失敗する動作と回帰テストを作業指示に組み込むため、もっともらしい修正パッチを作るだけで終わらなくなります。

.claude/skills/team-test-first-fix/SKILL.md として保存します。呼び出し例は /team-test-first-fix duplicate webhook events create duplicate invoices です。

---
description: Reproduce a bug with a failing test before fixing it
argument-hint: "[bug description or local issue file]"
disable-model-invocation: true
---

Bug: $ARGUMENTS
If the expected behavior is unclear, ask before changing code.
Read CLAUDE.md, inspect the working tree and preserve unrelated edits.
Find the relevant code and the repository's existing test runner.
Use local fixtures or mocks; do not call production services.

Add the smallest regression test that demonstrates the reported bug.
Run it before changing implementation. Confirm that it fails for
this bug, not because the environment or test setup is broken.
If you cannot demonstrate that failure, explain the blocker and stop.

Make the smallest implementation change that fixes the behavior.
Rerun the regression test and relevant nearby tests. Do not weaken
assertions to obtain a pass or expand into unrelated refactoring.

Report the cause, changed files, failing-before evidence,
passing-after evidence and any tests you could not run.
Do not commit, push or deploy.

この手順は、再現可能な不具合に向いています。本番で断続的に起きていて、判断材料も不足している障害なら、まずは調査から始めましょう。無理にコマンドを実行して、失敗するテストをでっち上げさせるべきではありません。

共有システムを変更する前に移行計画を立てる

データベースのスキーマ変更やAPIの置き換えを行うチームなら、実装前に作業順序や互換性の論点を洗い出すために使えます。目指すのは、ほかのメンバーが検討し、問題点を指摘できる計画です。とくに、新旧のバージョンが同時に動く期間の扱いが重要になります。

.claude/skills/team-migration-plan/SKILL.md として保存します。呼び出し例は /team-migration-plan "billing storage" "new invoice schema" です。

---
description: Plan a migration with compatibility checks and rollback gates
argument-hint: "[scope] [target-state]"
arguments: [scope, target]
disable-model-invocation: true
---

Plan a migration of $scope to $target.
If either input is missing or ambiguous, ask for clarification.
Read CLAUDE.md and inspect the current implementation and consumers.
Do not edit files, execute migrations or connect to production.

Describe the current state with file references. List affected data,
APIs, background jobs, integrations and deployment dependencies.
Separate verified facts from assumptions that need an owner.

Propose small phases with dependencies, acceptance checks and a
stop/go decision for each. Include compatibility between old and new
versions, backfill validation, retries and observability.
For each phase, describe rollback or recovery. Flag irreversible
steps and data that a code rollback cannot restore.

Return a reviewable plan, open questions and the smallest safe pilot.
Do not invent a duration, data volume or owner.

計画を立てるよう指示しても、Claude Codeの権限モードは変わりません。セッションもPlan Modeにしたい場合は、スキルを呼び出す前に /plan を入力してください。記述した手順と、セッションでツールに与える権限は、別々に管理するものとして扱いましょう。Plan Mode

自社プロダクトのリリースノートを作る

リリースを担当する開発者なら、指定した変更範囲から顧客向けの下書きを作るために使えます。コミットの内容をユーザーへの影響として説明し直す手間を減らしながら、各記述に根拠を求めます。

.claude/skills/team-release-notes/SKILL.md として保存します。/team-release-notes previous-release HEAD で呼び出し、previous-release は実在するタグやコミットに置き換えてください。

---
description: Draft product release notes from a verified Git range
argument-hint: "[base-ref] [head-ref]"
arguments: [base, head]
disable-model-invocation: true
---

Draft release notes for $base..$head.
If either ref is missing, ask. Confirm both resolve locally.
Read CLAUDE.md and the project's existing release-note format.
Inspect commits in the range and compare the endpoint trees.
Use the changed code and tests to verify what each change does.

Group the draft into Added, Changed, Fixed and Breaking Changes.
Omit empty sections. Describe user impact without exposing internal
secrets or vulnerability details that need coordinated disclosure.
Attach a commit or file reference to each item for the reviewer.
Do not claim a change is deployed, enabled for every customer or
faster by a measured amount without evidence of that fact.

Finish with upgrade actions, unresolved questions and any changes
excluded because their impact could not be established.
Return a draft in chat. Do not edit the changelog, tag a release,
publish, send messages or deploy.

コードの範囲から確認できるのは、リポジトリで何が変わったかです。その変更がどの顧客に提供されたかまでは証明できません。下書きを公開する前に、展開状況を確認しましょう。

チーム向けの週次変更レポートをまとめる

開発チームのリーダーなら、プロダクト部門やサポート部門への週次報告に使えます。マージ済みの作業と、リリースを確認できた変更を分けるため、まだフラグで無効化されている機能を誤って告知するのを防げます。

.claude/skills/team-weekly-changelog/SKILL.md として保存します。/team-weekly-changelog START_DATE END_DATE main で呼び出し、日付部分をタイムゾーン付きのISOタイムスタンプに置き換えてください。集計範囲は開始時刻を含み、終了時刻を含みません。

---
description: Draft a weekly engineering changelog from branch history
argument-hint: "[since] [until] [branch]"
arguments: [since, until, branch]
disable-model-invocation: true
---

Prepare a weekly changelog for $branch from $since inclusive to
$until exclusive. If an input is missing, ask. Confirm the timezone
and that the branch exists locally. State whether its checkout may
be stale; do not fetch or assume it matches the remote.

Read CLAUDE.md and the team's update format. Inspect commits reachable
from the branch, filtering by committer timestamp in this window.
Explain that commit timestamps do not prove merge or release dates.
Read diffs for claimed outcomes. Group related changes into themes
and avoid counting a merge and its constituent commits as separate
outcomes. Separate product changes, fixes and maintenance.

For each item, give its impact and a commit or file reference.
Label release status unknown unless deployment evidence is available.
Do not infer blockers, revenue, adoption or completion percentages
from commit messages. List evidence gaps at the end.
Return a concise draft in chat. Do not write files or send the update.

リリースノートと週次報告は分けて運用しましょう。リリースノートには明確なコードの範囲があり、読み手は顧客です。週次報告には報告対象の期間があり、まだリリースされていない有用な作業も含まれます。

使い続ける価値のあるコマンドとは？

最初の回答の見栄えではなく、モデルの前後で繰り返し発生する作業を測りましょう。

週あたりの効果は、実行回数 ×（導入前の準備・手直し時間 − 導入後の準備・手直し時間）× チームの時間単価 − モデル利用費の増加分 − 保守時間を同じ時間単価で換算した費用、で計算します。 自分たちの実測値を当てはめてください。自動化が進んだように感じても、長いプロンプトによって確認や手直しが増えれば、費用面では逆効果になり得ます。

最も変化しやすいコストは、経験豊富な開発者が同じ手順を説明したり、不十分な引き継ぎを補ったりする時間です。アーキテクチャやリリースの手順が変われば、コマンドの手順も保守する必要があります。

保存済みのコマンドでも、Claudeがその指示を実行すればモデルの使用量は発生します。/usage にはトークンコストの推定値やプランの使用状況が表示されますが、表示されたAPIコストの推定値がサブスクリプションの請求額になるわけではありません。Anthropicのコストに関するドキュメント

これらのコマンドを基に事業化できる2つの用途

テンプレートは社内ツールとして役立ちます。ただし、プロダクトとして提供するには、プロンプトを保存するだけでは得られない強みが必要です。

最も有望なのは、リポジトリ固有のレビュー項目

小規模なソフトウェア開発チームなら、自社でリスクの高い境界を把握し、継続的に保守されるレビューパッケージに対価を払う可能性があります。どのテーブルがどのアカウントに属するか、どの操作が請求に影響するか、変更時にどのテストが必要か、といった知識を持つパッケージです。

2026年10月13日に取得したDataForSEOの米国・英語のGoogleキーワード概要では、「ai code review」の推定月間検索数は1,300件でした。この数字はコードレビューという作業への関心を示すもので、特定のClaude Codeプラグインへの需要を示すものではありません。DataForSEO Keyword Overview

販売できる最小構成としては、プロジェクトのチェックリスト、補足のアーキテクチャ資料、過去のバグを集めた評価セットが考えられます。プラグインとして配布する前に、それらの事例に対して根拠のある指摘を出せるか確認しましょう。

課題は競争の厳しさです。Claude Codeにはすでにレビュー機能があり、CodeRabbitもコードレビューツールを販売しています。汎用的なレビュープロンプトだけでは、差別化として弱いでしょう。私なら、特定のチームで過去に起きた不具合を把握でき、チェック項目の正確さを保つ担当者もいる場合に限って、この用途を選びます。

より小さく始められるのは、根拠付きのリリース情報共有

プロダクトチームには、リポジトリの変更を顧客向けのリリースノートとサポート向けの社内資料にまとめる、継続的に保守されるワークフローが役立つ可能性があります。参照元を添え、展開状況を明示的に確認する仕組みも含めます。

同じキーワード概要では、「release notes generator」の推定月間検索数は70件でした。検索から読み取れる関心は小規模なので、私なら独立したソフトウェアを開発する前に、サービスや社内ワークフローとして始めます。DataForSEO Keyword Overview

最小構成では、指定したGitの範囲から、チームで決まっている形式の下書きを作成できます。難しいのは、コードの変更をフラグ、デプロイ状況、顧客が実際に利用できる状態と結び付けることです。コマンドは根拠を整理できますが、チームが記録していない根拠を作り出すことはできません。

業務用のコードベースで押さえておきたい限界

コマンドが標準化するのは指示です。結果を受け入れられるかどうかは、引き続きテスト、レビュー、リリース管理で判断します。 5つのテンプレートは手順作りの出発点として使い、変更するときはアプリケーションのコードと同様にレビューしましょう。

スキルの全文は使用時に読み込まれるため、手順は簡潔にし、詳しい参考情報は補助ファイルへ分けます。同じ名前のスキルがあると、個人用のスキルがプロジェクトのスキルより優先されることがあります。ローカルのターミナルセッションでは、スキルが標準コマンドより優先される場合もあります。区別しやすい名前を付け、メンバーによって動作が異なるときは読み込み元を確認してください。スキルの読み込みと優先順位

権限については、実際のツールのルールを別途設定します。「レビューのみ」と書けばClaudeに意図は伝わりますが、それはOSによる制限ではありません。Claude Codeの権限

週明けにまず取り組むこと

最初に /team-pr-check をコミットしましょう。汎用的な箇条書きを、直近で問題になった変更で本来確認すべきだった項目に置き換えます。結果を把握している完了済みの変更に対して実行し、指摘内容を実際の問題と照らし合わせてください。チームの習慣にする前に、その結果を基に手順を調整します。リリースノートと週次報告のコマンドは、出力形式の合意ができてから追加しましょう。

こうしたワークフローを業務システムにつなげたい場合は、チームが実際に必要とするチェックに合わせてAI自動化の仕組みを構築します。