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, 创建, 实现, 添加 | “构建一个登录页面” |
| 缺陷修复 | 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 | 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中检测到，还是用户必须指定？
- 目标范围 — 是否提到了文件、目录或模块？
- 验收标准 — 如何知道任务已完成？
- 错误处理 — 是否涉及边缘情况和失败模式？
- 安全要求 — 认证、输入验证、密钥？
- 测试期望 — 单元测试、集成测试、端到端测试？
- 性能约束 — 负载、延迟、资源限制？
- UI/UX要求 — 设计规范、响应式、可访问性？（如果是前端）
- 数据库更改 — 架构、迁移、索引？（如果是数据层）
- 现有模式 — 需要遵循的参考文件或约定？
- 范围边界 — 不要做什么？
如果缺失3个以上关键项目，在生成优化提示词之前，向用户提出最多3个澄清问题。然后将答案整合到优化提示词中。
阶段5：工作流与模型推荐
确定此提示词在开发生命周期中的位置：
研究 → 计划 → 实现（TDD） → 评审 → 验证 → 提交
对于MEDIUM+任务，始终以 /plan 开始。对于EPIC任务，使用blueprint技能。
模型推荐（包含在输出中）：
| 范围 | 推荐模型 | 理由 |
|---|---|---|
| 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：每个提示词实现一个阶段（每个以 /verify 结束）
- 最终提示词：跨所有阶段的集成测试 + /code-review
- 使用 /save-session 和 /resume-session 来保持会话间的上下文
输出格式
按此精确结构呈现你的分析。使用与用户输入相同的语言回复。
第一部分：提示词诊断
优点： 列出原始提示词做得好之处。
问题：
| 问题 | 影响 | 建议修复 |
|---|---|---|
| （问题） | （后果） | （如何修复） |
需要澄清： 用户应回答的编号问题列表。如果阶段0已自动检测到答案，则直接陈述答案，而不是提问。
第二部分：推荐的ECC组件
| 类型 | 组件 | 用途 |
|---|---|---|
| 命令 | /plan | 编码前规划架构 |
| 技能 | tdd-workflow | TDD方法论指导 |
| 代理 | code-reviewer | 实现后评审 |
| 模型 | Sonnet 5 | 建议用于此范围 |
第三部分：优化提示词 — 完整版
在一个单独的围栏代码块中呈现完整的优化提示词。提示词必须自包含且准备好复制粘贴。包括：
- 清晰的任务描述及上下文
- 技术栈（检测到或指定的）
- 在工作流适当阶段的 /command 调用
- 验收标准
- 验证步骤
- 范围边界（不要做什么）
对于引用blueprint的项目，请写：“使用blueprint技能...”（不是 /blueprint，因为blueprint是一个技能，而不是一个命令）。
第四部分：优化提示词 — 快捷版
为经验丰富的ECC用户提供的紧凑版本。根据意图类型而变化：
| 意图 | 快捷模式 |
|---|---|
| 新功能 | /plan [feature]。/tdd 实现。/code-review。/verify。 |
| 缺陷修复 | /tdd — 为[bug]编写失败测试。修复至通过。/verify。 |
| 重构 | /refactor-clean [scope]。/code-review。/verify。 |
| 研究 | 对[topic]使用search-first技能。基于发现使用 /plan。 |
| 测试 | /tdd [module]。对关键流程使用 /e2e。/test-coverage。 |
| 评审 | /code-review。然后使用 security-reviewer 代理。 |
| 文档 | /update-docs。/update-codemaps。 |
| EPIC | 使用blueprint技能达到“[objective]”。使用 /verify 关卡分阶段执行。 |
第五部分：增强理由
| 增强 | 原因 |
|---|---|
| （添加了什么） | （为什么重要） |
页脚
不符合你的需求？告诉我需要调整什么，或者如果你希望执行而不是优化提示词，请发起正常的任务请求。
示例
触发示例
- “为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
- 认证：要求有效token，用户只能更新自己的资料
- 成功时返回200及更新后的用户
- 输入无效时返回400及验证错误
- 认证失败时返回401/403
- 遵循代码库中现有的API模式
工作流：
1. /plan 规划端点结构、中间件链和验证逻辑
2. /tdd — 为成功、验证失败、认证失败、未找到编写表格驱动测试
3. 遵循现有处理程序模式实现
4. /go-review
5. /verify — 运行完整测试套件，确认无回归
不要做：
- 修改现有端点
- 更改数据库架构（使用现有用户表）
- 先检查现有依赖，不要添加新依赖（使用search-first技能）
示例3：EPIC项目
用户输入：
Migrate our monolith to microservices
优化提示词（完整版）：
使用blueprint技能规划：“将单体应用迁移到微服务架构”
在开始执行前，在蓝图中回答以下问题：
1. 当前单体中有哪些领域边界？
2. 哪个服务应该最先提取（耦合度最低）？
3. 通信模式：REST API、gRPC还是事件驱动（Kafka/RabbitMQ）？
4. 数据库策略：初始共享数据库还是从一开始就按服务分配数据库？
5. 部署目标：Kubernetes、Docker Compose还是Serverless？
蓝图应产生如下阶段：
- 阶段1：识别服务边界并创建领域映射
- 阶段2：设置基础设施（API网关、服务网格、每个服务的CI/CD）
- 阶段3：提取第一个服务（绞杀者模式）
- 阶段4：使用集成测试验证，然后提取下一个服务
- 阶段N：弃用单体
每个阶段 = 1个PR，阶段间有 /verify 关卡。
使用 /save-session 在不同的阶段之间保存会话。