implement-idea

实现想法

将想法转化为已确认的迷你规格，然后在当前代码库中端到端交付。

门槛

• 从一份不超过 400 个字符（含空格）的临时迷你规格开始。只有在基于产物的质询完成后，才确认最终迷你规格；规格须涵盖用户可见的结果、范围／非目标，以及可测试的成功指标。
• 在作出决定前，阅读项目说明、愿景、贡献指南、就绪定义、完成定义、相关领域技能、实际项目命令、受影响的代码路径、测试和相关工作。
• 在提供选项前，始终执行并记录网络搜索，查找当前证据。优先采用官方来源和一手资料，并结合检出版本进行核对；仅将记忆中的链接作为搜索线索。如果搜索无法找到与决策相关的当前证据，则停止。
• 自动模式以外，必须具备已注册的 grilling 和 render-html 技能，以及 Python 3。若任何依赖不可用，则停止。使用实际的 grilling 决策循环；不得用临时问题仿造。
• 提出选项前，先从代码库、复现结果、项目约定、当前网络研究和共享的当前状态产物中整理出一份中立证据包。所有选项都必须基于同一证据包。
• 在评分前，根据已确认的结果、约束和成功指标，定义一套比较标准。为每个可行选项提供同等且与决策相关的验证：
  • 对于 UI／UX 差异，展示每种有实质差异的体验；
  • 对于架构或工作流差异，展示每种相关流程；
  • 对于交互密集型或技术性主张，如果静态证据无法判定，则使用可比较的短期原型或测量结果。 同等检查不要求投入相同的实现工作量。明确标注观察到的事实、拟议行为和仅用于原型的简化。
• 如果某个选项揭示了证据缺口，则对所有受影响的选项执行相同的相关检查。如果无法做到，则披露证据的不均衡，并在比较前降低置信度。
• 原型必须保留在本地且可随时丢弃；仅保留可供审查的截图和发现，并在质询结束时移除。不得部署或发布原型。只有获得用户明确批准，才可保留或推进原型；在其 git-workflow 同步门槛通过前，已批准的原型材料必须留在所选工作树之外。
• 根据已声明的比较标准，对 2 至 4 个真正不同且可行的选项进行比较，然后推荐一个，并等待用户选择，自动模式除外。提供简洁的证据摘要，列出最相关的来源链接、核对过的项目版本、评分和仍存的不确定性。
• 自动模式以外，在 grilling 决策循环之前，使用 render-html 将比较内容呈现为临时交互式影响报告。报告须包含共享结构化证据、已声明的比较标准、各选项的影响、优缺点、评分、不确定性和可复制的讨论提示。推荐意见放在结尾部分，且置于所有中立选项之后。
• 选项选定或进入自动模式后，即使遇到状态询问、诊断、修正和门槛未通过，也要持续推进已获授权的实现。只有在结果已完成、安全范围内的进展已被外部阻碍耗尽，或继续推进需要新的授权或解决实质性未决决策时，才交还控制权。已知的修复方案或建议不能作为终止条件。
• 对任何代码或测试变更，反复执行 /code-review fix-all 并针对已确认的迷你规格进行黑盒测试，直到二者在同一份未变更的实现上均通过；然后完成项目门槛并执行 /create-pr。

项目定义

将最近且适用的 DEFINITION_OF_READY.md 和 DEFINITION_OF_DONE.md 视为规范依据。如果经过实际查找后发现其中任一文件缺失， 请说明一次，并在计划和 PR 中体现这一缺口；仅使用工作流内置的检查以及仓库实际声明的命令。

自动模式

仅当原始提示中写有 automatic 或明确提出此要求时，才适用自动模式。该模式会跳过交互式 HTML 报告和 grilling 环节，但不会豁免任何其他关卡。共享资料包、预先声明的评分标准和等效检查全部完成前，不要选择任何选项。如果比较仍未完成，请报告这一缺口及其对置信度的影响，而不要将初始偏好视为已验证。任何重大的产品、架构、安全、范围或愿景决策都会禁用自动模式。

工作流

1. 在 400 个字符以内（包括空格）起草临时迷你规格。 将其视为起点，而不是已确认的约定。
2. 加载适用的项目约定和专门技能。
3. 找出已有的扩展点、可复用模式、同类功能、测试和架构约束。始终执行最新的网络搜索，并将搜索结果与当前检出内容核对。搜索问题跟踪器时，应查找该想法要实现的结果，而不只是其实现机制；已有问题包含先前的决策和验收标准。如果该想法已经存在，建议使用现有方案；如果只部分存在，则在其基础上扩展，而不是重复实现。
4. 构建中立的证据包和比较标准，推导出各个选项，并用同等且与决策相关的检查验证每个选项。先比较，再给出建议。
5. 在自动模式之外，创建一个位于工作树之外的临时目录。遵循 render-html 架构，并在该目录中呈现选项对比。打开报告进行审阅。如果无法在宿主环境内预览，则提供其绝对路径并继续。使用报告和共享证据，一次提出一个问题进行 grilling，确认最终迷你规格，然后在聊天中等待用户选择。用户明确要求保留时除外；选择完成后，删除临时报告及其输入文件。
6. 用户选择后，复用或创建专用分支/工作树，并在编辑前执行 git-workflow 远程默认分支同步关卡。
7. 在正确的层级实施最小且完整的更改。更新迷你规格和项目约定要求的测试及文档。
8. 对于 UI/UX 工作，呈现所有受影响的状态；采集可供审阅的前后对比证据；检查无障碍性、响应式行为、主题和设计系统一致性；将证据附加到 PR。
9. 开发过程中运行针对性检查。修复失败项，不要降低检查标准。
10. 根据成功标准、完成定义、项目惯例、分支差异和可复现行为，运行 /code-review fix-all。解决所有经验证且属于范围内的问题。遇到重大新决策或尚未解决的阻塞或重要问题时停止。如果无法使用 /code-review，则直接执行同等范围的审查和修复。
11. 如果可用，运行 /test-against-spec fix。否则直接执行同等的黑盒测试：使用已确认的迷你规格，不以源代码作为证明；如有可用的精确修订版本预览部署，则优先使用，否则退回本地环境。记录每项要求及其观察结果或限制。
12. 如果第 10 步或第 11 步更改了实现或报告了未完成的工作，则继续实施并从第 10 步重新开始。重复执行，直到代码审查和行为测试都在同一份未更改的实现上通过。用尽可用环境后，如果仍有必需行为未经验证，则停止并询问；除非用户明确接受该限制，或要求创建草稿 PR 以获取缺失的预览环境。
13. 运行适用的完成定义和仓库关卡。如果修复关卡失败项导致实现发生变化，则返回第 10 步。不要在行为测试步骤中重复执行范围广泛的关卡。
14. 使用 /create-pr，并传递当前迷你规格、已交付结果和观察到的完成证据，以供创建 PR。
15. 在任何更早的返回之前，执行当前实现的终止检查。若尚未满足任何终止条件，则继续执行下一个安全且已获授权的操作。