quick-implement

快速实现

范围门槛（编码前必须满足）

只有在以下所有条件均满足时，才将任务视为符合快速实现条件：

1. 需求明确

   • 预期行为清晰明确
   • 没有重大的产品或架构歧义

2. 改动范围小

   • 通常涉及少量文件（粗略指引：<= 5 个文件）
   • 不涉及大范围的跨模块重构

3. 架构风险低

   • 不需要基础性重新设计
   • 不涉及大量迁移工作
   • 不依赖分阶段发布

4. 验证直接

   • 可以通过有针对性的测试／检查快速验证
   • 不需要漫长的探索性调试

如果任何一项不满足，请转为 write-plan。

必须升级处理的条件

出现以下任何情况时，立即停止快速实现并转入规划：

• 需求存在歧义，需要做出设计决策
• 多个子系统之间出现意料之外的耦合
• 数据模型或架构有重大变更
• 涉及安全敏感或合规关键的变更
• 性能工作需要基准测试或设计权衡
• 重构范围超出原定的小范围
• 多次尝试失败，且无法明确根因
• 需要分阶段交付、功能标志或迁移策略

升级处理步骤：

1. 立即停止所有编码活动。
2. 输出以下确切消息："This change exceeds rapid-implementation safety limits. Recommend write-plan first to define phased execution and risk controls."
3. 通过 input/question 询问用户是否要发起移交至 write-plan 技能。

工作流程

步骤 1：分析并梳理上下文

1. 理解用户请求并定义验收标准。
2. 仅加载与请求相关的项目上下文：
   • 如果存在 docs/SUMMARY.md，先阅读。
   • 仅加载与任务相关的详细文档。
   • 实现约定优先参考 Code Standard 文档。
   • 如果文档与代码或用户意图冲突，请通过 input/question 询问后再进行大范围变更。
3. 只检查最低限度的必要代码路径。
4. 确认任务仍符合范围门槛。
5. 如果仍有歧义，先提出澄清问题，再开始编码。

步骤 2：实现

1. 以最小且正确的改动满足需求。
2. 复用现有模式和约定。
3. 避免与请求无关的顺手重构。
4. 在适用情况下，确保改动具备幂等性，并且可以安全重复运行。

步骤 3：验证

使用适当的执行工具，根据改动规模进行相称的验证：

1. 针对已修改行为的测试
2. 与改动区域相关的 lint/type 检查
3. 适用时进行构建或运行时验证

如果验证意外失败：

• 如果问题明确局限于局部，尝试有针对性的修复。
• 如果失败表明影响范围更广，建议升级至 write-plan。

步骤 4：完成

1. 总结改动内容及原因。
2. 列出已修改的文件。
3. 报告验证命令和结果。
4. 如果行为或领域规则发生细微变化，则更新文档。

执行边界

• 未经用户明确批准，不得扩大范围。
• 不要臆测未说明的行为；应先澄清。
• 风险增加时，不要强行完成；应尽早升级处理。
• 当复杂度或风险超出快速实现限制时，升级至 write-plan。
• 如果任务主要是调试问题，请使用 fix。

输出检查清单

最终回复前，确认：

• 已满足范围门槛
• 未引入隐藏的架构变更
• 已运行并报告验证
• 超出安全限制时已升级处理