提示词优化器 (Prompt Optimizer)

分析草稿提示词、提出批评、匹配 ECC 生态系统组件，并输出完整的优化提示词，供用户复制粘贴运行。

何时使用 (When to Use)

• 用户说“优化这个提示词”、“改进我的提示词”、“重写这个提示词”
• 用户说“帮我写一个更好的提示词用于……”
• 用户说“问 Claude Code 做……的最佳方式是什么”
• 用户说“优化prompt”、“改进prompt”、“怎么写prompt”、“帮我优化这个指令”
• 用户粘贴了一个草稿提示词并请求反馈或增强
• 用户说“我不知道怎么为这个写提示词”
• 用户说“我该怎么用 ECC 来做……”
• 用户显式调用 /prompt-optimize

不要使用 (Do Not Use When)

• 用户想要直接完成任务（直接执行即可）
• 用户说“优化代码”、“优化性能”、“optimize this code”、“optimize performance”——这些是重构任务，不是提示词优化
• 用户询问关于 ECC 配置的问题（请改用 configure-ecc）
• 用户想要技能清单（请改用 skill-stocktake）
• 用户说“直接做”或“just do it”

工作原理 (How It Works)

仅提供建议——不要执行用户的任务。

不要编写代码、创建文件、运行命令或采取任何实现行动。您的唯一输出是分析加上优化后的提示词。

如果用户说“直接做”、“just do it”或“不用优化，直接执行”，不要在此技能内切换到实现模式。告知用户此技能仅生成优化的提示词，并指示他们如果需要执行，请发起正常的任务请求。

按顺序运行以下 6 个阶段。使用下面的输出格式呈现结果。

分析流程 (Analysis Pipeline)

阶段 0：项目检测 (Phase 0: Project Detection)

在分析提示词之前，检测当前项目上下文：

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 / 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：意图检测 (Phase 1: Intent Detection)

将用户的任务分类为一个或多个类别：

阶段 2：范围评估 (Phase 2: Scope Assessment)

如果阶段 0 检测到了项目，使用代码库大小作为信号。否则，仅从提示词描述中估算，并将估算标记为不确定。

阶段 3：ECC 组件匹配 (Phase 3: ECC Component Matching)

将意图 + 范围 + 技术栈（来自阶段 0）映射到特定的 ECC 组件。

按意图类型 (By Intent Type)

按技术栈 (By Tech Stack)

阶段 4：缺失上下文检测 (Phase 4: Missing Context Detection)

扫描提示词，查找缺失的关键信息。检查每个项目，并标记阶段 0 是否自动检测到，或者用户是否需要提供：

• 技术栈 (Tech stack) — 阶段 0 检测到，还是用户必须指定？
• 目标范围 (Target scope) — 提及了文件、目录或模块？
• 验收标准 (Acceptance criteria) — 如何知道任务完成了？
• 错误处理 (Error handling) — 边缘情况和失败模式是否涵盖？
• 安全要求 (Security requirements) — 认证、输入验证、密钥？
• 测试期望 (Testing expectations) — 单元测试、集成测试、端到端测试？
• 性能约束 (Performance constraints) — 负载、延迟、资源限制？
• UI/UX 要求 (UI/UX requirements) — 设计规范、响应式、无障碍？（如果是前端）
• 数据库变更 (Database changes) — 模式、迁移、索引？（如果是数据层）
• 现有模式 (Existing patterns) — 要遵循的参考文件或约定？
• 范围边界 (Scope boundaries) — 什么不要做？

如果缺失 3 个及以上关键项，在生成优化提示词之前，向用户提出最多 3 个澄清性问题。然后将答案整合到优化后的提示词中。

阶段 5：工作流与模型推荐 (Phase 5: Workflow & Model Recommendation)

确定此提示词在开发生命周期中的位置：

研究 → 计划 → 实现（测试驱动开发） → 审查 → 验证 → 提交 (Research → Plan → Implement (TDD) → Review → Verify → Commit)

对于中高范围任务，始终以 /plan 开头。对于史诗范围任务，使用蓝图技能。

模型推荐 (Model recommendation)（包含在输出中）：

多提示词拆分 (Multi-prompt splitting)（适用于高/史诗范围任务）：

对于超出单个会话的任务，拆分为顺序提示词：

• 提示词 1：研究 + 计划（使用 search-first 技能，然后 /plan）
• 提示词 2-N：每个阶段实现一个提示词（每个以 /verify 结束）
• 最终提示词：集成测试 + 所有阶段的 /code-review
• 使用 /save-session 和 /resume-session 在会话之间保留上下文

输出格式 (Output Format)

使用此确切结构呈现您的分析。以与用户输入相同的语言回复。

第 1 部分：提示词诊断 (Section 1: Prompt Diagnosis)

优点 (Strengths): 列出原始提示词做得好的地方。

问题 (Issues):

需要澄清 (Needs Clarification): 编号列表，列出用户应回答的问题。如果阶段 0 自动检测到了答案，则直接说明而不是提问。

第 2 部分：推荐的 ECC 组件 (Section 2: Recommended ECC Components)

第 3 部分：优化提示词 — 完整版 (Section 3: Optimized Prompt — Full Version)

将完整的优化提示词放在一个代码块内。提示词必须是自包含的，可直接复制粘贴。包括：

• 带有上下文的清晰任务描述
• 技术栈（检测到或指定的）
• 在正确工作流阶段调用的 /command
• 验收标准
• 验证步骤
• 范围边界（什么不要做）

