用途
Brainstorm Prompt Optimizer 用于把原始的想法转化为经过优化的提示词，作为头脑风暴工作流（/specs.brainstorm）的输入。其目标是在想法被传入 /specs.brainstorm 时，能够产出更好的功能规格，遵循 EARS 语法、正确的验收标准分类，以及完整的 Non-Goals/Negative Requirements 章节。
何时使用
- 用户希望在运行 /specs.brainstorm 之前优化一个想法。
- 用户说“prepare this idea for brainstorming”“enhance for brainstorm”“make this ready for brainstorm”“imposta per brainstorm”“prepara idea per brainstorm”等。
- 用户提供一个简单想法，希望将其结构化以获得更好的头脑风暴结果。
何时不要使用
- 用户想要代码或性能优化（应使用相应技能）。
- 用户想要通用提示词工程（应使用 prompt-engineering 技能）。
- 用户想要分析已有提示词。
- 用户要求直接执行任务。
- 用户想要修复缺陷或修改既有行为（路由到 specs.change-spec）。
工作方式
该技能仅输出优化后的提示词——不输出分析、不输出报告、不输出建议。其工作流把原始想法转化为结构化提示词，使其与 /specs.brainstorm 配合时能产出更好的功能规格。
工作流（阶段）
- 检测项目上下文：检查项目文件以理解环境，包括 CLAUDE.md（项目约定）、docs/specs/architecture.md（既有架构约束）、docs/specs/ontology.md（既有领域术语）；并检测技术栈，如 package.json（Node.js/TypeScript/React）、pom.xml / build.gradle（Java/Spring Boot）、requirements.txt / pyproject.toml（Python）。
- 分析想法：解析原始想法以识别核心动作、目标领域、隐式范围、用户视角、业务价值。
- 识别范围大小：估算复杂度以帮助 /specs.brainstorm，分为 Small（单一用户故事、1-3 个实体、简单流程，约 3-8 个任务）、Medium（2-4 个用户故事、4-8 个实体，约 8-15 个任务）、Large（5+ 用户故事、9+ 实体，可能需要拆分并提醒用户）。
- 结构化优化提示词：按照与 /specs.brainstorm 模板对齐的组件构建结构化提示词，包括 Problem Statement、Core Feature、Target Users、User Flows、Data Requirements、Success Criteria、Non-Goals、Negative Requirements，以及最多 3 条 [NEEDS CLARIFICATION]。
- 输出优化提示词：以带 optimized-prompt 标签的围栏代码块呈现完整优化提示词。
结构化提示词的关键规则
- 验收标准必须打标签：[IMP]（需要新代码、配置或显式行为，会生成任务）、[SEF]（[IMP] 标准的自然自动结果，不生成任务，在 e2e 中验证）、[EXT]（由外部工具或用户观察验证，不生成任务，作为 e2e 检查点）。
- 60% 规则：至少 60% 的标准应为 [IMP]。
- EARS 语法形式包括 Event-driven、State-driven、Generic、Feature、Negative；强制关键词为 SHALL、WILL、MAY；禁止使用的词包括 robust、intuitive、fast、scalable、efficient、user-friendly。
提供的模板分类
技能给出了按类别划分的提示词模板：认证与用户管理、API 与后端功能、UI 与前端功能、数据与处理功能。
示例
文档包含三个示例：简单想法（Add user authentication）转为优化提示词、模糊想法（Better search for products）转为结构化提示词、技术性想法（Implement Redis caching for API responses）转为功能性提示词。
与头脑风暴的集成
优化后的提示词应直接用于 /specs.brainstorm（复制优化后的提示词即可）。
限制
- 该技能仅输出优化后的提示词，不提供分析、报告或建议。
- 不用于代码或性能优化、通用提示词工程、分析已有提示词、直接执行任务，也不用于修复缺陷或修改既有行为（后者路由至 specs.change-spec）。