直接回答
Skills は知識とプロセスを再利用し、Subagents は調査や専門タスクを隔離する。両者が解決する問題は異なる。
このガイドで解決できること
チームが成熟した用法を保守可能な拡張として定着させ、同時にコンテキストと権限を制御できるようにする。
まず Skill が必要か Subagent が必要かを判断する
Skill はオンデマンドで読み込めるドメイン知識や繰り返しのワークフローであり、API 規約、リリースフロー、定型のトラブルシューティング手順に適している。Subagent は独立したコンテキストとツール群を持つエージェントで、大量のファイル読み込み、専門的なレビュー、並列調査に適している。
リアルタイムの外部システムが必要な場合のみ MCP を使い、ライフサイクルで確実に実行させたい場合は Hooks を使う。短いプロンプトひとつのために拡張一式を作らない。
最小のプロジェクト Skill を作成する
プロジェクト Skill は .claude/skills/<name>/SKILL.md にある。frontmatter は少なくとも明確な名称と説明を提供し、Claude がいつ読み込むべきか判断できるようにする。本文にはプロジェクト固有のルール、手順、検証方法を記載する。
説明にはトリガーシーンを記し、本文には実行に必要な内容だけを残す。大量の参考資料は Skill ディレクトリ内の別ファイルに切り分け、Claude がオンデマンドで読み込めるようにする。
---
name: api-conventions
description: このプロジェクトの REST API を追加または変更するときに使用する
---
# API conventions
- URL パスには kebab-case を使用する。
- 一覧エンドポイントはページネーションに対応させる。
- エンドポイント変更後に `pnpm test api` と `pnpm typecheck` を実行する。副作用のあるワークフローは手動トリガーにする
Skill は Issue の読み込みからテスト、PR の作成までの完全なフローを記述できる。リリース、コミット、外部書き込みの副作用を持つ Skill は、意味の類似性だけでモデルに自動トリガーされないようにすべきである。
手動呼び出しを使えば、パラメータは $ARGUMENTS を経由してワークフローに入る。スクリプトには引き続き権限承認が必要で、Skill 自体が Claude Code のセキュリティルールを回避することはない。
---
name: fix-issue
description: 指定した GitHub Issue を修正する
disable-model-invocation: true
---
Issue を修正: $ARGUMENTS
1. `gh issue view` で Issue を読む。
2. 再現テストを追加して根本原因を修正する。
3. 影響を受けるテストと lint を実行する。
4. 差分を提示し、承認を待ってから PR を作成する。専門レビュー用のカスタム Subagent を作成する
カスタム Subagent は .claude/agents/ に置き、frontmatter で名称、説明、モデル、使用可能なツールを定義する。独立したコンテキストで動作し、最終的に精緻化された結果をメインセッションに返す。
ツール権限はタスクに応じて最小化すべきである。コードレビューのみを行うエージェントは通常 Read、Grep、Glob が必要で、実際に検証を実行する場合にのみ制限付き Bash を追加する。
---
name: security-reviewer
description: 現在の変更に悪用可能なセキュリティ欠陥がないかレビューする
tools: Read, Grep, Glob
model: opus
---
認証回避、インジェクション、秘密情報の漏えい、安全でないデータ処理を確認する。
正確性またはセキュリティ境界に影響する問題だけを、ファイル位置と悪用経路とともに報告する。
スタイルだけのリファクタリングは提案しない。調査と独立レビューを Subagents に委譲する
委譲に適したタスクは、明確な問題、スコープ、戻り値のフォーマットを持つべきである。例えば token refresh パスの特定や、PLAN.md に従って現在の diff のみをレビューするなど。メインエージェントはサブエージェントが読んだすべてのファイルを受け取る必要はない。
実装後の独立レビューは新しいコンテキストを使うことで、エージェントが自身の案を擁護する傾向を減らせる。ただしレビューのプロンプトは真に正確性に関する問題に限定し、発見を産出するために過剰に設計しないようにする。
1 つのサブエージェントで auth モジュールの token refresh 処理を追跡し、再利用できるテスト用ツールを探してください。
コードは変更せず、ファイルパス、呼び出し経路、不確定な点を返してください。
実装後は別のサブエージェントで現在の差分を PLAN.md と照合してください。
要件、正確性、セキュリティに影響する不足だけを報告してください。テスト、レビュー、拡張コストの制御
Skill と Subagent ファイルはコードレビューに含め、代表的なタスクで正しくトリガーされるか、ツールの境界が守られているかを検証する。説明が広すぎると誤トリガーし、本文が長すぎるとコンテキストが増える。
サブエージェントは独立したコンテキストを持つが、それでも token を消費し、並列でファイルを変更する可能性がある。デフォルトでは調査エージェントを読み取り専用にし、並列編集が必要な場合は独立した worktree を使用し、ファイルの所有権を明確にする。
- 各拡張にメンテナ、用途、検証タスクを明記する。
- 重複、期限切れ、モデルが既に確実に処理できる説明を削除する。
- 外部の書き込み操作には権限と人による確認を残す。
/contextと実行記録を使って実際の読み込みと呼び出しを照合する。
公式情報と検証範囲
本ガイドは公開されている公式ドキュメントを根拠にしています。コマンドや設定はクライアントのバージョンにより変わるため、実行前に参照元も確認してください。
ドキュメントの適用範囲を見る