command-creator

コマンドクリエーター

OpenCode で、繰り返し行うタスク用のカスタムスラッシュコマンドを作成します。

<core_approach>

コマンドの作成は、取引ではなく対話を通じて行います。

• ユーザーの希望を決めつけてはいけません。質問してください
• シンプルに始め、必要な場合にのみ複雑さを加えてください
• 下書きを提示し、フィードバックに基づいて反復してください

</core_approach>

<question_tool>

まとめて質問する場合： 関連する質問が2つ以上ある場合は、question ツールを使用します。質問が1つだけの場合は、通常のテキストを使用します。

構文： header は12文字以内、label は1～5語にします。デフォルトには「(Recommended)」を追加します。

質問するタイミング：依頼が曖昧な場合（「コマンドを作って」など）、または複数の実装方法がある場合。

</question_tool>

コマンドの保存場所

スコープ	パス
プロジェクト	.opencode/command/<name>.md
グローバル	~/.config/opencode/command/<name>.md

テンプレートのプレースホルダー（重要）

• 挿入は1回のみ： 各プレースホルダー（$ARGUMENTS、$1、@filename など）は、コマンド本文内に1回だけ挿入してください。
• 専用ブロック： ユーザー入力とファイル内容には専用の XML ブロックを使用し、目的と指示を明確に保ってください。
• 推奨： 厳密に必要な場合を除き、複雑な位置引数ではなく、単一の引数（$ARGUMENTS）を使用してください。

悪い例：「$ARGUMENTS を実行し、その後、$ARGUMENTS にエラーがないか確認する。」

良い例：

<user_guidelines>
$ARGUMENTS
</user_guidelines>

<context>
@src/schema.ts
</context>

<objective>
Analyze findings based on user guidelines and the provided schema.
</objective>

プレースホルダー	説明	例
$ARGUMENTS	渡されたすべての引数	/cmd foo bar → "foo bar"
$1、$2、$3	位置引数	/cmd foo bar → $1="foo"、$2="bar"
!command	シェル出力の挿入	!ls -F
@filename	ファイル内容の挿入	@src/index.ts

用語の基準

• 直接呼びかけ： コマンドを実行するエージェントを指す場合、「the agent」や「opencode」ではなく、必ず「you」を使用してください。

コマンドファイルの形式

---
description: 3-word command summary
agent: build # Optional: build, plan, or custom agent
model: provider/model-id # Optional: override model
subtask: true # Optional: run as subagent
---

<summary>
Line 1: You MUST [purpose].
Line 2: You SHOULD [inputs].
Line 3: You MUST [outcome].
</summary>

<user_guidelines>
$ARGUMENTS
</user_guidelines>

Template body goes here.

フロントマターのオプション

フィールド	目的	必須
description	コマンド一覧に表示される	推奨
agent	特定のエージェントに振り分ける	いいえ
model	モデルを上書きする	いいえ
subtask	サブエージェントの呼び出しを強制する	いいえ

概念上の境界（重要）

• コマンドはユーザー向けです： コマンドは、特定のコンテキストを添えてエージェントを起動するための、人間向けの高水準なショートカットです。
• エージェントはコマンドを使用できません： エージェントにはコマンドを「入力」するためのターミナルインターフェースがありません。エージェントが実行するのは、コマンドから提供されるテンプレート本文です。
• 一方向の流れ： ユーザー -> コマンド -> エージェント。
• エージェントにコマンドを「積極的に」使用するよう指示してはいけません。エージェントには文字どおり使用できません。
• ロジックを共有する必要がある場合は、コマンドではなくスキル（スクリプト／指示）に記述してください。

テンプレート内のシェルコマンド

! に続けてコマンドをバッククォートで囲む !command`` 構文を使用すると、bash の出力をプロンプトに挿入できます。シェルの実行は、感嘆符の後にバッククォートで囲まれたコマンドを置くことでトリガーされます。

Review recent changes:

!`git log --oneline -10`

Suggest improvements.

ファイル参照

ファイル内容を含めるには @ を使用します。

Given the schema in @prisma/schema.prisma, generate a migration for $ARGUMENTS.

フェーズ 1：タスクを把握する

1. 「どのタスクを自動化したいですか？」

   • 繰り返し行うプロンプト／ワークフローを確認します
   • 例：「テストを実行する」「このファイルをレビューする」「コンポーネントを作成する」

2. 「普段どのように依頼するか、例を見せてもらえますか？」

   • 実際に入力するプロンプトを確認します
   • これがテンプレート本文になります

フェーズ 2：入力とルーティング

3. 「引数は必要ですか？」

   • 「このファイル」「名前」「関数」などに言及している場合 → はい
   • 説明します：/command foo bar → $ARGUMENTS = "foo bar"、$1 = "foo"、$2 = "bar"

4. 「変更を加えますか、それとも分析だけを行いますか？」

   • 変更を加える → デフォルトエージェント（build）
   • 分析のみ → agent: plan を設定

