Quick Execution
用途
- 把"所有任务都走完整链路"改成"小任务快速通道 + 质量底线"。
- 适合 bug 修复、文档更新、配置变更、小型重构等边界清晰的任务。
- 跳过
/team-intake→/team-plan→/handoff的完整链路,直接进入执行。
准入条件
以下条件全部满足时可使用快速模式:
- 范围明确:改动范围可在一句话内说清楚。
- 影响面小:预计改动不超过 3 个文件或 100 行代码。
- 无跨团队依赖:不需要其他角色的输入或确认。
- 可回滚:改动可以独立回滚,不影响其他正在进行的工作。
- 风险低:不涉及鉴权、支付、数据迁移、API 契约变更等高风险领域。
默认做法
一句话目标:用一句话描述要做什么以及为什么。
快速评估(30 秒):
- 确认准入条件全部满足
- 若任一不满足,回退到标准
/team-intake流程 - 边界情况由
tech-lead裁定
直接执行:
- 跳过 intake、plan、handoff
- 直接编写代码并自测
- 遵循现有编码风格和测试约定
内联验证:
- 改动完成后立即运行相关测试
- 若存在 lint/type-check/build,确保全部通过
- 快速 diff review:确认没有意外改动
提交与记录:
- 使用 conventional commit 格式
- commit message 中注明
[quick]标记 - 若改动最终超出预期范围,在 commit 中说明并考虑补 handoff
自动降级机制
执行过程中出现以下情况时,自动降级到标准流程:
- 发现改动范围超出预期(>5 个文件或 >200 行)
- 发现需要其他角色的输入或确认
- 发现涉及高风险领域
- 遇到需要讨论的灰色地带
- 测试失败且根因不在预期范围内
降级时输出:
⚠️ 快速模式降级:{原因}
建议切换到 /team-intake 或 /team-plan
当前已完成:{已做内容摘要}
触发信号
- 用户说"快速修一下"、"小改动"、"顺手改掉"、"quick fix"。
- 改动明显是 bug 修复、typo 修正、配置调整。
- 任务来自已有 backlog 且标记为低优先级/低风险。
配套约束
- 质量底线不降:跳过流程不等于跳过测试和 review。
- 不滥用:若一天内超过 3 个任务走快速模式,建议
tech-lead评估是否有系统性问题。 - 可追溯:
[quick]标记的 commit 可以在需要时被批量审计。 - 不累积:快速模式产生的技术债务不能以"等以后再说"搁置,需要在 backlog 中可见。
Source: hashgraph-online/awesome-codex-plugins → plugins/Colin4k1024/tsp/skills/quick-execution/SKILL.md