Quick Execution

用途

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

准入条件

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

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

默认做法

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

1. 快速评估（30 秒）：

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

1. 直接执行：

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

1. 内联验证：

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

1. 提交与记录：

• 使用 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 中可见。