create-slash-commands

ユーザーが `/command-name` 構文で再利用可能なプロンプトを呼び出せる、効果的な Claude Code のスラッシュコマンドを作成します。スラッシュコマンドは現在の会話でプロンプトとして展開されるため、チームはワークフローや運用を標準化できます。このスキルでは、XML タグ、YAML フロントマター、動的なコンテキストの読み込み、インテリジェントな引数処理を用いたコマンドの構成方法を説明します。

<quick_start>

1. `.claude/commands/` ディレクトリを作成します（プロジェクト用）。または `~/.claude/commands/` を使用します（個人用）。 2. `command-name.md` ファイルを作成します。 3. YAML フロントマターを追加します（最低限、`description` を指定）。 4. コマンドプロンプトを記述します。 5. `/command-name [args]` でテストします。 **ファイル**：`.claude/commands/optimize.md`

---
description: Analyze this code for performance issues and suggest optimizations
---

Analyze the performance of this code and suggest three specific optimizations:

使用方法：/optimize

Claude は展開されたプロンプトを受け取り、コンテキスト内のコードを分析します。 </quick_start>

<xml_structure> 生成するすべてのスラッシュコマンドでは、明確さと一貫性を保つため、本文（YAML フロントマターの後）に XML タグを使用してください。

<required_tags>

<objective> - コマンドの動作と、その重要性

<objective>
What needs to happen and why this matters.
Context about who uses this and what it accomplishes.
</objective>

<process> または <steps> - コマンドの実行方法

<process>
Sequential steps to accomplish the objective:
1. First step
2. Second step
3. Final step
</process>

<success_criteria> - コマンドが成功したかどうかの判断方法

<success_criteria>
Clear, measurable criteria for successful completion.
</success_criteria>

</required_tags>

<conditional_tags>

<context> - 動的な状態やファイルを読み込む場合

<context>
Current state: ! `git status`
Relevant files: @ package.json
</context>

（注：実際に使用する際は、@ の後のスペースを削除してください）

<verification> - 確認が必要な成果物を作成する場合

<verification>
Before completing, verify:
- Specific test or check to perform
- How to confirm it works
</verification>

<testing> - ワークフローの一部としてテストを実行する場合

<testing>
Run tests: ! `npm test`
Check linting: ! `npm run lint`
</testing>

<output> - 特定のファイルを作成・変更する場合

<output>
Files created/modified:
- `./path/to/file.ext` - Description
</output>

</conditional_tags>

<structure_example>

---
name: example-command
description: Does something useful
argument-hint: [input]
---

<objective>
Process $ARGUMENTS to accomplish [goal].

This helps [who] achieve [outcome].
</objective>

<context>
Current state: ! `relevant command`
Files: @ relevant/files
</context>

<process>
1. Parse $ARGUMENTS
2. Execute operation
3. Verify results
</process>

<success_criteria>
- Operation completed without errors
- Output matches expected format
</success_criteria>

</structure_example>

<intelligence_rules>

シンプルなコマンド（単一の操作で、成果物を作成しない場合）：

• 必須：<objective>、<process>、<success_criteria>
• 例：/check-todos、/first-principles

複雑なコマンド（複数の手順があり、成果物を作成する場合）：

• 必須：<objective>、<process>、<success_criteria>
• 追加：状態を読み込む場合は <context>、ファイルを作成する場合は <verification>、作成するものを指定する場合は <output>
• 例：/commit、/create-prompt、/run-prompt

動的な引数を使用するコマンド：

• <objective> または <process> タグで $ARGUMENTS を使用します。
• フロントマターに argument-hint を含めます。
• 引数の用途を明確にします。

ファイルを作成するコマンド：

• 作成するものを指定した <output> タグを必ず含めます。
• 実施する確認事項を記述した <verification> タグを必ず含めます。

テストやビルドを実行するコマンド：

• 具体的なコマンドを記述した <testing> タグを含めます。
• <success_criteria> に合格・不合格の基準を含めます。 </intelligence_rules> </xml_structure>

