command-creator

command-creatorスキルの概要

command-creatorスキルは、Claude Codeで何度も繰り返している作業フローを、毎回同じ説明をし直す代わりに再利用できるスラッシュコマンドへ落とし込みたい人向けのスキルです。単にmarkdownファイルを下書きするだけではなく、適切なコマンドパターンの選定、エージェントが実行しやすい書き方への整理、そしてプロジェクト単位・ユーザー単位のどちらで再利用するかに応じた配置先の判断まで支援します。

command-creatorが向いている人

command-creatorは、CI修正、PR提出、実装計画、レビュー手順といった、すでに繰り返しているワークフローを把握していて、それを/command-nameで呼び出せるようにしたい開発者、チームリード、Skill Authoringユーザーに特に向いています。

本当に解決したい仕事は何か

多くのユーザーが必要としているのは「コマンド用ファイル」そのものではありません。必要なのは、別のエージェントが曖昧さを減らし、追加質問を少なくし、より一貫した出力で実行できるコマンドです。command-creator skillが有用なのは、ふわっとしたプロンプト作成ではなく、コマンド構造、実行の明確さ、再利用しやすいワークフロー設計に焦点を当てているからです。

通常のプロンプトと何が違うのか

普通のプロンプトでも、ざっくりしたスラッシュコマンド案を素早く作ることはできます。ただしcommand-creatorは、次のようなより価値の高い観点までガイドしてくれます。

• ワークフローパターンの選び方
• 命令形で、ツールが扱いやすい指示の書き方
• 引数と期待する出力の定義
• コマンドを.claude/commands/と~/.claude/commands/のどちらに置くべきかの判断
• 自律実行を損なう、よくあるコマンド記述ミスの回避

command-creatorが強くハマる場面

次のように感じているなら、command-creatorはかなり相性が良いです。

• 「この作業を毎回やっているから、スラッシュコマンドにしたい」
• 「このワークフローを/somethingにしてほしい」
• 「この複数ステップの手順を、Claude Codeが安定して実行できるように文書化したい」
• 「このrepo専用のプロジェクト向けコマンドを作りたい」
• 「複数プロジェクトで使い回せるグローバルコマンドを作りたい」

向いていないケース

一度きりの回答だけ欲しい場合、再利用を前提としない単純なプロンプトで十分な場合、あるいはmarkdownのコマンド定義よりも外部スクリプトに依存する自動化が主役の場合は、command-creatorは優先度が下がります。このスキルが最も力を発揮するのは、分析・実行・報告の流れを、繰り返し可能な手順として明確に表現できるワークフローです。

command-creatorスキルの使い方

command-creatorのインストール前提

リポジトリはsoftaworks/agent-toolkitで、該当スキルはskills/command-creatorにあります。このtoolkitからスキルを入れる一般的な方法は次のとおりです。

npx skills add softaworks/agent-toolkit --skill command-creator

利用している環境で別のスキルローダーを使っている場合も、参照元としては上記のrepository pathを基準にしてください。

command-creatorが生成を助けるもの

出力されるのはClaude Codeのスラッシュコマンドです。保存先は次のいずれかのmarkdownファイルになります。

• .claude/commands/：プロジェクト専用コマンド
• ~/.claude/commands/：グローバルコマンド

このファイルは、後からClaude Code内で/command-nameとして呼び出します。

スキル利用前に先に読んでおきたいファイル

最短で良い結果にたどり着きたいなら、repositoryは次の順番で読むのがおすすめです。

1. SKILL.md：想定トリガーとスコープの確認
2. references/patterns.md：適切なコマンド形の選定
3. references/best-practices.md：書き方と構成のベストプラクティス確認
4. references/examples.md：すでに動いている完全なコマンド例の確認
5. README.md：必要なら全体像の把握

この順番には意味があります。導入時につまずく原因の多くはインストールではなく、誤ったパターン選択や、指示の曖昧さといった設計面の問題だからです。

コマンド名ではなくワークフローから始める

ベストなcommand-creator usageは、名前付けや見た目からではなく、繰り返している作業から始まります。スキルに依頼する前に、最低でも次の点を書き出しておくと効果的です。

• trigger：どんな問題や状況でワークフローが始まるか
• inputs：必要な引数、ファイル、repoの状態
• sequence：どの順番で何を行うか
• stop condition：どこまで進めば成功と見なすか
• report：最後にユーザーへ何を返すべきか

ここまで整理しておくと、スキル側も曖昧にでっち上げるのではなく、構造に合ったコマンドパターンを選べるようになります。

粗い依頼を強いプロンプトに変える

弱い入力:

• 「PR用のスラッシュコマンド作って」

より強い入力:

• 「このrepo向けにsubmit-stackというClaude Code slash commandを作ってください。最初に.PLAN.mdを確認し、なければgit diffにフォールバックし、簡潔なcommit messageを生成したうえで、Graphiteのrestackとsubmitコマンドを実行し、最後にPR URLを報告してください。これはproject-levelで、.claude/commands/に置き、任意のdescription引数を受け取るようにしてください。」

