Prompt Optimizer
分析草稿提示词，批评它，匹配 ECC 生态系统组件，并输出一个用户可以直接复制粘贴并运行的完整优化提示词。
何时使用
- 用户说“优化这个提示词”、“改进我的提示词”、“重写这个提示词”
- 用户说“帮我写一个更好的提示词来...”
- 用户说“让 Claude Code 做...的最佳方式是什么”
- 用户说“优化prompt”、“改进prompt”、“怎么写prompt”、“帮我优化这个指令”
- 用户粘贴一个草稿提示词并寻求反馈或改进
- 用户说“我不知道怎么提示这个”
- 用户说“我该如何用 ECC 来做...”
- 用户明确调用
/prompt-optimize
不要使用的情况
- 用户想直接完成任务（直接执行它）
- 用户说“优化代码”、“优化性能”、“optimize this code”、“optimize performance” — 这些是重构任务，而非提示词优化
- 用户询问 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：意图检测
将用户的任务分类为一个或多个类别：
| 类别 | 信号词 | 示例 |
|---|---|---|
| 新功能 | build, create, add, implement, 创建, 实现, 添加 | “构建一个登录页面” |
| Bug 修复 | 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 检测到项目，则使用代码库大小作为信号。否则，仅根据提示词描述进行估计，并将估计标记为不确定。
| 范围 | 启发式规则 | 编排方式 |
|---|---|---|
| 微小 | 单个文件，少于 50 行 | 直接执行 |
| 低 | 单个组件或模块 | 单个命令或技能 |
| 中 | 多个组件，同一领域 | 命令链 + /verify |
| 高 | 跨领域，5 个以上文件 | 先 /plan，再分阶段执行 |
| 史诗级 | 多会话、多 PR、架构变更 | 使用蓝图技能制定多会话计划 |
阶段 3：ECC 组件匹配
将意图 + 范围 + 技术栈（来自阶段 0）映射到特定的 ECC 组件。
按意图类型
| 意图 | 命令 | 技能 | 代理 |
|---|---|---|---|
| 新功能 | /plan, /tdd, /code-review, /verify | tdd-workflow, verification-loop | planner, tdd-guide, code-reviewer |
| Bug 修复 | /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 |
| 设计（中-高） | /plan | — | planner, architect |
| 设计（史诗级） | — | 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) → 审查 → 验证 → 提交
对于中+ 任务，始终以 /plan 开始。对于史诗级任务，使用蓝图技能。
模型推荐（包含在输出中）：
| 范围 | 推荐模型 | 理由 |
|---|---|---|
| 微小-低 | Sonnet 5 | 快速、成本效益高，适用于简单任务 |
| 中 | Sonnet 5 | 标准工作的最佳编码模型 |
| 高 | Sonnet 5（主要）+ Opus 5（规划） | Opus 用于架构，Sonnet 用于实现 |
| 史诗级 | Opus 5（蓝图）+ Sonnet 5（执行） | 深度推理，适用于多会话规划 |
多提示词拆分（适用于高/史诗级范围）：
对于超过单个会话的任务，拆分为连续的提示词：
- 提示词 1：调研 + 计划（先使用 search-first 技能，然后 /plan）
- 提示词 2-N：每个提示词实现一个阶段（每个以 /verify 结束）
- 最终提示词：跨所有阶段的集成测试 + /code-review
- 使用 /save-session 和 /resume-session 在会话之间保留上下文
输出格式
以精确的结构呈现您的分析。以与用户输入相同的语言回应。
第 1 节：提示词诊断
优点： 列出原始提示词做得好地方。
问题：
| 问题 | 影响 | 建议修复 |
|---|---|---|
| (问题) | (后果) | (如何修复) |
需要澄清： 用户应回答的问题编号列表。如果阶段 0 自动检测到答案，则说明该答案而不是提问。
第 2 节：推荐的 ECC 组件
| 类型 | 组件 | 目的 |
|---|---|---|
| 命令 | /plan | 编码前规划架构 |
| 技能 | tdd-workflow | TDD 方法论指导 |
| 代理 | code-reviewer | 实现后审查 |
| 模型 | Sonnet 5 | 为这个范围推荐 |
第 3 节：优化提示词 — 完整版
在单个围栏代码块内呈现完整的优化提示词。提示词必须自包含且可复制粘贴。包括：
- 带有上下文的清晰任务描述
- 技术栈（检测到或指定）
- 在工作流适当阶段的 /command 调用
- 验收标准
- 验证步骤
- 范围边界（不要做什么）
对于引用蓝图的项目，请编写：“使用蓝图技能来...”（而不是 /blueprint，因为蓝图是技能，而非命令）。
第 4 节：优化提示词 — 快速版
为经验丰富的 ECC 用户提供的紧凑版本。根据意图类型变化：
| 意图 | 快速模式 |
|---|---|
| 新功能 | /plan [功能]。/tdd 来实现。/code-review。/verify。 |
| Bug 修复 | /tdd — 为 [bug] 编写失败测试。修复到绿灯。/verify。 |
| 重构 | /refactor-clean [范围]。/code-review。/verify。 |
| 调研 | 对于 [主题] 使用 search-first 技能。/plan 基于发现。 |
| 测试 | /tdd [模块]。/e2e 用于关键流程。/test-coverage。 |
| 审查 | /code-review。然后使用 security-reviewer 代理。 |
| 文档 | /update-docs。/update-codemaps。 |
| 史诗级 | 为“[目标]”使用蓝图技能。执行阶段，以 /verify 为关卡。 |
第 5 节：增强理由
| 增强项 | 理由 |
|---|---|
| (添加了什么) | (为什么重要) |
页脚
不是您需要的？告诉我需要调整什么，或者如果您希望执行而不是优化提示词，请提出正常的任务请求。
示例
触发示例
- “为 ECC 优化这个提示词”
- “重写这个提示词，以便 Claude Code 使用正确的命令”
- “帮我优化这个指令”
- “我该如何为这个任务提示 ECC？”
示例 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 验证所有测试通过且页面正常渲染
安全要求：
- 密码不明文传输
- 防止暴力破解（rate limiting）
- XSS 防护
- CSRF token
验收标准：
- 所有测试通过，覆盖率 80%+
- 页面在移动端和桌面端正常渲染
- 登录成功跳转到 dashboard，失败显示错误信息
不要做：
- 不要实现注册页面
- 不要实现忘记密码功能
- 不要修改现有的路由结构
示例 2：中等英文提示词
用户输入：
Add a REST API endpoint for user profile updates with validation
阶段 0 检测： go.mod 包含 Go 1.22，Chi 路由器
优化提示词（完整版）：
添加一个用于用户个人资料更新的 REST API 端点（PATCH /api/users/:id）。
技术栈：Go 1.22 + Chi 路由器（从项目检测到）
要求：
- 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：史诗级项目
用户输入：
Migrate our monolith to microservices
优化提示词（完整版）：
使用蓝图技能来规划：“将单体应用迁移到微服务架构”
在执行之前，在蓝图中回答这些问题：
1. 当前单体中的领域边界有哪些？
2. 应该首先提取哪个服务（耦合度最低）？
3. 通信模式：REST API、gRPC 还是事件驱动（Kafka/RabbitMQ）？
4. 数据库策略：最初共享数据库还是一开始就每个服务独立数据库？
5. 部署目标：Kubernetes、Docker Compose 还是无服务器？
蓝图应生成如下阶段：
- 阶段 1：识别服务边界并创建领域映射图
- 阶段 2：搭建基础设施（API 网关、服务网格、每个服务的 CI/CD）
- 阶段 3：提取第一个服务（绞杀者模式）
- 阶段 4：使用集成测试验证，然后提取下一个服务
- 阶段 N：停用单体应用
每个阶段 = 1 个 PR，阶段之间设置 /verify 关卡。
在阶段之间使用 /save-session
...
[为翻译而截断]