prompt-optimizer

提示词优化器

分析草稿提示词，进行评审，匹配到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：意图检测

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

类别	信号词	示例
新功能	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检测到项目，使用代码库大小作为信号。否则，仅根据提示词描述进行估计，并标记估计为不确定。

范围	启发式规则	编排方式
微小	单个文件，< 50行	直接执行
低	单个组件或模块	单个命令或技能
中	多个组件，同一领域	命令链 + /verify
高	跨领域，5个以上文件	先 /plan，然后分阶段执行
史诗	多会话、多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
设计（中-高）	/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已检测到，还是用户必须指定？
• [ ] 目标范围 —— 是否提到了文件、目录或模块？
• [ ] 验收标准 —— 如何知道任务完成？
• [ ] 错误处理 —— 是否涉及边界情况和失败模式？
• [ ] 安全要求 —— 认证、输入验证、密钥？
• [ ] 测试期望 —— 单元测试、集成测试、端到端测试？
• [ ] 性能约束 —— 负载、延迟、资源限制？
• [ ] UI/UX要求 —— 设计规范、响应式、可访问性？（如果是前端）
• [ ] 数据库变更 —— 模式、迁移、索引？（如果是数据层）
• [ ] 现有模式 —— 需要参考的文件或约定？
• [ ] 范围边界 —— 哪些不要做？

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

阶段5：工作流与模型推荐

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

调研 → 规划 → 实施（TDD）→ 审查 → 验证 → 提交

对于中+范围的任务，始终以 /plan 开始。对于史诗范围的任务，使用 blueprint 技能。

模型推荐（包含在输出中）：

范围	推荐模型	理由
微小-低	Sonnet 4.6	快速、成本效益高，适合简单任务
中	Sonnet 4.6	标准工作的最佳编码模型
高	Sonnet 4.6（主要）+ Opus 4.6（规划）	Opus 用于架构，Sonnet 用于实施
史诗	Opus 4.6（蓝图）+ Sonnet 4.6（执行）	多会话规划的深度推理

多提示词拆分（针对高/史诗范围）：

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

• 提示词1：调研 + 规划（使用 search-first 技能，然后 /plan）
• 提示词2-N：每个提示词实施一个阶段（每个以 /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 [feature]. /tdd to implement. /code-review. /verify.
错误修复	/tdd — write failing test for [bug]. Fix to green. /verify.
重构	/refactor-clean [scope]. /code-review. /verify.
调研	Use search-first skill for [topic]. /plan based on findings.
测试	/tdd [module]. /e2e for critical flows. /test-coverage.
审查	/code-review. Then use security-reviewer agent.
文档	/update-docs. /update-codemaps.
史诗	Use blueprint skill for "[objective]". Execute phases with /verify gates.

第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 路由器

优化提示词（完整版）：

Add a REST API endpoint for user profile updates (PATCH /api/users/:id).

Tech stack: Go 1.22 + Chi router (detected from project)

Requirements:
- PATCH /api/users/:id — partial update of user profile
- Input validation for fields: name, email, avatar_url, bio
- Auth: require valid token, users can only update own profile
- Return 200 with updated user on success
- Return 400 with validation errors on invalid input
- Return 401/403 for auth failures
- 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)
- Add new dependencies without checking existing ones first (use search-first skill)

示例3：史诗级项目

用户输入：

Migrate our monolith to microservices

优化提示词（完整版）：

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. Communication pattern: REST APIs, gRPC, or event-driven (Kafka/RabbitMQ)?
4. Database strategy: shared DB initially or database-per-service from start?
5. Deployment target: Kubernetes, Docker Compose, or serverless?

The blueprint should produce phases like:
- Phase 1: Identify service boundaries and create domain map
- Phase 2: Set up infrastructure (API gateway, service mesh, CI/CD per service)
- Phase 3: Extract first service (strangler fig pattern)
- Phase 4: Verify with integration tests, then extract next service
- Phase N: Decommission monolith

Each phase = 1 PR, with /verify gates between phases.
Use /save-session between phases. Use /resume-session to continue.
Use git worktrees for parallel service extraction when dependencies allow.

Recommended: Opus 4.6 for blueprint planning, Sonnet 4.6 for phase execution.

---

相关组件

组件	何时引用
configure-ecc	用户尚未设置ECC
skill-stocktake	审计已安装的组件（替代硬编码目录）
search-first	优化提示词中的调研阶段
blueprint	史诗级优化提示词（作为技能调用，非命令）
strategic-compact	长会话上下文管理
cost-aware-llm-pipeline	Token优化建议