後者のほうが良い結果になりやすいのは、コンテキスト確認、フォールバック処理、ツール実行、保存先、引数まで具体的に指定されているからです。

早い段階で適切なコマンドパターンを選ぶ

reference群を見ると、下書きを始める前にパターンを決めたほうが、コマンド品質が上がることがわかります。代表的なパターンは次のとおりです。

• Analyze → Act → Report：複数ステップのワークフロー自動化向け
• Run → Parse → Fix → Repeat：CIやlintのような反復修正タスク向け
• コマンドが専門エージェントへ作業を振り分ける前提の委譲型フロー
• 分岐が少ない直接実行型のシンプルなパターン

実運用でコマンドがうまく機能しない場合、原因は文言の細かい言い回しではなく、パターン選択のミスマッチであることが少なくありません。

command-creatorではエージェントが実行できる形で書く

references/best-practices.mdの重要なポイントは、コマンドは二人称の助言ではなく、具体的な命令文で書くべきだということです。

望ましい例:

• “Run git status to inspect modified files.”
• “Check whether .PLAN.md exists in the repository root.”
• “Report PR URLs after submission.”

避けたい例:

• “You should inspect the repo.”
• “You may want to look at git status.”
• “Try to submit the PRs.”

これはcommand-creator guideの中でも特に影響が大きいポイントです。なぜなら、生成されたコマンドが自律的に実行可能かどうかに直結するからです。

期待する結果と分岐条件も書く

良いコマンドは、単に手順を並べるだけでは不十分です。何が起きるべきか、どこで分岐するかまで明示します。

追加しておくと有効な情報:

• 最初にどのファイルを確認するか
• そのファイルがない場合に何をするか
• 成功時の出力がどのようなものか
• どの時点で止めてユーザーに確認すべきか
• 最後に何を報告するか

これによって実行中の推測が減り、会話をまたいでも再利用しやすいコマンドになります。

プロジェクト単位かグローバルかを決める

command-creator for Skill Authoringでは、配置先の判断はかなり実務的です。

• ワークフローがrepoの慣習、repo固有ツール、プロジェクト内ファイルに依存するなら.claude/commands/を使う
• 複数のrepoで個人的に使い回せるなら~/.claude/commands/を使う

多くの実用的なワークフローはローカルな慣習に依存するため、迷ったらプロジェクト専用コマンドをデフォルトにするのが無難です。

引数は実際の変動要素に合わせて設計する

引数は、実行内容に意味のある差が出る場合だけ追加してください。候補として妥当なのは次のようなものです。

• ユーザーが渡す説明文
• 対象ファイルやpath
• quickとfullのような実行モード
• 環境やスコープの切り替え指定

「柔軟であるべきだから」という理由だけで引数を増やすのは避けたほうがよいです。任意引数が多すぎると、コマンドの信頼性が落ち、エージェントにとっても解釈しづらくなります。

初回利用時の実践的な流れ

実用的なcommand-creator installから利用までの流れは、たとえば次のようになります。

1. softaworks/agent-toolkitからスキルをインストールまたは読み込む
2. SKILL.mdとreferences/patterns.mdを読む
3. まずは繰り返しているワークフローを1つだけ選ぶ
4. 入力、分岐、期待出力を含めてそのワークフローを説明する
5. command-creatorにスラッシュコマンドの下書きを依頼する
6. 生成結果をreferences/best-practices.mdと照らし合わせる
7. Claude Codeで現実的なケースを使ってテストする
8. 曖昧な手順、前提条件の抜け、弱い報告部分を詰める

repository内で特に重要なシグナル

このスキルで価値が高いのは補助スクリプトよりreference群です。pattern、example、best practiceの文書が同梱されているのは重要で、コマンド作成はコード不足より設計の不明瞭さで失敗することのほうが多いからです。つまりこのスキルは、ツール主体の自動化よりも、再利用可能なmarkdownコマンドを設計したい人に特に向いています。

command-creatorスキル FAQ

すでにプロンプトが書けるなら、command-creatorを使う価値はある？

あります。目的が一度きりのプロンプトではなく、再利用可能なコマンド作成なら特に有効です。command-creatorは、コマンドパターン、命令形での記述、期待出力の定義といった、スラッシュコマンドに必要な構造を与えてくれます。結果として、その場しのぎで作ったプロンプトよりも、別のエージェントが安定して実行しやすいコマンドになりやすいです。

command-creatorは初心者にも使いやすい？

基本的には使いやすいです。ただし前提として、自動化したいワークフロー自体は自分で理解している必要があります。最初からスラッシュコマンドの作法をすべて知っている必要はありませんが、タスク、入力、成功条件を明確に説明できるほど、結果は大きく良くなります。

command-creatorがやってくれないことは？

