enhance-prompt

プロンプトの改善

LLM のプロンプトとエージェントへの指示を分析、作成、改善します。これらの原則を、システムプロンプト、エージェントへの指示、スキル、CLAUDE.md ファイル、ルール、スラッシュコマンド、あらゆる LLM プロンプトに適用します。

ワークフロー

入力がある状態で呼び出された場合：

1. リクエストを分類する：入力がレビュー対象のプロンプト、作成するプロンプトの説明、一般的なプロンプトエンジニアリングの質問のいずれかを判定します
2. 分析する：既存のプロンプトでは、以下の原則に違反している点を特定します。新規プロンプトでは、要件を収集します
3. 原則を適用する：トークン効率、決定性、命令形の言葉遣い、書式、アンチパターンのチェックを適用します
4. 出力を作成する：改善したプロンプトのみを返します

出力形式

改善したプロンプトのみを返します。前置き、違反点の指摘、コメント、説明は含めません。応答全体を、そのままコピーして貼り付けられる改善済みプロンプトにします。

入力なしで呼び出された場合は、以下の原則を参照ガイドとして提示します。

トークン効率

コンテキストウィンドウは共有リソースです。情報の一つひとつに、「モデルはすでにこの情報を知っているか」と問いかけてください。モデルが持たないコンテキストだけを追加します。高い基本能力を前提にしてください。

装飾的な表現を削除します。「お願いします」「覚えておいてください」「必ず〜してください」は使いません。

説明より例を使います。具体的な変更前／変更後の例を1つ示すほうが、説明を3段落書くより多くを伝えられます。

構造化データには表を優先します。関連情報をまとめ、ざっと確認できる形式にします。

決定性と具体性

自由度

タスクの要件に合わせて具体性を調整します。

自由度が高い（テキストの指示）：複数の方法が有効な場合に使います。自由度が中程度（擬似コード、パラメーター化されたスクリプト）：推奨されるパターンがある場合に使います。自由度が低い（パラメーターのない厳密なスクリプト）：操作に注意を要する場合や、一貫性が重要な場合に使います。

曖昧さをなくす

すべての指示が一つの解釈だけになるようにします。

提案ではなく、明確な制約を使います。「必要に応じて厳格なマーカーを使ってテストを実行する」ではなく、「pytest tests/ --strict-markers を実行する」とします。

条件を漏れなく指定します。「入力を検証する」ではなく、「API 境界で入力を検証する」とします。

「検討する」「試みる」「可能な場合」「一般的に」「多くの場合」といった曖昧な表現をなくします。

決定的なコマンド

すべてのフラグと引数を含めます。dotnet test ではなく、dotnet test --logger "console;verbosity=detailed" とします。

絶対パス、または対象範囲を正確に指定したパスを使います。「API コード」ではなく、/src/api/ や src/**/*.ts とします。

動作がバージョンによって異なる場合は、ツールのバージョンを指定します。「fetch を使う」ではなく、「Node.js 20 以降ではネイティブの fetch を使う」とします。

命令形の言葉遣い

命令形だけを使います。「境界で入力を検証する」ではなく、「境界で入力を検証します」とします。

直接的な指示には命令形を使います。

適切：「API 境界で入力を検証する」
避ける：「API 境界で入力を検証することを検討してください」

否定形より肯定形の指示を優先します。「例外を不必要に捕捉しない」ではなく、「例外をそのまま伝播させる」とします。

制約の具体性

禁止事項と要件を具体的にします。

適切：「バックグラウンドジョブに再試行ロジックを実装しない」
避ける：「防御的なパターンを避ける」

LLM の解析に適した書式

LLM の理解を助ける Markdown 構造を使います。

書式	用途
見出し	コンテキストと適用範囲の境界を明確にする
リスト	個別で、並列かつ独立した項目を示す
コードブロック	正確な値、コマンド、識別子、パターンを示す
表	構造化された比較、参照データ、判断基準を示す
太字	違反すると失敗につながる厳格な制約を示す（内容の最大 10%）
文章	考え方の関係、条件分岐、根拠を示す
空白	解析しやすいよう、段落やセクションの間に空行を入れる

