プロンプトオプティマイザー

プロンプトオプティマイザー は何をしますか？

プロンプトの下書きを分析、批評し、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: プロジェクト検出

プロンプトを分析する前に、現在のプロジェクトコンテキストを検出します。

1. 作業ディレクトリに CLAUDE.md が存在するか確認 — プロジェクトの規約を読み込みます
2. プロジェクトファイルから技術スタックを検出:
   • package.json → Node.js / TypeScript / React / Next.js
   • go.mod → Go
   • pyproject.toml / requirements.txt → Python
   • Cargo.toml → Rust
   • build.gradle / pom.xml → Java / Kotlin (ビルドファイル内の quarkus を確認 → Quarkus、または spring-boot → Spring Boot)
   • Package.swift → Swift
   • Gemfile → Ruby
   • composer.json → PHP
   • *.csproj / *.sln → .NET
   • Makefile / CMakeLists.txt → C / C++
   • cpanfile / Makefile.PL → Perl
3. 検出した技術スタックをフェーズ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、アーキテクチャ変更	ブループリントスキルを使用して複数セッション計画

フェーズ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要件 — デザイン仕様、レスポンシブ、アクセシビリティ？（フロントエンドの場合）
• データベース変更 — スキーマ、マイグレーション、インデックス？（データレイヤーの場合）
• 既存パターン — 参照すべきファイルや規約？
• 範囲境界 — やらないこと？

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回のセッションを超えるタスクの場合は、順次プロンプトに分割:

• プロンプト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で検出: Next.js 15、TypeScript、Tailwind CSS を含む package.json

最適化プロンプト（完全版）:

プロジェクトの既存技術スタック（Next.js 15 + TypeScript + Tailwind CSS）を使用してユーザーログインページを実装します。

技術要件:
- プロジェクトの既存コンポーネント構造とルーティング規則に従う
- フォーム検証にはプロジェクト内の既存検証方式を使用（Zod/Yup/その他の使用状況を確認）
- 認証方式: プロジェクトの既存認証方式に従う（ない場合はデフォルトでJWT）
- 含めるもの: メール/パスワードログインフォーム、フォーム検証、エラーメッセージ、ローディング状態、レスポンシブレイアウト

ワークフロー:
1. /plan でコンポーネント構造と認証フローを計画、既存ページのパターンを参照
2. /tdd テストファースト: ログインフォームの単体テストと認証フローの統合テストを作成
3. ログインページと認証ロジックを実装
4. /code-review で実装をレビュー
5. /verify ですべてのテスト合格とページの正常レンダリングを確認

セキュリティ要件:
- パスワードは平文で送信しない
- ブルートフォース対策（レート制限）
- XSS対策
- CSRFトークン

受入基準:
- すべてのテスト合格、カバレッジ80%以上
- ページがモバイルとデスクトップで正常にレンダリングされる
- ログイン成功時にダッシュボードへ遷移、失敗時にはエラー情報を表示

やらないこと:
- 登録ページは実装しない
- パスワード忘れ機能は実装しない
- 既存のルーティング構造は変更しない

例2: 中程度の英語プロンプト

ユーザー入力:

検証付きのユーザープロフィール更新用REST APIエンドポイントを追加

フェーズ0で検出: Go 1.22、Chi Router を含む go.mod

最適化プロンプト（完全版）:

ユーザープロフィール更新用の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プロジェクト

ユーザー入力:

モノリスをマイクロサービスに移行する

最適化プロンプト（完全版）:

ブループリントスキルを使用して計画: 「モノリスをマイクロサービスアーキテクチャに移行」

実行前に、ブループリントで以下の質問に回答:
1. 現在のモノリスにはどのようなドメイン境界が存在するか？
2. 最初に抽出すべきサービスはどれか（結合度が最も低いもの）？
3. 通信パターン: REST API、gRPC、またはイベント駆動（Kafka/RabbitMQ）？
4. データベース戦略: 最初は共有DB、それとも最初からサービスごとのDB？
5. デプロイメントターゲット: Kubernetes、Docker Compose、またはサーバーレス？

ブループリントは以下のようなフェーズを生成する必要があります:
- フェーズ1: サービス境界を特定し、ドメインマップを作成
- フェーズ2: インフラのセットアップ（APIゲートウェイ、サービスメッシュ、サービスごとのCI/CD）
- フェーズ3: 最初のサービスを抽出（ストラングラーフィグパターン）
- フェーズ4: 統合テストで検証し、次のサービスを抽出
- フェーズN: モノリスを廃止

各フェーズ = 1 PR、フェーズ間に /verify ゲートを設定。
フェーズ間で /save-session を使用。

---

[翻訳のため省略]