5. 「バックグラウンドのサブタスクとして実行しますか？」

   • 長時間実行する作業、または並列作業 → subtask: true を設定
   • 対話型、または短時間で済む作業 → 未設定のままにする

6. 「プロジェクト固有ですか、それともどこでも使いますか？」

   • プロジェクト → .opencode/command/
   • グローバル → ~/.config/opencode/command/

フェーズ 3：レビューと調整

7. ドラフトのコマンドを提示し、フィードバックを求める
   • 「作成したものはこちらです。調整したい点はありますか？」
   • ユーザーが満足するまで繰り返す

柔軟に対応してください： ユーザーが最初に多くの情報を提供した場合は、それに合わせて対応します。すべての質問を厳密に尋ねてはなりません。

/test - テストの実行と修正

---
description: Run tests and fix failures
---

<summary>
You MUST run the full test suite.
You SHOULD identify and fix failures.
You MUST re-verify fixes.
</summary>

<objective>
You MUST run the full test suite, find the root cause of any failures, and fix the issue.
</objective>

1. Show the failing test
2. Identify the root cause
3. Fix the issue
4. Re-run to verify

/review - コードレビュー（読み取り専用）

---
description: Review code for issues
agent: plan
---

<summary>
You MUST review $ARGUMENTS for issues.
You SHOULD check for bugs, security, and performance.
You MUST provide actionable feedback.
</summary>

<objective>
You MUST review $ARGUMENTS for bugs, security, and performance issues and provide actionable feedback without making changes.
</objective>

- Bugs and edge cases
- Security issues
- Performance problems

/commit - プレフィックス付きのスマートコミット

---
description: Stage and commit with conventional prefix
---

<summary>
You MUST analyze changes and stage files.
You SHOULD choose a conventional commit prefix.
You MUST commit with a concise message.
</summary>

<context>
!`git status`
!`git diff`
</context>

<objective>
You MUST analyze changes, stage relevant files, and commit with a concise message.
</objective>

1. Analyze all changes
2. Choose appropriate prefix: docs:, feat:, fix:, refactor:, test:, ci:
3. Write concise commit message (imperative mood)
4. Stage relevant files and commit

/spellcheck - スペルチェック

---
description: Check spelling in markdown files
subtask: true
---

<summary>
You MUST find unstaged markdown files.
You SHOULD check them for spelling errors.
You MUST report any found errors.
</summary>

Check spelling in all unstaged markdown files:

<context>
!`git diff --name-only | grep -E '\.md$'`
</context>

<objective>
You MUST check for and report any spelling errors found in unstaged markdown files.
</objective>

/issues - GitHub Issue の検索

---
description: Search GitHub issues
model: anthropic/claude-3-5-haiku-20241022
subtask: true
---

<summary>
You MUST search GitHub issues for $ARGUMENTS.
You SHOULD limit results to the top 10.
You MUST summarize the relevant issues.
</summary>

Search GitHub issues matching: $ARGUMENTS

<context>
!`gh issue list --search "$ARGUMENTS" --limit 10`
</context>

<objective>
You MUST summarize the top 10 relevant GitHub issues found for $ARGUMENTS.
</objective>

/component - コンポーネントの作成

---
description: Create a new React component
---

<summary>
You MUST create a React component named $1.
You SHOULD include TypeScript props and basic styling.
You MUST provide a unit test file.
</summary>

Create a React component named $1 in $2 with:

<objective>
You MUST create a React component with TypeScript props and basic styling, and provide a corresponding unit test file.
</objective>

- TypeScript props interface
- Basic styling
- Unit test file

使用方法：/component UserProfile src/components

/migrate - データベースのマイグレーション

---
description: Generate database migration
---

<summary>
You MUST read the Prisma schema.
You SHOULD generate a migration for $ARGUMENTS.
You MUST ensure the migration matches the schema.
</summary>

Given the schema in @prisma/schema.prisma:

<context>
@prisma/schema.prisma
</context>

<objective>
You MUST generate a Prisma migration for $ARGUMENTS that matches the provided schema.
</objective>

<quality_checklist>

提供する前に確認してください：

• 自動化するタスクを尋ねた
• 通常どのようにプロンプトを入力するか、例を確認した
• 引数が必要かどうかを判断した（$ARGUMENTS と $1、$2）
• 適切なエージェントを設定した（読み取り専用の場合は plan）
• 長時間実行する作業にサブタスクを検討した
• プロジェクト単位かグローバルかを選択した
• ドラフトを提示し、フィードバックを得た

</quality_checklist>

<best_practices>

すべきこと	避けること
テンプレートの焦点を絞る	1 つに複数のタスクを詰め込む
構造化された引数には $1、$2 を使う	複数の引数に $ARGUMENTS だけを使う
コンテキストの収集には !cmd を使う	動的な値をハードコードする
設定やスキーマの参照には @file を使う	ファイルの内容をコピー＆ペーストする
読み取り専用の場合は agent: plan を設定する	レビュー時にエージェントの設定を忘れる
並列作業では subtask: true を設定する	不必要にメインセッションをブロックする

</best_practices>