強調表現と用語

強調の修飾語

違反すると失敗につながる厳格な制約に限り、MUST、MUST NOT、REQUIRED を使います。

希望や既定の設定に修飾語を使わないでください。すべての指示に MUST を使うと、どの指示も目立たなくなります。

用語の一貫性

概念ごとに用語を1つ選び、一貫して使用します。

適切：「API endpoint」を常に使用する 避ける：「API endpoint」「URL」「route」「path」を交互に使用する

構造の最適化

重要な制約を先に配置します。ファイルの冒頭に最も重要な情報を記載します。

段階的に詳細化します。まず全体的なルールを示し、次にドメイン固有のルール、最後にファイル固有のルールを示します。

関心事を明確に分けます。トピックごとにセクションを1つ設けます。テストのルールとデプロイの手順を混在させないでください。

セクションを明確に締めくくります。末尾に「など」や「その他」を残さないでください。

よくあるアンチパターン

言語に関するアンチパターン

提案するような表現：

• 避ける：「async/await の使用を検討してください」
• 適切：「I/O 操作には async/await を使用します」

曖昧な数量表現：

• 避ける：「通常は入力を検証します」
• 適切：「API 境界で入力を検証します」

曖昧な条件表現：

• 避ける：「必要に応じてログを追加します」
• 適切：「スタックトレースとともにエラーを記録します。想定内の制御フローは記録しません。」

既定の選択肢がない複数の選択肢：

• 避ける：「テストには Jest、Vitest、または Mocha を使用します」
• 適切：「テストには Vitest を使用します。レガシーファイルでは Jest も使用できます。」

構造に関するアンチパターン

重要な制約を埋もれさせる：

• 避ける：長い前置きの後、途中に重要な要件を記載する
• 適切：まず重要な要件を記載し、必要に応じてその後に背景を説明する

強調しすぎる：

• 避ける：ほぼ すべての 単語を 太字にする
• 適切：違反すると失敗につながる厳格な制約にのみ太字を使用する

何でもリストにする：

• 避ける：すべてを箇条書きにする
• 適切：独立した項目にはリストを、相互関係の説明には文章を使用する

内容に関するアンチパターン

フレームワークのドキュメントを繰り返す：

• 避ける：「React のフックを使うと、関数コンポーネントで状態やライフサイクルを扱えます……」
• 適切：「フォームの状態はローカル状態ではなく、URL パラメーターに保存します」

一般的なベストプラクティス：

• 避ける：「関数は小さく、役割を明確にする必要があります」
• 適切：「API ハンドラーはルーティングのみに限定します。ロジックはサービスに移します。」

時間とともに変わる情報：

• 避ける：「2025 年 8 月より前は、レガシー API を使用します」
• 適切：「api.example.com/v2/ の v2 API を使用します」

装飾的な内容：歓迎のメッセージ、意欲を高める言葉、背景となる歴史。

仮定上のシナリオ：「将来的に Postgres に移行する場合……」。実際に必要になってから対応し、仮定の段階では扱いません。

最適化の手法

文の簡潔化

冗長な表現を削除します：

• 変更前：「変更をコミットする前に、必ずテストスイートを実行するようにしてください」
• 変更後：pytest を実行してからコミットします

関連する指示をまとめます：

• 変更前：「TypeScript を使用します。型注釈を追加します。strict モードを有効にします。」
• 変更後：「明示的な型注釈を使用し、TypeScript の strict モードを有効にします」

コマンドの指定

完全な指定：

## Commands
- `pytest tests/ --strict-markers --cov=src --cov-report=html`: Run tests with coverage
- `dotnet build --configuration Release --no-restore`: Production build
- `npm run lint -- --fix`: Auto-fix linting issues

次のようにはしません：

## Commands
Run pytest to test. Use dotnet build for building. Lint with npm.