slash-command-builder

スラッシュコマンドビルダー

適切な構造、動的な機能、ベストプラクティスに沿って、Claude Code 用の効果的なカスタムスラッシュコマンドを作成します。

クイックリファレンス

コマンドファイルの場所：

• プロジェクト用（共有）：.claude/commands/name.md
• 個人用（個別）：~/.claude/commands/name.md

動的な機能：

• 引数：$ARGUMENTS（すべて）または $1、$2、$3（位置指定）
• Bash の実行：[execute: command]（allowed-tools: Bash(...) が必要です）
• ファイル参照：@path/to/file

フロントマター：description、allowed-tools、argument-hint、model を指定する任意の YAML

スラッシュコマンド作成ワークフロー

フェーズ 1：要件の確認

AskUserQuestion を使って、必要な内容を確認します。

1. コマンドで何を実行しますか？

   • どのタスクやプロンプトを自動化しますか？
   • 期待する結果は何ですか？

2. 誰が使いますか？

   • 自分だけ（個人用コマンド）
   • チーム（プロジェクト用コマンド）

3. 動的な入力は必要ですか？

   • 固定のプロンプト（引数なし）
   • ユーザーが指定する値（引数が必要）
   • システムのコンテキスト（Bash の実行）
   • ファイルの内容（ファイル参照）

4. どのツールへのアクセスが必要ですか？

   • 読み取り専用の分析（Read、Grep、Glob）
   • Git 操作（Bash(git:*)）
   • フルアクセス（デフォルト、制限なし）

フェーズ 2：スコープの選択

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

• 個人用のショートカット
• 実験的なコマンド
• 個人のワークフローの自動化
• チームとは共有しません

プロジェクト用コマンド（.claude/commands/）：

• チームで共有するコマンド
• 標準化されたワークフロー
• Git にコミットされます
• チームメンバー全員が利用できます

フェーズ 3：構造の設計

基本的なコマンド構造：

---
description: Brief description for /help
allowed-tools: Optional tool restrictions
argument-hint: Optional argument guidance
---

[Your prompt here]

判断の流れ：

1. 基本のプロンプトから始めます
2. 必要に応じて引数を追加します（$ARGUMENTS または $1/$2）
3. コンテキストが必要なら Bash の実行を追加します（[execute: command]）
4. ファイルを分析する場合はファイル参照を追加します（@path）
5. 説明と制限を指定するフロントマターを追加します

フェーズ 4：実装

ステップ 1：ファイルを作成する

# For project commands
touch .claude/commands/your-command.md

# For personal commands
touch ~/.claude/commands/your-command.md

ファイル名（.md を除く）がコマンド名になります。

ステップ 2：コマンドを記述する

templates/ ディレクトリのテンプレートを使用します。

• basic-command.md - シンプルなプロンプト
• with-arguments.md - 動的な入力を使用
• with-bash.md - Bash の実行を使用
• with-files.md - ファイル参照を使用
• complex-command.md - すべての機能を組み合わせたコマンド

ステップ 3：フロントマターを追加する（推奨）

---
description: What this command does (appears in /help)
allowed-tools: Read, Grep, Glob  # Optional restrictions
argument-hint: [arg1] [arg2]     # Optional user guidance
---

フェーズ 5：テスト

1. コマンドが表示されることを確認する：

   /help
   

   一覧にコマンドが表示されていることを確認します。

2. 基本的な呼び出しをテストする：

   /your-command
   

3. 引数を指定してテストする（該当する場合）：

   /your-command arg1 arg2
   

4. Bash の実行をテストする（該当する場合）：

   • コマンドが実行されることを確認します
   • 出力がプロンプトに表示されることを確認します

5. ファイル参照をテストする（該当する場合）：

   • ファイルが正しく読み込まれることを確認します
   • パスが解決されることを確認します

6. チームでテストする（プロジェクト用コマンドの場合）：

   • チームメイトに試してもらいます
   • フィードバックを集めます
   • 実際の使用状況に基づいて改善します

フェーズ 6：反復

シンプルな状態から始めて、段階的に機能を追加します。

1. 最初に：動的な機能を使わない基本のプロンプトを作成します
2. テスト：動作することを確認します
3. 追加：機能を 1 つ追加します（引数、Bash、ファイルのいずれか）
4. テスト：追加した機能が動作することを確認します
5. 繰り返し：必要に応じて次の機能を追加します

