プロンプト最適化 は何をしますか？
プロンプトの下書きを分析し、批評し、ECCエコシステムのコンポーネントにマッピングして、すぐに使える完全に最適化されたプロンプトを出力します。
いつ使用するか
- ユーザーが「このプロンプトを最適化して」「プロンプトを改善して」「このプロンプトを書き直して」と言った時
- ユーザーが「より良いプロンプトの書き方を手伝って」と言った時
- ユーザーが「Claude Codeに依頼する最善の方法は？」と言った時
- ユーザーが「プロンプトを最適化」「プロンプトを改善」「プロンプトの書き方」「この指示を最適化して」と言った時
- ユーザーがプロンプトの下書きを貼り付けて、フィードバックや改善を求めた時
- ユーザーが「これに対するプロンプトの書き方がわからない」と言った時
- ユーザーが「ECCをこれにどう使えばいい？」と言った時
- ユーザーが明示的に
/prompt-optimizeを呼び出した時
使用すべきでない場合
- ユーザーがタスクを直接実行してほしい場合（その場合は実行する）
- ユーザーが「コードを最適化」「パフォーマンスを最適化」「このコードを最適化」「パフォーマンスを最適化」と言った場合 — これらはリファクタリングタスクであり、プロンプト最適化ではありません
- ユーザーがECCの設定について質問している場合（代わりに
configure-eccを使用） - ユーザーがスキル一覧を欲しがっている場合（代わりに
skill-stocktakeを使用） - ユーザーが「とにかく実行して」「直接やって」と言った場合
動作方法
アドバイスのみ — ユーザーのタスクは実行しないでください。
コードを書いたり、ファイルを作成したり、コマンドを実行したり、実装アクションを一切行わないでください。あなたの唯一の出力は分析と最適化されたプロンプトです。
ユーザーが「とにかく実行して」「直接やって」「最適化しないで、実行して」と言った場合、このスキル内で実装モードに切り替えないでください。このスキルは最適化されたプロンプトのみを生成することをユーザーに伝え、実行を希望する場合は通常のタスクリクエストを行うように指示してください。
以下の6フェーズのパイプラインを順次実行してください。結果は以下の出力形式で提示してください。
分析パイプライン
フェーズ0: プロジェクト検出
プロンプトを分析する前に、現在のプロジェクトコンテキストを検出します。
- 作業ディレクトリに
CLAUDE.mdが存在するか確認 — プロジェクトの規約を読み取る - プロジェクトファイルから技術スタックを検出:
package.json→ Node.js / TypeScript / React / Next.jsgo.mod→ Gopyproject.toml/requirements.txt→ PythonCargo.toml→ Rustbuild.gradle/pom.xml→ Java / Kotlin (ビルドファイルにquarkusがあれば Quarkus、spring-bootがあれば Spring Boot)Package.swift→ SwiftGemfile→ Rubycomposer.json→ PHP*.csproj/*.sln→ .NETMakefile/CMakeLists.txt→ C / C++cpanfile/Makefile.PL→ Perl
- 検出された技術スタックをフェーズ3とフェーズ4で使用するために記録
プロジェクトファイルが見つからない場合（プロンプトが抽象的、または新規プロジェクトの場合など）、検出をスキップし、フェーズ4で「技術スタック不明」とフラグを立てます。
フェーズ1: 意図検出
ユーザーのタスクを1つ以上のカテゴリに分類します。
| カテゴリ | シグナルワード | 例 |
|---|---|---|
| 新機能 | 作成、追加、実装、build、create、add、implement | 「ログインページを作成」 |
| バグ修正 | 修正、壊れている、動かない、エラー、fix、broken、not working、error | 「認証フローを修正」 |
| リファクタリング | リファクタ、整理、再構築、refactor、clean up、restructure | 「APIレイヤーをリファクタリング」 |
| 調査 | 方法、とは、調査、検討、how to、what is、explore、investigate | 「SSOを追加する方法」 |
| テスト | テスト、カバレッジ、検証、test、coverage、verify | 「カートにテストを追加」 |
| レビュー | レビュー、監査、チェック、review、audit、check | 「PRをレビュー」 |
| ドキュメント | 文書化、ドキュメント更新、document、update docs | 「APIドキュメントを更新」 |
| インフラ | デプロイ、CI、Docker、データベース、deploy、CI、docker、database | 「CI/CDパイプラインを設定」 |
| 設計 | 設計、アーキテクチャ、計画、design、architecture、plan | 「データモデルを設計」 |
フェーズ2: スコープ評価
フェーズ0でプロジェクトが検出された場合は、コードベースのサイズをシグナルとして使用します。それ以外の場合は、プロンプトの説明のみから推定し、推定値は不確実であるとマークします。
| スコープ | ヒューリスティック | オーケストレーション |
|---|---|---|
| TRIVIAL | 単一ファイル、50行未満 | 直接実行 |
| LOW | 単一コンポーネントまたはモジュール | 単一コマンドまたはスキル |
| MEDIUM | 複数コンポーネント、同一ドメイン | コマンドチェーン + /verify |
| HIGH | クロスドメイン、5ファイル以上 | 最初に /plan、次に段階的実行 |
| EPIC | 複数セッション、複数PR、アーキテクチャ変更 | ブループリントスキルを使用して複数セッション計画を作成 |
フェーズ3: ECCコンポーネントマッチング
意図 + スコープ + 技術スタック（フェーズ0から）を特定のECCコンポーネントにマッピングします。
意図タイプ別
| 意図 | コマンド | スキル | エージェント |
|---|---|---|---|
| 新機能 | /plan, /tdd, /code-review, /verify | tdd-workflow, verification-loop | planner, tdd-guide, code-reviewer |
| バグ修正 | /tdd, /build-fix, /verify | tdd-workflow | tdd-guide, build-error-resolver |
| リファクタリング | /refactor-clean, /code-review, /verify | verification-loop | refactor-cleaner, code-reviewer |
| 調査 | /plan | search-first, iterative-retrieval | — |
| テスト | /tdd, /e2e, /test-coverage | tdd-workflow, e2e-testing | tdd-guide, e2e-runner |
| レビュー | /code-review | security-review | code-reviewer, security-reviewer |
| ドキュメント | /update-docs, /update-codemaps | — | doc-updater |
| インフラ | /plan, /verify | docker-patterns, deployment-patterns, database-migrations | architect |
| 設計 (MEDIUM-HIGH) | /plan | — | planner, architect |
| 設計 (EPIC) | — | blueprint (スキルとして呼び出し) | planner, architect |
技術スタック別
| 技術スタック | 追加するスキル | エージェント |
|---|---|---|
| Python / Django | django-patterns, django-tdd, django-security, django-verification, python-patterns, python-testing | python-reviewer |
| Go | golang-patterns, golang-testing | go-reviewer, go-build-resolver |
| Spring Boot / Java | springboot-patterns, springboot-tdd, springboot-security, springboot-verification, java-coding-standards, jpa-patterns | java-reviewer |
| Quarkus / Java | quarkus-patterns, quarkus-tdd, quarkus-security, quarkus-verification, java-coding-standards, jpa-patterns | java-reviewer |
| Kotlin / Android | kotlin-coroutines-flows, compose-multiplatform-patterns, android-clean-architecture | kotlin-reviewer |
| TypeScript / React | frontend-patterns, backend-patterns, coding-standards | code-reviewer |
| Swift / iOS | swiftui-patterns, swift-concurrency-6-2, swift-actor-persistence, swift-protocol-di-testing | code-reviewer |
| PostgreSQL | postgres-patterns, database-migrations | database-reviewer |
| Perl | perl-patterns, perl-testing, perl-security | code-reviewer |
| C++ | cpp-coding-standards, cpp-testing | code-reviewer |
| その他 / 未記載 | coding-standards (汎用) | code-reviewer |
フェーズ4: 不足コンテキスト検出
プロンプトに不足している重要な情報がないかスキャンします。各項目をチェックし、フェーズ0で自動検出されたか、ユーザーが提供する必要があるかをマークします。
- 技術スタック — フェーズ0で検出されたか、ユーザーが指定する必要があるか？
- 対象スコープ — ファイル、ディレクトリ、またはモジュールは言及されているか？
- 受入基準 — タスクが完了したかどうかを判断する方法は？
- エラーハンドリング — エッジケースと障害モードは対処されているか？
- セキュリティ要件 — 認証、入力検証、シークレットは？
- テスト期待値 — 単体テスト、統合テスト、E2Eテストは？
- パフォーマンス制約 — 負荷、レイテンシ、リソース制限は？
- UI/UX要件 — デザイン仕様、レスポンシブ、a11y？（フロントエンドの場合）
- データベース変更 — スキーマ、マイグレーション、インデックス？（データレイヤーの場合）
- 既存パターン — 参照ファイルや従うべき規約は？
- スコープ境界 — やってはいけないことは？
3つ以上の重要な項目が不足している場合、最適化されたプロンプトを生成する前に、最大3つの質問をユーザーにしてください。その後、回答を最適化されたプロンプトに組み込みます。
フェーズ5: ワークフローとモデルの推奨
このプロンプトが開発ライフサイクルのどこに位置するかを判断します。
調査 → 計画 → 実装 (TDD) → レビュー → 検証 → コミット
MEDIUM以上のタスクでは、常に /plan から始めます。EPICタスクでは、ブループリントスキルを使用します。
モデル推奨 (出力に含める):
| スコープ | 推奨モデル | 根拠 |
|---|---|---|
| TRIVIAL-LOW | Sonnet 5 | シンプルなタスクには高速でコスト効率が良い |
| MEDIUM | Sonnet 5 | 標準的な作業に最適なコーディングモデル |
| HIGH | Sonnet 5 (メイン) + Opus 5 (計画) | アーキテクチャはOpus、実装はSonnet |
| EPIC | Opus 5 (ブループリント) + Sonnet 5 (実行) | 複数セッション計画には深い推論が必要 |
マルチプロンプト分割 (HIGH/EPICスコープの場合):
単一セッションを超えるタスクの場合は、順次プロンプトに分割します。
- プロンプト1: 調査 + 計画（search-first スキルを使用し、次に /plan）
- プロンプト2-N: フェーズごとに1つのプロンプトで実装（各プロンプトは /verify で終了）
- 最終プロンプト: 全フェーズにわたる統合テスト + /code-review
- /save-session と /resume-session を使用してセッション間のコンテキストを保持
出力形式
分析を以下の正確な構造で提示します。ユーザーの入力と同じ言語で応答してください。
セクション1: プロンプト診断
強み: 元のプロンプトの優れている点をリストします。
問題点:
| 問題点 | 影響 | 提案される修正 |
|---|---|---|
| (問題) | (結果) | (修正方法) |
明確化の必要性: ユーザーが回答すべき質問の番号付きリスト。フェーズ0で自動的に回答が検出された場合は、質問する代わりにその回答を記載します。
セクション2: 推奨ECCコンポーネント
| タイプ | コンポーネント | 目的 |
|---|---|---|
| コマンド | /plan | コーディング前にアーキテクチャを計画 |
| スキル | tdd-workflow | TDD方法論のガイダンス |
| エージェント | code-reviewer | 実装後のレビュー |
| モデル | Sonnet 5 | このスコープに推奨 |
セクション3: 最適化済みプロンプト — 完全版
完全に最適化されたプロンプトを単一のフェンス付きコードブロック内に提示します。プロンプトは自己完結型で、コピー＆ペーストですぐに使用できる必要があります。以下を含めます。
- コンテキストを含む明確なタスク説明
- 技術スタック（検出済みまたは指定済み）
- 適切なワークフローステージでの /command 呼び出し
- 受入基準
- 検証手順
- スコープ境界（やってはいけないこと）
ブループリントを参照する項目については、「ブループリントスキルを使用して...」と記述します（blueprint はスキルであり、コマンドではないため /blueprint とは記述しません）。
セクション4: 最適化済みプロンプト — クイック版
経験豊富なECCユーザー向けのコンパクトなバージョン。意図タイプによって異なります。
| 意図 | クイックパターン |
|---|---|
| 新機能 | /plan [機能]. /tdd で実装. /code-review. /verify. |
| バグ修正 | /tdd — [バグ]の失敗テストを記述. 修正してグリーンに. /verify. |
| リファクタリング | /refactor-clean [スコープ]. /code-review. /verify. |
| 調査 | search-first スキルを[トピック]に使用. 結果に基づいて /plan. |
| テスト | /tdd [モジュール]. クリティカルフローは /e2e. /test-coverage. |
| レビュー | /code-review. 次に security-reviewer エージェントを使用. |
| ドキュメント | /update-docs. /update-codemaps. |
| EPIC | ブループリントスキルを「[目的]」に使用. /verify ゲートでフェーズを実行. |
セクション5: 改善の根拠
| 改善点 | 理由 |
|---|---|
| (追加されたもの) | (なぜ重要か) |
フッター
ご希望の内容と異なりますか？ 調整が必要な点をお知らせいただくか、プロンプト最適化ではなく実行をご希望の場合は、通常のタスクリクエストを行ってください。
例
トリガー例
- 「このプロンプトをECC用に最適化して」
- 「Claude Codeが適切なコマンドを使うようにこのプロンプトを書き換えて」
- 「この指示を最適化して」
- 「このタスクのためにECCにどうプロンプトを送ればいい？」
例1: 曖昧な中国語プロンプト（プロジェクト検出済み）
ユーザー入力:
帮我写一个用户登录ページ
フェーズ0が検出: package.json with Next.js 15, TypeScript, Tailwind CSS
最適化済みプロンプト（完全版）:
プロジェクトの既存技術スタック（Next.js 15 + TypeScript + Tailwind CSS）を使用してユーザーログインページを実装してください。
技術要件:
- プロジェクトの既存コンポーネント構造とルーティング規則に従う
- フォームバリデーションにはプロジェクトで既存のバリデーションスキームを使用する（Zod/Yup/その他が既に使用されているか確認）
- 認証方式: プロジェクトの既存認証スキームに従う（ない場合は、デフォルトでJWT）
- 含めるもの: メール/パスワードログインフォーム、フォームバリデーション、エラー表示、ローディング状態、レスポンシブレイアウト
ワークフロー:
1. /plan でコンポーネント構造と認証フローを計画し、既存ページのパターンを参照
2. /tdd テストファースト: ログインフォームの単体テストと認証フローの統合テストを作成
3. ログインページと認証ロジックを実装
4. /code-review で実装をレビュー
5. /verify で全てのテストが合格し、ページが正常にレンダリングされることを検証
セキュリティ要件:
- パスワードは平文で送信しない
- ブルートフォース攻撃の防止（レート制限）
- XSS対策
- CSRFトークン
受入基準:
- すべてのテストが合格し、カバレッジ80%以上
- モバイルとデスクトップの両方でページが正常にレンダリングされること
- ログイン成功時はダッシュボードにリダイレクト、失敗時はエラーメッセージを表示
やってはいけないこと:
- 登録ページは実装しない
- パスワード忘れ機能は実装しない
- 既存のルーティング構造は変更しない
例2: 適度な英語プロンプト
ユーザー入力:
Add a REST API endpoint for user profile updates with validation
フェーズ0が検出: go.mod with Go 1.22, Chi router
最適化済みプロンプト（完全版）:
ユーザープロフィール更新用のREST APIエンドポイント（PATCH /api/users/:id）を追加してください。
技術スタック: Go 1.22 + Chi router（プロジェクトから検出）
要件:
- PATCH /api/users/:id — ユーザープロフィールの部分更新
- フィールドの入力検証: name, email, avatar_url, bio
- 認証: 有効なトークンが必要、ユーザーは自身のプロフィールのみ更新可能
- 成功時は200と更新されたユーザーを返す
- 無効な入力時は400とバリデーションエラーを返す
- 認証失敗時は401/403を返す
- コードベースの既存APIパターンに従う
ワークフロー:
1. /plan でエンドポイント構造、ミドルウェアチェーン、バリデーションロジックを計画
2. /tdd — 成功、バリデーション失敗、認証失敗、未発見のテーブル駆動テストを作成
3. 既存のハンドラパターンに従って実装
4. /go-review
5. /verify — 全テストスイートを実行し、リグレッションがないことを確認
やってはいけないこと:
- 既存のエンドポイントを変更しない
- データベーススキーマを変更しない（既存のユーザーテーブルを使用）
- 最初に既存の依存関係を確認せずに新しい依存関係を追加しない（search-first スキルを使用）
例3: EPICプロジェクト
ユーザー入力:
Migrate our monolith to microservices
最適化済みプロンプト（完全版）:
ブループリントスキルを使用して計画: 「モノリスをマイクロサービスアーキテクチャに移行」
実行前に、ブループリントで次の質問に回答してください:
1. 現在のモノリスにはどのようなドメイン境界が存在しますか？
2. 最初に抽出すべきサービスはどれですか（結合度が最も低いもの）？
3. 通信パターン: REST API、gRPC、またはイベント駆動（Kafka/RabbitMQ）？
4. データベース戦略: 最初は共有DB、それとも最初からサービスごとのデータベース？
5. デプロイメントターゲット: Kubernetes、Docker Compose、またはサーバーレス？
ブループリントは次のようなフェーズを生成する必要があります:
- フェーズ1: サービス境界を特定し、ドメインマップを作成
- フェーズ2: インフラをセットアップ（APIゲートウェイ、サービスメッシュ、サービスごとのCI/CD）
- フェーズ3: 最初のサービスを抽出（strangler fig パターン）
- フェーズ4: 統合テストで検証し、次のサービスを抽出
- フェーズN: モノリスを廃止
各フェーズ = 1 PR、フェーズ間に /verify ゲートを配置。
セッション間で /save-session を使用。
…
[翻訳のため省略]