<arguments_intelligence> このスキルでは、スラッシュコマンドに引数が必要かどうかを適切に判断してください。

<commands_that_need_arguments>

ユーザーが具体的な入力を指定する場合：

• /fix-issue [issue-number] - issue 番号が必要です
• /review-pr [pr-number] - PR 番号が必要です
• /optimize [file-path] - 最適化するファイルが必要です
• /commit [type] - コミットの種類が必要です（任意）

パターン： ユーザーが指定したデータを対象にタスクを実行します。

フロントマターに argument-hint: [description] を含め、本文で $ARGUMENTS を参照してください。 </commands_that_need_arguments>

<commands_without_arguments>

自己完結型の手順：

• /check-todos - 既知のファイル（TO-DOS.md）を対象に実行します
• /first-principles - 現在の会話を対象に実行します
• /whats-next - 現在のコンテキストを分析します

パターン： 暗黙のコンテキスト（現在の会話、既知のファイル、プロジェクトの状態）を対象にタスクを実行します。

argument-hint は省略し、$ARGUMENTS も参照しないでください。 </commands_without_arguments>

<incorporating_arguments>

<objective> タグ内：

<objective>
Fix issue #$ARGUMENTS following project conventions.

This ensures bugs are resolved systematically with proper testing.
</objective>

<process> タグ内：

<process>
1. Understand issue #$ARGUMENTS from issue tracker
2. Locate relevant code
3. Implement fix
4. Add tests
</process>

<context> タグ内：

<context>
Issue details: @ issues/$ARGUMENTS.md
Related files: ! `grep -r "TODO.*$ARGUMENTS" src/`
</context>

（注：実際に使用する際は、感嘆符の後のスペースを削除してください） </incorporating_arguments>

<positional_arguments>

構造化された入力には、$1、$2、$3 を使用します。

---
argument-hint: <pr-number> <priority> <assignee>
---

<objective>
Review PR #$1 with priority $2 and assign to $3.
</objective>

使用方法： /review-pr 456 high alice </positional_arguments> </arguments_intelligence>

<file_structure> プロジェクトコマンド：.claude/commands/

• バージョン管理を通じてチームと共有されます
• /help リストに (project) と表示されます

個人用コマンド：~/.claude/commands/

• すべてのプロジェクトで使用できます
• /help リストに (user) と表示されます

ファイル名：command-name.md → /command-name として呼び出します </file_structure>

<yaml_frontmatter>

**必須** - コマンドの動作を説明します

description: Analyze this code for performance issues and suggest optimizations

/help コマンドのリストに表示されます。

**任意** - Claude が使用できるツールを制限します

allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)

形式：

• 配列：allowed-tools: [Read, Edit, Write]
• 単一のツール：allowed-tools: SequentialThinking
• Bash の制限：allowed-tools: Bash(git add:*)

省略した場合：すべてのツールを使用できます </yaml_frontmatter>

コマンドファイル：.claude/commands/fix-issue.md

---
description: Fix issue following coding standards
---

Fix issue #$ARGUMENTS following our coding standards

使用方法：/fix-issue 123 high-priority

Claude が受け取る内容：「コーディング規約に従って、優先度の高いイシュー #123 を修正してください」

</all_arguments_string>

<positional_arguments_syntax>

コマンドファイル：.claude/commands/review-pr.md

---
description: Review PR with priority and assignee
---

Review PR #$1 with priority $2 and assign to $3

使用方法：/review-pr 456 high alice

Claude が受け取る内容：「優先度 high で PR #456 をレビューし、alice に割り当ててください」

高度なパターンについては、references/arguments.md を参照してください。 </positional_arguments_syntax>

<dynamic_context>

バッククォートの直前に感嘆符のプレフィックスを付けて（間にスペースを入れずに）、プロンプトの前に Bash コマンドを実行します。