一度にすべての機能を追加しようとしないでください。段階的に構築しましょう。

よく使われるコマンドパターン

パターン 1：コード分析

---
description: Analyze code for [specific criteria]
allowed-tools: Read, Grep, Glob
argument-hint: [file-or-directory]
---

Analyze @$1 for:
1. [Criterion 1]
2. [Criterion 2]
3. [Criterion 3]

Provide specific findings with examples.

パターン 2：Git ワークフロー

---
description: [Git operation] with context
allowed-tools: Bash(git:*)
---

## Current State

Branch: [execute: git branch --show-current]
Status: [execute: git status --short]

## Task

[What to do with this context]

パターン 3：コード生成

---
description: Generate [artifact] following patterns
allowed-tools: Read, Grep, Glob, Write
argument-hint: [what-to-generate]
---

## Existing Patterns

@[relevant examples]

## Task

Generate $ARGUMENTS following the patterns above.

パターン 4：詳細な分析

---
description: Deep analysis of [topic]
---

Think deeply about $ARGUMENTS considering:
1. [Aspect 1]
2. [Aspect 2]
3. [Aspect 3]

[Extended thinking triggered by keywords]

実例

動作する完全な例については、examples/ を参照してください。

• git-workflows.md - コミット、PR、ブランチ用コマンド
• code-analysis.md - レビュー、セキュリティ、パフォーマンス
• code-generation.md - テスト、ドキュメント、定型コード

高度な機能

引数：$ARGUMENTS と $1/$2

$ARGUMENTSを使う場合：

• すべての入力を1つのブロックとして扱いたい場合
• 自由形式のテキスト（メッセージ、説明）
• 各部分を個別に参照する必要がない場合

$1、$2、$3を使う場合：

• 構造化されたパラメーターが必要な場合
• 異なる部分を別々の場所で使う場合
• 引数が省略されたときのデフォルト値を設定したい場合

例：

# $ARGUMENTS approach
Explain $ARGUMENTS in detail.

# Positional approach
Review PR #$1 with priority $2 assigned to $3.

Bash の実行

プロンプトが実行される前にコマンドを実行します。

---
allowed-tools: Bash(git:*)
---

Current branch: [execute: git branch --show-current]
Recent commits: [execute: git log --oneline -5]

要件：

1. allowed-tools: Bash(...)を含める必要があります
2. [execute: command]の構文を使います（バッククォートが必要です）
3. 出力は取得され、プロンプトに含まれます

セキュリティ：特定のツールパターンを指定して Bash へのアクセスを制限します。

allowed-tools: Bash(git:*)          # Git only
allowed-tools: Bash(npm:*), Bash(git:*)  # npm and git

ファイル参照

@プレフィックスを付けてファイルの内容を含めます。

Review @src/auth/login.js for security issues.

機能：

• ファイルのディレクトリ階層からCLAUDE.mdを自動的に含めます
• 相対パスと絶対パスの両方に対応します
• ディレクトリは内容ではなく一覧を表示します

Frontmatter の設定

frontmatter のオプション一覧：

---
description: Brief description (required for /help and SlashCommand tool)
allowed-tools: Read, Grep, Glob, Bash(git:*)  # Optional restrictions
argument-hint: [file] [priority]              # Optional guidance
model: claude-3-5-haiku-20241022              # Optional model override
disable-model-invocation: false               # Optional, prevent auto-calling
---

ベストプラクティス

1. 必ず説明を含める

   • コマンドの目的をチームが理解しやすくなります
   • SlashCommand ツールで必須です
   • /helpに表示されます

2. わかりやすい argument-hint を使う

   • 想定される入力を示します
   • コマンドの自己文書化につながります
   • ユーザーの混乱を減らします

3. 適切な場合は allowed-tools を制限する

   • 読み取り専用コマンド：Read, Grep, Glob
   • Git のみ：Bash(git:*)
   • セキュリティと安全性が向上します

4. 複雑なコマンドは構造化する

   • セクション（Context、Task、Constraints）を使います
   • プロンプトが理解しやすくなります
   • 明確な流れに沿った構成になります