对于引用蓝图的项目，请写成：“使用 blueprint 技能来……”（而不是 /blueprint，因为 blueprint 是技能，不是命令）。

第 4 部分：优化提示词 — 快速版 (Section 4: Optimized Prompt — Quick Version)

为经验丰富的 ECC 用户准备的紧凑版本。按意图类型变化：

第 5 部分：增强理由 (Section 5: Enhancement Rationale)

页脚 (Footer)

不是您需要的？告诉我需要调整什么，或者如果您想要执行而不是优化提示词，请发起正常的任务请求。

示例 (Examples)

触发示例 (Trigger Examples)

• “Optimize this prompt for ECC”
• “Rewrite this prompt so Claude Code uses the right commands”
• “帮我优化这个指令”
• “How should I prompt ECC for this task?”

示例 1：模糊的中文提示词（检测到项目）(Example 1: Vague Chinese Prompt – Project Detected)

用户输入 (User input):

帮我写一个用户登录页面

阶段 0 检测到 (Phase 0 detects): package.json with Next.js 15, TypeScript, Tailwind CSS

优化后的提示词（完整版）(Optimized Prompt – Full):

使用项目现有技术栈（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：中等复杂度的英文提示词 (Example 2: Moderate English Prompt)

用户输入 (User input):

Add a REST API endpoint for user profile updates with validation

阶段 0 检测到 (Phase 0 detects): go.mod with Go 1.22, Chi router

优化后的提示词（完整版）(Optimized Prompt – Full):

为更新用户资料添加 REST API 端点（PATCH /api/users/:id）。

技术栈：Go 1.22 + Chi 路由器（从项目检测到）(Tech stack: Go 1.22 + Chi router - detected from project)

要求 (Requirements):
- PATCH /api/users/:id — 用户资料的部分更新 (partial update of user profile)
- 对字段进行输入验证：name, email, avatar_url, bio (Input validation for fields: name, email, avatar_url, bio)
- 认证 (Auth): 需要有效令牌，用户只能更新自己的资料 (require valid token, users can only update own profile)
- 成功时返回 200 并返回更新后的用户 (Return 200 with updated user on success)
- 输入无效时返回 400 并返回验证错误 (Return 400 with validation errors on invalid input)
- 认证失败时返回 401/403 (Return 401/403 for auth failures)
- 遵循代码库中现有的 API 模式 (Follow existing API patterns in the codebase)

工作流 (Workflow):
1. /plan 规划端点结构、中间件链和验证逻辑 (the endpoint structure, middleware chain, and validation logic)
2. /tdd — 为成功、验证失败、认证失败、未找到编写表驱动测试 (write table-driven tests for success, validation failure, auth failure, not-found)
3. 遵循现有处理程序模式实现 (Implement following existing handler patterns)
4. /go-review
5. /verify — 运行完整测试套件，确认无回归 (run full test suite, confirm no regressions)

不要做 (Do not):
- 修改现有端点 (Modify existing endpoints)
- 更改数据库模式（使用现有用户表）(Change the database schema - use existing user table)
- 不先检查现有依赖项就添加新依赖项（使用 search-first 技能）(Add new dependencies without checking existing ones first - use search-first skill)

示例 3：史诗级项目 (Example 3: EPIC Project)

用户输入 (User input):

Migrate our monolith to microservices

优化后的提示词（完整版）(Optimized Prompt – Full):

使用 blueprint 技能规划：“将单体架构迁移到微服务”
(Use the blueprint skill to plan: "Migrate monolith to microservices architecture")

在执行之前，在蓝图中回答以下问题：
(Before executing, answer these questions in the blueprint:)
1. 当前单体架构中存在哪些领域边界？(Which domain boundaries exist in the current monolith?)
2. 应该先提取哪个服务（耦合度最低）？(Which service should be extracted first - lowest coupling?)
3. 通信模式：REST API、gRPC 还是事件驱动（Kafka/RabbitMQ）？(Communication pattern: REST APIs, gRPC, or event-driven - Kafka/RabbitMQ?)
4. 数据库策略：一开始共享数据库还是每个服务独立数据库？(Database strategy: shared DB initially or database-per-service from start?)
5. 部署目标：Kubernetes、Docker Compose 还是无服务器？(Deployment target: Kubernetes, Docker Compose, or serverless?)

蓝图应产出类似以下阶段：
(The blueprint should produce phases like:)
- 阶段 1 (Phase 1): 识别服务边界并创建领域映射 (Identify service boundaries and create domain map)
- 阶段 2 (Phase 2): 设置基础设施（API 网关、服务网格、每个服务的 CI/CD）(Set up infrastructure - API gateway, service mesh, CI/CD per service)
- 阶段 3 (Phase 3): 提取第一个服务（绞杀者模式）(Extract first service - strangler fig pattern)
- 阶段 4 (Phase 4): 使用集成测试验证，然后提取下一个服务 (Verify with integration tests, then extract next service)
- 阶段 N (Phase N): 弃用单体架构 (Decommission monolith)

每个阶段 = 1 个拉取请求 (PR)，阶段之间使用 /verify 关卡。
(Each phase = 1 PR, with /verify gates between phases.)
在阶段之间使用 /save-session。使用 /resume-session 继续。
(Use /save-session between phases. Use /resume-session to continue.)
当依赖允许时，使用 git worktrees 进行并行服务提取。
(Use git worktrees for parallel service extraction when dependencies allow.)

推荐 (Recommended): Opus 4.6 用于蓝图规划 (for blueprint planning), Sonnet 4.6 用于阶段执行 (for phase execution).

相关组件 (Related Components)

\\