曖昧な一文から、ぐちゃぐちゃなワークフローを魔法のように推測して整えてくれるわけではありません。プロセスの前提が隠れている、必要なツール名が抜けている、どこで止まればよいか不明確、といった問題があると、生成されるコマンドにもその欠落がそのまま残ります。

例のコマンドをコピーするのと何が違う？

exampleは参考になりますが、ワークフローに調整が必要な場合はcommand-creator usageのほうが強いです。同梱されているexampleは動作するパターンを示してくれますが、command-creatorは、そのパターンに自分の具体的なプロセスをどう当てはめるかを手助けしてくれます。単に1つのexampleをコピーして「たぶん合うだろう」と使うのとは違います。

単純な作業にもcommand-creatorを使うべき？

その作業を十分な頻度で繰り返すなら使う価値があります。小さな一回限りの処理なら、普通にプロンプトを書くほうが速いです。一方、チームやrepoで繰り返されるワークフローなら、command-creator skillの価値は大きくなります。

command-creatorはプロジェクト専用コマンドにも向いている？

はい。むしろそこが最も相性の良い用途の1つです。repository内のファイル、ローカルな慣習、一定のチェック手順と実行順序に依存するコマンドに特によく合います。

どんなときはcommand-creatorをインストールしないほうがいい？

本当に必要なのがClaude Codeのスラッシュコマンドではなく、外部自動化コード、shell script、CI設定であるなら、command-creator installを優先しないほうがよいです。このスキルが扱うのはコマンド定義の作成であって、あらゆる自動化レイヤーの代替ではありません。

command-creatorスキルを改善するには

command-creatorに渡す元情報の質を上げる

command-creatorの出力を最も手早く改善する方法は、ワークフローを構造化して渡すことです。

• goal
• trigger
• required tools
• file checks
• branching logic
• final deliverable

「リリース用のコマンド作って」のような曖昧な一文より、短い箇条書きでも構造化されているほうがはるかに有効です。

repository固有の文脈を見せる

コマンドがproject-levelなら、次のようなrepo固有情報を含めてください。

• コマンドが最初に読むべき重要ファイル
• make testやpnpm lintのような標準コマンド
• 命名規則
• commitやPRの運用ルール
• Graphite、pytest、独自scriptのような使用ツール

これにより、単なる汎用テンプレートではなく、そのrepoに合ったコマンドを生成しやすくなります。

失敗パターンを先に伝える

何がよく問題になるのかを、あらかじめcommand-creatorへ伝えておくと効果的です。

• 必要なcontext fileがない
• working treeがdirty
• テストが不安定
• ツール出力が部分的にしか返らない
• 続行せず停止すべきケースがある

こうした情報があると、分岐設計と安全な指示が改善されます。

前提条件と出力形式を明示的に求める

よくある失敗は、「何をするか」は書いてあっても、「成功とは何か」が書かれていないコマンドです。スキルには、次を含めるよう依頼するとよいです。

• preflight checks
• 各主要ステップ後の期待出力
• 最終報告フォーマット
• 安全に続行できないときのescalation point

これだけで、最初の試行から実行しやすいコマンドになりやすくなります。

初稿の曖昧な表現を締める

最初の結果にcheck、review、fixのような曖昧語が多いなら、具体的な動作に置き換えてください。

• どのcommandを実行するのか
• どのfileを読むのか
• どのconditionを確認するのか
• どのoutputを返すのか

これはcommand-creator for Skill Authoringを改善する最も有効な方法の1つです。スラッシュコマンドの性能が落ちる主因は、ほぼ曖昧さだからです。

同梱referenceを目的別に使い分ける

各referenceは、改善の観点ごとに使い分けるのが効果的です。

• references/patterns.md：全体構造の修正
• references/examples.md：現実的に動く例との比較
• references/best-practices.md：表現と実行詳細の磨き込み

SKILL.mdを何度も読み返すより、この使い分けのほうが実践的です。

静的に読むだけでなく、実際に呼び出して試す

markdown上ではよく見えるコマンドでも、実際に使うと失敗することがあります。現実的な引数とrepo状態で、実際に/command-nameとしてテストしてください。そのうえで次を直します。

• 不明瞭な前提
• file checkの不足
• 弱いfallback logic
• 不十分な報告
• 不要な任意性

複雑化する前に、まずスコープを絞る

最初のコマンドが脆いと感じるなら、機能追加より先に対象範囲を狭めてください。多数のエッジケースを処理しようとする「賢い」コマンドより、1つの明確なワークフローに絞った小さなコマンドのほうが、たいてい安定して動きます。基本ルートが固まってから、引数や分岐を意図的に足すべきです。

command-creatorは最終判断者ではなく設計支援として使う

command-creator skillの結果を良くする最善策は、初稿を完成品ではなく設計成果物として扱うことです。実際の仕事の流れに合っているかを確認し、そのうえでrepo、ツール、制約に合わせて編集してください。このスキルが最も役立つのは、判断そのものを代替するときではなく、推測の余地を減らすときです。