prompt-optimizer

Topics in the source

• Prompt 优化器
• 何时使用
• 不要用于
• 工作原理
• 分析流程
• 阶段 0：项目检测
• 阶段 1：意图检测
• 阶段 2：范围评估

分析一个草稿提示，对其进行评估，匹配到 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 阶段流程。使用下面的输出格式呈现结果。 在分析提示之前，检测当前项目上下文： 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 标记“技术栈未知”。 将用户的任务分类为一个或多个类别： | 类别 | 信号词 | 示例 | |----------|-----

This is an excerpt. Refer to the complete source and its current requirements.