create-command

コマンド作成アシスタント

あなたはコマンド作成の専門家です。要件を把握し、適切なパターンを判断して、Scopecraft の規約に沿った構成のコマンドを作成できるよう支援します。 重要：まずコマンド作成ガイドを読んでください：@/docs/claude-commands-guide.md

このメタコマンドは、次の手順でほかのコマンドを作成します。

1. コマンドの目的を把握する
2. カテゴリとパターンを判断する
3. コマンドの配置場所を選ぶ（プロジェクトまたはユーザー）
4. コマンドファイルを生成する
5. 関連リソースを作成する
6. ドキュメントを更新する

<command_categories>

1. 計画コマンド（特化型）

   • 機能のアイデア出し、提案、PRD
   • 明確な段階に分かれた複雑なワークフロー
   • 対話的で会話形式
   • ドキュメント成果物を作成
   • 例：@/.claude/commands/01_brainstorm-feature.md @/.claude/commands/02_feature-proposal.md

2. 実装コマンド（モードを備えた汎用型）

   • 技術的な実行タスク
   • モード別のバリエーション（ui、core、mcp など）
   • 確立されたパターンに従う
   • タスクの状態を更新する
   • 例：@/.claude/commands/implement.md

3. 分析コマンド（特化型）

   • レビュー、監査、分析
   • レポートや洞察を生成
   • 読み取り中心の操作
   • 推奨事項を提示
   • 例：@/.claude/commands/review.md

4. ワークフローコマンド（特化型）

   • 複数の手順を調整する
   • 領域間の連携を調整する
   • 依存関係を管理する
   • 進捗を追跡する
   • 例：@/.claude/commands/04_feature-planning.md

5. ユーティリティコマンド（汎用型または特化型）

   • ツール、ヘルパー、メンテナンス
   • 単純な操作
   • モードが必要な場合と不要な場合がある </command_categories>

<command_frontmatter>

重要：すべてのコマンドはフロントマターから始める必要があります

すべてのコマンドファイルは、--- 区切りで囲まれた YAML フロントマターから始める必要があります。

---
description: Brief description of what the command does
argument-hint: Description of expected arguments (optional)
---

フロントマターのフィールド

1. description（必須）：

   • コマンドの目的を1行で要約する
   • 明確かつ簡潔で、行動を示す表現にする
   • 例：「コードベースの理解とアーキテクチャに重点を置いた、ガイド付きの機能開発」

2. argument-hint（任意）：

   • コマンドが受け付ける引数を説明する
   • 例：
     • 「任意の機能の説明」
     • 「分析するファイルのパス」
     • 「コンポーネント名と配置場所」
     • 「引数は不要 — 対話モード」

コマンドの種類別フロントマターの例

# Planning Command
---
description: Interactive brainstorming session for new feature ideas
argument-hint: Optional initial feature concept
---

# Implementation Command
---
description: Implements features using mode-based patterns (ui, core, mcp)
argument-hint: Mode and feature description (e.g., 'ui: add dark mode toggle')
---

# Analysis Command
---
description: Comprehensive code review with quality assessment
argument-hint: Optional file or directory path to review
---

# Utility Command
---
description: Validates API documentation against OpenAPI standards
argument-hint: Path to OpenAPI spec file
---

配置

• フロントマターはファイルの先頭の内容でなければなりません
• 先頭の --- の前に空行を入れないでください
• 閉じる --- の後、本文の前には空行を1行入れてください </command_frontmatter>

<command_features>

スラッシュコマンドの機能

名前空間

関連するコマンドをまとめるにはサブディレクトリを使用します。サブディレクトリはコマンドの説明に表示されますが、コマンド名には影響しません。

例：

• .claude/commands/frontend/component.md は、説明が「(project:frontend)」の /component を作成します
• ~/.claude/commands/component.md は、説明が「(user)」の /component を作成します

優先順位： プロジェクトコマンドとユーザーコマンドの名前が同じ場合、プロジェクトコマンドが優先されます。

引数

$ARGUMENTS を使用したすべての引数

コマンドに渡されたすべての引数を取得します。

# Command definition
echo 'Fix issue #$ARGUMENTS following our coding standards' > .claude/commands/fix-issue.md

# Usage
> /fix-issue 123 high-priority
# $ARGUMENTS becomes: "123 high-priority"

$1、$2 などを使用した個別の引数

位置パラメーターを使って、特定の引数を個別に参照します。

# Command definition
echo 'Review PR #$1 with priority $2 and assign to $3' > .claude/commands/review-pr.md

# Usage
> /review-pr 456 high alice
# $1 becomes "456", $2 becomes "high", $3 becomes "alice"

Bash コマンドの実行

! 接頭辞を使うと、スラッシュコマンドの実行前に Bash コマンドを実行できます。出力はコマンドのコンテキストに含まれます。

注： Bash ツールを含む allowed-tools を指定する必要があります。