5. プロジェクトの規約を参照する

   • 規約として@CLAUDE.mdを含めます
   • 例となるファイルを参照します
   • 一貫性を保てます

6. 段階的にテストする

   • シンプルな状態から始め、機能を1つずつ追加します
   • 次に進む前に、追加した機能をテストします
   • 複数の機能を同時にデバッグしないでください

7. サブディレクトリで整理する

   • 関連するコマンドをまとめます
   • ファイル構成がすっきりします
   • メンテナンスが容易になります

8. プロジェクトのコマンドをコミットする

   • git 経由でチームと共有できます
   • コマンドをバージョン管理できます
   • チームもあなたの成果を活用できます

よくある問題と解決策

問題：コマンドが /help に表示されない

原因：

• ファイルの配置場所が正しくない
• .md 拡張子がない
• ファイル名に無効な文字が含まれている

解決策：

• ファイルが.claude/commands/または~/.claude/commands/にあることを確認します
• .md拡張子を確認します
• ファイル名には小文字とハイフンを使います

問題：引数が置き換えられない

原因：

• プレースホルダーのタイプミス（$ARGUMENTSではなく$ARGUMENT）
• 呼び出し時に引数を渡していない
• 構文が間違っている

解決策：

• 綴りを再確認します：$ARGUMENTS、$1、$2
• 次のようにテストします：/command arg1 arg2
• テンプレートにプレースホルダーがあることを確認します

問題：Bash コマンドが実行されない

原因：

• frontmatter にallowed-tools: Bash(...)がない
• 構文が間違っている（バッククォートがない）
• コマンドの実行時に失敗している

解決策：

• frontmatter に追加します：allowed-tools: Bash(command:*)
• 正しい構文を使います：[execute: command]
• まずターミナルでコマンドをテストします

問題：ファイル参照が機能しない

原因：

• @プレフィックスがない
• ファイルが存在しない
• パスが間違っている

解決策：

• @path/to/fileの構文を使います
• ファイルが存在することを確認します：ls path/to/file
• 相対パスで失敗する場合は、絶対パスを試します

スラッシュコマンドとスキルの比較

使い分け：

スラッシュコマンドを使う場合	スキルを使う場合
手動で呼び出す（いつ使うかを自分で決める）	自動的に見つける（いつ使うかをClaudeが判断する）
シンプルなプロンプトテンプレート	複雑な複数ファイルのワークフロー
すばやく実行できる、対象を絞った操作	幅広い機能
単一の.mdファイル	複数のファイルを含むディレクトリ

例：

• スラッシュコマンド：/commit - コミットする準備ができたら自分で呼び出します
• スキル：skill-builder - Skills に言及すると、Claude が見つけます

どちらもワークフローを補完し合います。

完全な構文リファレンス

構文の詳細については、reference/syntax-guide.md を参照してください。

ベストプラクティスとパターンについては、reference/best-practices.md を参照してください。

トラブルシューティングについては、reference/troubleshooting.md を参照してください。

効果的なコマンドを作成するためのヒント

1. まずは動作する最もシンプルなバージョンから始めます
2. 必要な場合にのみ複雑さを加えます（YAGNI 原則）
3. 共有する前に実際のシナリオでテストします
4. frontmatter に明確な説明を含めます
5. 安全性を確保するためにツールの制限を使用します
6. file refs を使ってプロジェクトの規約を参照します
7. bash の実行でコンテキストを収集します
8. 明確なセクションでプロンプトを構成します
9. argument-hint に例を記載します
10. 使用状況に基づいて反復し、時間をかけて改善します

次のステップ

コマンドを作成した後は、次の手順に従います。

1. さまざまな入力で十分にテストします
2. （プロジェクトコマンドの場合）チームと共有します
3. ほかの人が知っておくべきパターンであれば、CLAUDE.md に記載します
4. 関連するワークフロー用に関連コマンドを作成します
5. フィードバックに基づいて調整します。コマンドは使うほど改善されます

---

覚えておいてください：スラッシュコマンドは、ユーザーが呼び出すプロンプトテンプレートです。シンプルに始め、頻繁にテストし、機能を段階的に追加しましょう。優れたコマンドは、明確で焦点が絞られており、実際のワークフローの問題を解決します。