注： 以下の例では、スキルの読み込み中に実行されないよう、感嘆符の後にスペースを入れています。実際のスラッシュコマンドでは、このスペースを削除してください。

例：

---
description: Create a git commit
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
---

## Context

- Current git status: ! `git status`
- Current git diff: ! `git diff HEAD`
- Current branch: ! `git branch --show-current`
- Recent commits: ! `git log --oneline -10`

## Your task

Based on the above changes, create a single git commit.

Bash コマンドが実行され、その出力が展開されたプロンプトに含まれます。 </dynamic_context>

<file_references>

特定のファイルを参照するには、@ プレフィックスを使用します。

---
description: Review implementation
---

Review the implementation in @ src/utils/helpers.js

（注：実際に使用する際は、@ の後のスペースを削除してください）

Claude は参照先ファイルの内容にアクセスできます。 </file_references>

<best_practices>

1. 常に XML 構造を使用する

# All slash commands should have XML-structured bodies

フロントマターの後には、XML タグを使用します。

• <objective> - 目的と理由（常に含めます）
• <process> - 実行方法（常に含めます）
• <success_criteria> - 完了の定義（常に含めます）
• 必要に応じて追加のタグ（xml_structure セクションを参照）

2. 説明を明確にする

# Good
description: Analyze this code for performance issues and suggest optimizations

# Bad
description: Optimize stuff

3. 状態に依存するタスクには動的コンテキストを使用する

Current git status: ! `git status`
Files changed: ! `git diff --name-only`

4. 適切な場合はツールを制限する

# For git commands - prevent running arbitrary bash
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)

# For analysis - thinking only
allowed-tools: SequentialThinking

5. 柔軟性を高めるために $ARGUMENTS を使用する

Find and fix issue #$ARGUMENTS

6. 関連ファイルを参照する