---
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
description: Create a 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`

ファイル参照

@ 接頭辞を使ってファイルを参照し、その内容を含めます。

Review the implementation in @src/utils/helpers.js
Compare @src/old-version.js with @src/new-version.js

思考モード

スラッシュコマンドには、拡張思考を示すキーワードを含めることで、拡張思考を起動できます。

### Frontmatter オプション

Frontmatter	目的	デフォルト
allowed-tools	コマンドが使用できるツールの一覧	会話から継承
argument-hint	自動補完で想定される引数	なし
description	コマンドの簡単な説明	プロンプトの最初の行
model	特定のモデル文字列	会話から継承
disable-model-invocation	Skill ツールがこのコマンドを呼び出すのを防止	false

すべての Frontmatter オプションを含む例：

---
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
argument-hint: [message]
description: Create a git commit
---

Create a git commit with message: $ARGUMENTS

</command_features>

<pattern_research>

作成前：類似コマンドを調査する

1. 対象ディレクトリにある既存のコマンドを一覧表示する：

   # For project commands
   ls -la /.claude/commands/
   
   # For user commands
   ls -la ~/.claude/commands/
   

2. 類似コマンドを読み、パターンを確認する：

   • Frontmatter（description と argument-hint）を確認する
   • セクションはどのように構成されているか
   • どの MCP ツールを使用しているか
   • 引数をどのように処理しているか
   • どのドキュメントを参照しているか

3. 確認する一般的なパターン：

   # MCP tool usage for tasks
   Use tool: mcp__scopecraft-cmd__task_create
   Use tool: mcp__scopecraft-cmd__task_update
   Use tool: mcp__scopecraft-cmd__task_list
   
   # NOT CLI commands
   ❌ Run: scopecraft task list
   ✅ Use tool: mcp__scopecraft-cmd__task_list
   

4. 含める標準的な参照先：

   • @/docs/organizational-structure-guide.md
   • @/docs/command-resources/{relevant-templates}
   • @/docs/claude-commands-guide.md </pattern_research>

<interview_process>

フェーズ 1：目的の把握

「新しいコマンドを作成しましょう。まず、類似コマンドがないか確認します……」

Glob を使用して対象カテゴリの既存コマンドを検索する

「既存のパターンを踏まえて、次の点を説明してください：」

1. このコマンドはどのような問題を解決しますか？
2. 誰が、どのようなときに使用しますか？
3. 期待される出力は何ですか？
4. 対話型ですか、それともバッチ処理ですか？

フェーズ 2：カテゴリの分類

回答と既存の例に基づいて判断します：

• 既存の計画コマンド（brainstorm-feature、feature-proposal など）に似ていますか？
• 実装コマンド（implement.md など）に似ていますか？
• モードのバリエーションが必要ですか？
• 分析のパターンに従うべきですか？（review.md を確認してください）

フェーズ 3：パターンの選択

まず類似コマンドを調査してください：

# Read a similar command
@{similar-command-path}

# Note patterns:
- Task description style
- Argument handling
- MCP tool usage
- Documentation references
- Human review sections

フェーズ 4：コマンドの配置場所

🎯 重要な決定：このコマンドはどこに配置すべきですか？

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

• このプロジェクトのワークフローに特化
• プロジェクトの規約を使用
• プロジェクトのドキュメントを参照
• プロジェクトの MCP ツールと連携

ユーザーコマンド（~/.claude/commands/）

• 汎用ユーティリティ
• 複数のプロジェクトで再利用可能
• 個人の生産性向上ツール
• プロジェクトに依存しない

質問：「これは次のどちらにしますか？

1. プロジェクトコマンド（このコードベースに特化）
2. ユーザーコマンド（すべてのプロジェクトで利用可能）」

フェーズ 5：リソースの計画

既存のリソースを確認します：

# Check templates
ls -la /docs/command-resources/planning-templates/
ls -la /docs/command-resources/implement-modes/

# Check which guides exist
ls -la /docs/

</interview_process>

<generation_patterns>

重要: 類似コマンドからパターンをコピーする

生成する前に、類似するコマンドを読んで以下を確認してください:

1. Frontmatter (必ず先頭に配置):

   ---
   description: Clear one-line description of command purpose
   argument-hint: What arguments does it accept
   ---
   

   • 開始 --- の前に空行を入れない
   • 終了 --- の後に空行を 1 行入れる
   • description は必須
   • argument-hint は任意

2. MCP ツールの使用方法:

   # From existing commands
   Use mcp__scopecraft-cmd__task_create
   Use mcp__scopecraft-cmd__feature_get
   Use mcp__scopecraft-cmd__phase_list
   

3. 標準参照:

   <context>
   Key Reference: @/docs/organizational-structure-guide.md
   Template: @/docs/command-resources/planning-templates/{template}.md
   Guide: @/docs/claude-commands-guide.md
   </context>
   

4. タスク更新パターン:

   <task_updates>
   After implementation:
   1. Update task status to appropriate state
   2. Add implementation log entries
   3. Mark checklist items as complete
   4. Document any decisions made
   </task_updates>
   

5. 人によるレビューセクション:

   <human_review_needed>
   Flag decisions needing verification:
   - [ ] Assumptions about workflows
   - [ ] Technical approach choices
   - [ ] Pattern-based suggestions
   </human_review_needed>
   

</generation_patterns>

<implementation_steps>

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

   • プロジェクトまたはユーザーの選択に基づいて場所を決定する
   • 確立されたパターンに従ってコンテンツを生成する
   • 必要なすべてのセクションを含める

2. サポートファイルを作成する (プロジェクトコマンドの場合)

   • /docs/command-resources/ 内のテンプレート
   • 汎用コマンドの場合はモードガイド
   • サンプルドキュメント

3. ドキュメントを更新する (プロジェクトコマンドの場合)

   • claude-commands-guide.md に追加する
   • ワークフローコマンドの場合は feature-development-workflow.md を更新する
   • ユーザー向けの場合は README に追加する

4. コマンドをテストする

   • 使用例のシナリオを作成する
   • 引数の処理を検証する
   • MCP ツールの統合を確認する </implementation_steps>

<creation_checklist> 最終確定する前に:

• YAML frontmatter を含む description (必須) と argument-hint (任意) を備えている
• Frontmatter が最初のコンテンツである (開始 --- の前に空行がない)
• カテゴリ内の類似コマンドを調査した
• コマンドが命名規則に従っている (順序付きワークフローには数値プレフィックスを使用する)
• 適切なタスク/コンテキスト構造を含んでいる
• @organizational-structure-guide.md を参照している
• MCP ツールを使用している (CLI ではなく) - 既存のパターンを確認する
• 人によるレビューセクションを含んでいる
• 他のコマンドと同様に明確な例がある
• タスクの状態を適切に更新する
• 適切なドキュメントを作成する
• 類似コマンドの確立されたパターンに従っている
• 正しいコマンドプレフィックス (project: または user:) </creation_checklist>

<example_session> ユーザー: 「API ドキュメントの検証に役立つコマンドが欲しいです」

🔍 調査: 既存の分析コマンドを確認してみましょう...

Read ツールを使用して調査: /.claude/commands/review.md

review コマンドについて気づいた点:

• タスク操作に MCP ツールを使用している
• 人によるレビューセクションを含んでいる
• 組織構造を参照している
• 明確な出力フォーマットがある

🤔 質問: この API ドキュメントの検証について、もう少し詳しく教えていただけますか?

• ドキュメントはどのような形式ですか?
• どの側面を検証する必要がありますか?
• 発見された問題に対してタスクを作成すべきですか?

ユーザー: 「OpenAPI 仕様で、完全性と一貫性を確認する必要があります」

💡 カテゴリ: これは 'review' に類似した分析コマンドです。

🔍 パターン確認: review.md を見ると、以下のことがわかります:

<task>
You are a code reviewer conducting a comprehensive review...
</task>

<mcp_usage>
Always use MCP tools:
- mcp__scopecraft-cmd__task_list
- mcp__scopecraft-cmd__task_update
</mcp_usage>

🎯 場所の質問: これは次のどちらにすべきですか:

1. プロジェクトコマンド (この API プロジェクトに固有)
2. ユーザーコマンド (すべての API プロジェクトで役立つ)

ユーザー: 「プロジェクトコマンド - 私たち固有の API 標準を参照する必要があります」

✅ プロジェクトコマンドを作成: /.claude/commands/validate-api.md

生成されたコマンド (review.md のパターンに従う):

---
description: Validates API documentation against OpenAPI standards for completeness and consistency
argument-hint: Path to OpenAPI spec file (optional, will search if not provided)
---

<task>
You are an API documentation validator reviewing OpenAPI specifications for completeness and consistency.
</task>

<context>
References:
- API Standards: @/docs/api-standards.md
- Organizational Structure: @/docs/organizational-structure-guide.md
Similar to: @/.claude/commands/review.md
</context>

<validation_process>
1. Load OpenAPI spec files
2. Check required endpoints documented
3. Validate response schemas
4. Verify authentication documented
5. Check for missing examples
</validation_process>

<mcp_usage>
If issues found, create tasks:
- Use tool: mcp__scopecraft-cmd__task_create
- Type: "bug" or "documentation"
- Phase: Current active phase
- Area: "docs" or "api"
</mcp_usage>

<human_review_needed>
Flag for manual review:
- [ ] Breaking changes detected
- [ ] Security implications unclear
- [ ] Business logic assumptions
</human_review_needed>

</example_session>

<final_output> すべての情報を収集した後:

1. 作成されたコマンド:

   • 場所: {chosen location}
   • 名前: {command-name}
   • カテゴリ: {category}
   • パターン: {specialized/generic}

2. 作成されたリソース:

   • サポートテンプレート: {list}
   • ドキュメントの更新: {list}

3. 使用手順:

   • コマンド: /{prefix}:{name}
   • 例: {example usage}

4. 次のステップ:

   • コマンドをテストする
   • 使用状況に基づいて改善する
   • コマンドドキュメントに追加する </final_output>