everything-claude-code/docs/zh-CN/skills/prompt-optimizer/SKILL.md

name: prompt-optimizer description: 分析原始提示，识别意图和差距，匹配ECC组件（技能/命令/代理/钩子），并输出一个可直接粘贴的优化提示。仅提供咨询角色——绝不自行执行任务。触发时机：当用户说“优化提示”、“改进我的提示”、“如何编写提示”、“帮我优化这个指令”或明确要求提高提示质量时。中文等效表达同样触发：“优化prompt”、“改进prompt”、“怎么写prompt”、“帮我优化这个指令”。不触发时机：当用户希望直接执行任务，或说“直接做”时。不触发时机：当用户说“优化代码”、“优化性能”、“optimize performance”、“optimize this code”时——这些是重构/性能优化任务，而非提示优化。origin: community metadata: author: YannJY02 version: "1.0.0"

Prompt 优化器

分析一个草稿提示，对其进行评估，匹配到 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 / 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, 创建, 实现, 添加	"Build a login page"
错误修复	fix, broken, not working, error, 修复, 报错	"Fix the auth flow"
重构	refactor, clean up, restructure, 重构, 整理	"Refactor the API layer"
研究	how to, what is, explore, investigate, 怎么, 如何	"How to add SSO"
测试	test, coverage, verify, 测试, 覆盖率	"Add tests for the cart"
审查	review, audit, check, 审查, 检查	"Review my PR"
文档	document, update docs, 文档	"Update the API docs"
基础设施	deploy, CI, docker, database, 部署, 数据库	"Set up CI/CD pipeline"
设计	design, architecture, plan, 设计, 架构	"Design the data model"

阶段 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
错误修复	/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	code-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：工作流和模型推荐

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

Research → Plan → Implement (TDD) → Review → Verify → Commit

对于中等级别及以上的任务，始终以 /plan 开始。对于史诗级任务，使用蓝图技能。

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

范围	推荐模型	理由
微小-低	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，因为蓝图是技能，不是命令）。

第 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 部分：改进理由

改进	理由
(添加了什么)	(为什么重要)

页脚

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

---

示例

触发示例

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

示例 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 router

优化提示（完整）：

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 优化推荐