Quick Execution

用途

• 把"所有任务都走完整链路"改成"小任务快速通道 + 质量底线"。
• 适合 bug 修复、文档更新、配置变更、小型重构等边界清晰的任务。
• 跳过 /team-intake → /team-plan → /handoff 的完整链路，直接进入执行。

准入条件

以下条件全部满足时可使用快速模式：

1. 范围明确：改动范围可在一句话内说清楚。
2. 影响面小：预计改动不超过 3 个文件或 100 行代码。
3. 无跨团队依赖：不需要其他角色的输入或确认。
4. 可回滚：改动可以独立回滚，不影响其他正在进行的工作。
5. 风险低：不涉及鉴权、支付、数据迁移、API 契约变更等高风险领域。

默认做法

1. 一句话目标：用一句话描述要做什么以及为什么。

2. 快速评估（30 秒）：

   • 确认准入条件全部满足
   • 若任一不满足，回退到标准 /team-intake 流程
   • 边界情况由 tech-lead 裁定

3. 直接执行：

   • 跳过 intake、plan、handoff
   • 直接编写代码并自测
   • 遵循现有编码风格和测试约定

4. 内联验证：

   • 改动完成后立即运行相关测试
   • 若存在 lint/type-check/build，确保全部通过
   • 快速 diff review：确认没有意外改动

5. 提交与记录：

   • 使用 conventional commit 格式
   • commit message 中注明 [quick] 标记
   • 若改动最终超出预期范围，在 commit 中说明并考虑补 handoff

自动降级机制

执行过程中出现以下情况时，自动降级到标准流程：

• 发现改动范围超出预期（>5 个文件或 >200 行）
• 发现需要其他角色的输入或确认
• 发现涉及高风险领域
• 遇到需要讨论的灰色地带
• 测试失败且根因不在预期范围内

降级时输出：

⚠️ 快速模式降级：{原因}
建议切换到 /team-intake 或 /team-plan
当前已完成：{已做内容摘要}

触发信号

• 用户说"快速修一下"、"小改动"、"顺手改掉"、"quick fix"。
• 改动明显是 bug 修复、typo 修正、配置调整。
• 任务来自已有 backlog 且标记为低优先级/低风险。

配套约束

1. 质量底线不降：跳过流程不等于跳过测试和 review。
2. 不滥用：若一天内超过 3 个任务走快速模式，建议 tech-lead 评估是否有系统性问题。
3. 可追溯：[quick] 标记的 commit 可以在需要时被批量审计。
4. 不累积：快速模式产生的技术债务不能以"等以后再说"搁置，需要在 backlog 中可见。