Review @ package.json for dependencies
Analyze @ src/database/* for schema

（注：実際に使用する際は、@ の後のスペースを削除してください） </best_practices>

<common_patterns>

シンプルな分析コマンド：

---
description: Review this code for security vulnerabilities
---

<objective>
Review code for security vulnerabilities and suggest fixes.
</objective>

<process>
1. Scan code for common vulnerabilities (XSS, SQL injection, etc.)
2. Identify specific issues with line numbers
3. Suggest remediation for each issue
</process>

<success_criteria>
- All major vulnerability types checked
- Specific issues identified with locations
- Actionable fixes provided
</success_criteria>

コンテキスト付き Git ワークフロー：

---
description: Create a git commit
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
---

<objective>
Create a git commit for current changes following repository conventions.
</objective>

<context>
- Current status: ! `git status`
- Changes: ! `git diff HEAD`
- Recent commits: ! `git log --oneline -5`
</context>

<process>
1. Review staged and unstaged changes
2. Stage relevant files
3. Write commit message following recent commit style
4. Create commit
</process>

<success_criteria>
- All relevant changes staged
- Commit message follows repository conventions
- Commit created successfully
</success_criteria>

パラメーター付きコマンド：

---
description: Fix issue following coding standards
argument-hint: [issue-number]
---

<objective>
Fix issue #$ARGUMENTS following project coding standards.

This ensures bugs are resolved systematically with proper testing.
</objective>

<process>
1. Understand the issue described in ticket #$ARGUMENTS
2. Locate the relevant code in codebase
3. Implement a solution that addresses root cause
4. Add appropriate tests
5. Verify fix resolves the issue
</process>

<success_criteria>
- Issue fully understood and addressed
- Solution follows coding standards
- Tests added and passing
- No regressions introduced
</success_criteria>

ファイル指定コマンド：

---
description: Optimize code performance
argument-hint: [file-path]
---

<objective>
Analyze performance of @ $ARGUMENTS and suggest specific optimizations.

This helps improve application performance through targeted improvements.
</objective>

<process>
1. Review code in @ $ARGUMENTS for performance issues
2. Identify bottlenecks and inefficiencies
3. Suggest three specific optimizations with rationale
4. Estimate performance impact of each
</process>

<success_criteria>
- Performance issues clearly identified
- Three concrete optimizations suggested
- Implementation guidance provided
- Performance impact estimated
</success_criteria>

使用方法：/optimize src/utils/helpers.js

その他の例については、references/patterns.md を参照してください。 </common_patterns>

<reference_guides>

引数のリファレンス：references/arguments.md

• $ARGUMENTS 変数
• 位置引数（$1、$2、$3）
• 解析方法
• 公式ドキュメントの例

パターンのリファレンス：references/patterns.md

• Git ワークフロー
• コード分析
• ファイル操作
• セキュリティレビュー
• 公式ドキュメントの例

ツールの制限：references/tool-restrictions.md

• Bash コマンドのパターン
• セキュリティのベストプラクティス
• ツールを制限する場面
• 公式ドキュメントの例 </reference_guides>

<generation_protocol>

1. ユーザーのリクエストを分析する：

   • コマンドの目的は何ですか？
   • ユーザー入力（$ARGUMENTS）が必要ですか？
   • ファイルや成果物を生成しますか？
   • 検証やテストが必要ですか？
   • シンプル（単一ステップ）ですか、それとも複雑（複数ステップ）ですか？

2. フロントマターを作成する：

   ---
   name: command-name
   description: Clear description of what it does
   argument-hint: [input] # Only if arguments needed
   allowed-tools: [...] # Only if tool restrictions needed
   ---
   

3. XML 構造の本文を作成する：

   常に含める項目：

   • <objective> - 目的と理由
   • <process> - 実行方法（番号付き手順）
   • <success_criteria> - 完了の定義 該当する場合に含めます：
   • <context> - 動的な状態（! commands）またはファイル参照（@ files）
   • <verification> - 成果物を作成する場合に実施するチェック
   • <testing> - テストがワークフローに含まれる場合のテストコマンド
   • <output> - 作成／変更したファイル

4. $ARGUMENTS を適切に組み込みます：

   • ユーザー入力が必要な場合：argument-hint を追加し、タグ内で $ARGUMENTS を使用します
   • 自己完結している場合：argument-hint と $ARGUMENTS は省略します

5. 適切に判断します：

   • シンプルなコマンド：簡潔にまとめます（目的＋手順＋成功基準）
   • 複雑なコマンド：必要に応じてコンテキスト、検証、テストを追加します
   • シンプルなコマンドを過剰に複雑化しないでください
   • 複雑なコマンドの仕様を不十分にしないでください

6. ファイルを保存します：

   • プロジェクト：.claude/commands/command-name.md
   • 個人用：~/.claude/commands/command-name.md </generation_protocol>

<success_criteria> 適切に構成されたスラッシュコマンドは、次の基準を満たします。

YAML フロントマター：

• description フィールドが明確かつ簡潔である
• コマンドが引数を受け取る場合、argument-hint がある
• ツールの制限が必要な場合、allowed-tools が指定されている

XML 構造：

• 必須の 3 つのタグがすべて含まれている：<objective>、<process>、<success_criteria>
• 複雑さに応じて条件付きタグが適切に使用されている
• 本文に生の Markdown 見出しがない
• すべての XML タグが正しく閉じられている

引数の処理：

• コマンドがユーザー指定のデータを扱う場合、$ARGUMENTS が使用されている
• 構造化された入力が必要な場合、位置引数（$1、$2 など）が使用されている
• 自己完結したコマンドでは $ARGUMENTS を参照していない

機能性：

• コマンドが呼び出し時に正しく展開される
• 動的なコンテキストが正しく読み込まれる（bash コマンド、ファイル参照）
• ツールの制限によって、許可されていない操作が防止される
• コマンドが意図した目的を確実に達成する

品質：

• <process> タグ内の指示が明確で実行可能である
• <success_criteria> に測定可能な完了基準がある
• 適切な詳細度である（シンプルなタスクを過剰に複雑化していない）
• 有用な場合に例が示されている </success_criteria>