prompt-improver

プロンプト改善ツール

コード関連のプロンプトを、明確さ、調査を優先する思考、検証の観点から最適化します。

入力

$ARGUMENTS

---

ステップ 1：プロンプトを分析する

入力プロンプトを次の観点から評価します。

観点	確認事項
タスクの明確さ	タスクの種類は明確ですか？（実装、修正、リファクタリング、レビュー、テスト）範囲は定義されていますか？
調査	作業前に読み、理解するよう指定されていますか？
検証	適切な確認事項はありますか？（テスト、ビルド、リンターの実行）
コンテキストの明確化	特定のファイル、関数、パターンを参照していますか？
アクションの具体性	望ましい結果は明確ですか？品質への期待が示されていますか？
範囲の管理	適切な範囲に収まっていますか？明確な終了条件はありますか？

入力プロンプトで弱い、または不足している観点を特定します。

ゲート（順番に実施）

順番どおりに完了してください。ステップを飛ばさないでください。

1. 監査ゲート（ステップ 1 の最後）： 合格条件： 続く「分析」でタスクの種類を明示し、表にある弱い、または不足している観点をすべて列挙するか、すべての観点が十分であることを明示します。十分と判断した観点には、その理由を簡潔に添えます。
2. 変換ゲート（ステップ 2）： 合格条件： 「適用した改善」に列挙するすべての改善が、監査で特定した不足点に対応しているか、プロンプトがすでに十分な場合は意図的な強化であること。
3. 出力ゲート（ステップ 3）： 合格条件： ゲート 1〜2 に合格した後にのみ、「最適化されたプロンプト」ブロックを出力します。

ステップ 2：変換ルールを適用する

タスクの明確さ

• 曖昧な依頼を、具体的なタスクの種類と範囲に置き換えます
• 曖昧な場合は、「実装する」「修正する」「リファクタリングする」「レビューする」「テストする」を追加します
• 推測可能な場合は、対象となるファイルやコンポーネントを指定します

調査優先

• 「変更を加える前に、関連ファイルを読んで理解してください」を追加します
• バグの場合：「まず再現し、根本原因を理解してください」
• 機能の場合：「コードベース内の既存のパターンを確認してください」

幻覚の防止

• 「読んでいないコード構造を推測しないでください」
• 「使用する前に、インポートや依存関係が存在することを確認してください」
• 「新しく作成する前に、既存のユーティリティがないか確認してください」

検証手順

• 実装の場合：「変更後にテストを実行してください」
• リファクタリングの場合：「動作が変わっていないことを確認してください」
• 修正の場合：「修正を検証し、リグレッションがないか確認してください」

ポジティブな表現

• 「テストを壊さないでください」を「変更後にテストが合格することを確認してください」に置き換えます
• 「過剰に設計しないでください」を「最小限の解決策を実装してください」に置き換えます

範囲の管理

• 範囲が不足している場合は、明確な境界を追加します
• 必要に応じて、複数の依頼をフェーズに分けます

例

バグ修正

Original: "fix the login bug"

Optimized:
Fix the login bug. First, read the authentication-related files to understand
the current implementation. Reproduce the bug to confirm the issue. Identify
the root cause before making changes. Implement the fix and run existing tests
to verify no regressions.

機能の実装

Original: "add dark mode"

Optimized:
Implement dark mode for the application. First, check how theming/styling is
currently handled in the codebase. Look for existing color variables or theme
patterns. Implement the toggle and theme switching with minimal changes to
existing components. Run tests and verify the UI renders correctly in both modes.

リファクタリング

Original: "clean up the user service"

Optimized:
Refactor the user service for improved maintainability. Read the current
implementation and understand its responsibilities. Identify specific issues
(duplication, unclear naming, tight coupling). Make incremental changes,
running tests after each step to ensure behavior is unchanged.

タスクの種類別のヒント

タスクの種類	ヒント
バグ修正	わかっている場合は、再現手順を含めます。簡単な修正でよいのか、根本原因の分析が必要なのかを指定します。
機能の実装	コードベース内の類似機能を参照します。テストが必要かどうかを指定します。
リファクタリング	目標（可読性、パフォーマンス、テスト容易性）を示します。段階的な変更を重視します。
コードレビュー	注目する領域（セキュリティ、パフォーマンス、スタイル）を指定します。対象外とする内容も示します。
テスト	テストの種類（単体、統合、E2E）を指定します。既存のテストパターンを参照します。

ステップ 3：出力を生成する

ステップ 1 のゲート（監査 → 変換 → 出力）に従います。次の形式で正確に出力します。

分析

[プロンプトの種類と、弱い、または不足している観点、あるいはすべての観点がすでに十分である理由を 2〜3 文で説明します]

適用した改善

• [適用した具体的な変換を箇条書きで記載します]

最適化されたプロンプト

[The improved prompt, ready to copy and use]

このタスクの種類に関するヒント

[タスクの種類別のヒントの表から、関連するヒントを 1〜2 文で記載します]