このプロンプトは Node.js 製 CLI 以外 (Python / Go / Rust) でも使えますか?

10 セクション (コマンド名・引数表・設定ファイル・環境変数・ログ・エラー規約など) は言語非依存の概念なので、Python の Click / Typer や Go の cobra、Rust の clap でも同じフレームで仕様書化できます。設定ファイル形式や外部バイナリ依存の章だけ、各言語のエコシステムに合わせて読み替えてください。

アイデアが 1 行しか無くて、想定ユーザーやスペックがまだ固まっていません

アイデア欄に 1-3 行だけ書き、想定ユーザー欄に「未定」と明記して投げて構いません。AI が「想定ユーザーの候補を 3 つ挙げてください」と聞き返してくる構成になりがちですが、その候補から選ぶ流れで仕様が固まります。逆に全項目を埋めてから投げると、AI の発散余地が消えて画一的な仕様書になりやすいので注意です。

AI が v1 必須機能と将来機能を混ぜて出してきます

制約セクションに「『将来欲しい機能』と『v1 で必須』を分けて書く」と明記しているのに混ざる場合は、「v1 必須機能と将来機能をテーブル分けで再出力してください」と返すと修正されます。それでも混ざる場合は、AI が v1 のスコープを大きく見積もりすぎている合図なので「v1 は 2 週間で実装可能な範囲に絞ってください」と工数制約を追加すると分離します。

出来上がった仕様書をそのまま実装プロンプトに渡してもいいですか?

仕様書 → 実装プロンプトへの直接連結は可能ですが、間に「仕様書のうち未確定箇所を列挙して」というステップを 1 つ挟むと、実装時の手戻りが減ります。特に設定ファイルの上書き優先度と終了コード規約は実装前に決まっていないと、後から大規模変更が必要になりやすい箇所です。

コーディング 2026-05-18 更新

CLI ツール仕様書を Claude に書かせるプロンプト

いつ使うか

個人開発の小さな CLI を作りたいが、いきなりコードを書くと引数体系や設定ファイル仕様が後から崩れる。先に仕様書を AI に作らせて、それをそのまま実装フェーズへの input にしたい時に使う。

プロンプト本文 (コピペして使う)

あなたは熟練の CLI 設計者です。以下のアイデアを実装可能な仕様書に落とし込んでください。

## アイデア (1-3行)
<例: ローカルの動画ファイルを一括で 1080p に正規化する CLI>

## 想定ユーザー
<例: 自分一人、Windows + macOS で動かす>

## 期待する仕様書セクション
1. **コマンド名** (kebab-case、npm スコープ含む)
2. **サブコマンド** (なければ単一コマンドで OK、それぞれの用途を1行)
3. **引数 / フラグ表**
   - 名前 / 短縮形 / 必須/任意 / デフォルト / 型 / 説明 (テーブル形式)
4. **入出力**
   - 入力ソース (stdin / ファイル / glob)
   - 出力先 (stdout / ファイル / ディレクトリ)
   - 終了コード規約 (0=成功、1=想定エラー、2=引数エラー…)
5. **設定ファイル**
   - パス検索順序 (例: ./.foorc → ~/.config/foo/config.toml)
   - フォーマット (TOML/JSON/YAML どれか + 理由)
   - 上書き優先度 (CLI 引数 > env > config file > default)
6. **環境変数**
7. **ログ出力**
   - レベル (--verbose / --quiet)
   - 構造化ログオプション (--json)
8. **エラーメッセージ規約** (1行サマリ + ヒント形式)
9. **依存ツール** (ffmpeg 等の外部バイナリ)
10. **テスト戦略** (snapshot/e2e の方針)

## 制約
- POSIX 系の慣例に従う (--help / --version は必須)
- グローバルフラグと subcommand 固有フラグを混ぜない
- 「将来欲しい機能」と「v1 で必須」を分けて書く

効くポイント

10セクションを固定すると、後から「あ、これ決めてなかった」が激減する
上書き優先度を最初に決めておくと、運用フェーズの混乱を防げる
v1 必須 / 将来を分けさせると、MVP がブレない

よくある質問

このプロンプトは Node.js 製 CLI 以外 (Python / Go / Rust) でも使えますか?: 10 セクション (コマンド名・引数表・設定ファイル・環境変数・ログ・エラー規約など) は言語非依存の概念なので、Python の Click / Typer や Go の cobra、Rust の clap でも同じフレームで仕様書化できます。設定ファイル形式や外部バイナリ依存の章だけ、各言語のエコシステムに合わせて読み替えてください。
アイデアが 1 行しか無くて、想定ユーザーやスペックがまだ固まっていません: アイデア欄に 1-3 行だけ書き、想定ユーザー欄に「未定」と明記して投げて構いません。AI が「想定ユーザーの候補を 3 つ挙げてください」と聞き返してくる構成になりがちですが、その候補から選ぶ流れで仕様が固まります。逆に全項目を埋めてから投げると、AI の発散余地が消えて画一的な仕様書になりやすいので注意です。
AI が v1 必須機能と将来機能を混ぜて出してきます: 制約セクションに「『将来欲しい機能』と『v1 で必須』を分けて書く」と明記しているのに混ざる場合は、「v1 必須機能と将来機能をテーブル分けで再出力してください」と返すと修正されます。それでも混ざる場合は、AI が v1 のスコープを大きく見積もりすぎている合図なので「v1 は 2 週間で実装可能な範囲に絞ってください」と工数制約を追加すると分離します。
出来上がった仕様書をそのまま実装プロンプトに渡してもいいですか?: 仕様書 → 実装プロンプトへの直接連結は可能ですが、間に「仕様書のうち未確定箇所を列挙して」というステップを 1 つ挟むと、実装時の手戻りが減ります。特に設定ファイルの上書き優先度と終了コード規約は実装前に決まっていないと、後から大規模変更が必要になりやすい箇所です。