プロンプト最適化ツール は何をしますか？
ユーザーのドラフトプロンプトを分析・批評し、ECCエコシステムのコンポーネントとマッチングして、すぐに貼り付けて実行できる完全な最適化済みプロンプトを出力します。
使用タイミング
- ユーザーが「このプロンプトを最適化して」「プロンプトを改善して」「このプロンプトを書き直して」と言った場合
- ユーザーが「...のためのより良いプロンプトを書くのを手伝って」と言った場合
- ユーザーが「Claude Codeに...を依頼する最良の方法は？」と言った場合
- ユーザーが「优化prompt」「改进prompt」「怎么写prompt」「帮我优化这个指令」と言った場合
- ユーザーがドラフトプロンプトを貼り付けてフィードバックや改善を依頼した場合
- ユーザーが「これについてどうプロンプトすればいいか分からない」と言った場合
- ユーザーが「ECCを...にどう使えばいいか」と言った場合
- ユーザーが明示的に
/prompt-optimizeを呼び出した場合
使用すべきでないタイミング
- ユーザーがタスクを直接実行して欲しい場合（そのまま実行する）
- ユーザーが「优化代码」「优化性能」「optimize this code」「optimize performance」と言った場合 — これらはリファクタリングタスクであり、プロンプト最適化ではありません
- ユーザーがECCの設定について質問している場合（代わりに
configure-eccを使用） - ユーザーがスキル一覧を欲しがっている場合（代わりに
skill-stocktakeを使用） - ユーザーが「just do it」「直接做」と言った場合
仕組み
アドバイスのみ — ユーザーのタスクを実行しないでください。
コードを書いたり、ファイルを作成したり、コマンドを実行したり、実装アクションを一切行わないでください。唯一の出力は分析と最適化されたプロンプトです。
ユーザーが「just do it」「直接做」「最適化しないで実行して」と言った場合、このスキル内で実装モードに切り替えないでください。このスキルは最適化されたプロンプトのみを生成することをユーザーに伝え、実行が必要な場合は通常のタスク要求を行うよう指示してください。
以下の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 / Spring BootPackage.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ドキュメントを更新」 |
| インフラ | deploy, CI, docker, database, 部署, 数据库 | 「CI/CDパイプラインを設定」 |
| 設計 | design, architecture, plan, 设计, 架构 | 「データモデルを設計」 |
フェーズ2: スコープ評価
フェーズ0でプロジェクトが検出された場合は、コードベースのサイズをシグナルとして使用します。それ以外の場合は、プロンプトの説明だけから見積もり、その見積もりは不確実であるとマークします。
| スコープ | ヒューリスティック | オーケストレーション |
|---|---|---|
| TRIVIAL | 単一ファイル、50行未満 | 直接実行 |
| LOW | 単一コンポーネントまたはモジュール | 単一コマンドまたはスキル |
| MEDIUM | 複数コンポーネント、同一ドメイン | コマンドチェーン + /verify |
| HIGH | クロスドメイン、5ファイル以上 | 最初に /plan、その後フェーズ実行 |
| EPIC | 複数セッション、複数PR、アーキテクチャ変更 | blueprint スキルをマルチセッションプランに使用 |
フェーズ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 | code-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要件 — デザインスペック、レスポンシブ、アクセシビリティ？（フロントエンドの場合）
- データベース変更 — スキーマ、マイグレーション、インデックス？（データ層の場合）
- 既存パターン — 参照ファイルや従うべき規約？
- スコープ境界 — やらないこと？
3つ以上の重要な項目が不足している場合、最適化プロンプトを生成する前に、最大3つの明確化質問をユーザーに投げかけてください。その後、回答を最適化プロンプトに組み込んでください。
フェーズ5: ワークフローとモデル推奨
このプロンプトが開発ライフサイクルのどこに位置するかを判断します:
調査 → 計画 → 実装（TDD）→ レビュー → 検証 → コミット
MEDIUM以上のタスクでは、必ず /plan から始めてください。EPICタスクでは blueprint スキルを使用してください。
モデル推奨（出力に含める）
| スコープ | 推奨モデル | 根拠 |
|---|---|---|
| TRIVIAL-LOW | Sonnet 4.6 | 単純なタスクに高速で費用対効果が高い |
| MEDIUM | Sonnet 4.6 | 標準的な作業に最適なコーディングモデル |
| HIGH | Sonnet 4.6（メイン）+ Opus 4.6（計画） | Opusがアーキテクチャ、Sonnetが実装 |
| EPIC | Opus 4.6（設計図）+ Sonnet 4.6（実行） | マルチセッション計画に深い推論 |
マルチプロンプト分割（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 4.6 | このスコープに推奨 |
セクション3: 最適化プロンプト — 完全版
完全に最適化されたプロンプトを単一のフェンスコードブロック内に提示します。プロンプトは自己完結型で、コピーペーストできる状態である必要があります。以下を含めてください:
- コンテキストを含む明確なタスク説明
- 技術スタック（検出または指定されたもの）
- 適切なワークフローステージでの
/command呼び出し - 受け入れ基準
- 検証手順
- スコープ境界（やってはいけないこと）
blueprint を参照する項目では、「blueprint スキルを使用して...」と記述します（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 | blueprint スキルを「[目的]」に使用. 各フェーズを /verify ゲートで実行. |
セクション5: 改善根拠
| 改善点 | 理由 |
|---|---|
| （追加されたもの） | （なぜそれが重要なのか） |
例
例1: 曖昧な中国語プロンプト（プロジェクト検出あり）
ユーザー入力: 帮我写一个用户登录页面
フェーズ0で検出: package.json に 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%以上
- モバイル・デスクトップ両方でページが正常にレンダリングされること
- ログイン成功時にダッシュボードへ遷移、失敗時にはエラーメッセージを表示
やってはいけないこと:
- 登録ページを実装しない
- パスワードリセット機能を実装しない
- 既存のルーティング構造を変更しない