task-execution-framework

---
name: task-execution-framework
description: >
  中大型任务执行纪律：先定义"做成什么样"，再找参照，再规划，最后动手，做完对照规划验收。
  含任务分级（S/M/L/XL）、8 步流程、G0/G1/G2 闸门、任务卡/一页规划/验收矩阵、变更三级、交付前 12 项。
  Use when 任务超过 30 分钟、跨多章节/多文件/多系统、涉及视觉/数据/发布；或用户说"做看板/报告/网站/方案"、
  "改版"、"重做"、"整理成体系"；或发现自己反复返工、被连续否决。
  Do NOT use when 单点查询、一句话改写、简单命令、纯事实问答。
allowed-tools: Read, Write, Edit, Glob, Grep, Bash, WebSearch, WebFetch, AskUserQuestion, present_files
agent_created: true
---

# 中大型任务执行框架

**一句话**：先定义"做成什么样"，再找"别人怎么做"，再规划"我们怎么做"，最后才动手；做完**对照规划验收**，不对照感觉验收。

> 路由层。全文（每步细节、模板全文、反例审计）在 `references/00_框架全文.md`。

## 读取契约（硬性）

| 何时 | 必读 | 不读的后果 |
|---|---|---|
| 判为 M 级及以上，动手前 | `references/00_框架全文.md` 第三、四章 | 会跳闸门、漏验收矩阵 |
| 判为 XL（多 Agent / 5 天+） | 另加载 `massive-task-orchestrator` | 缺 DAG/波次，多 Agent 互相踩 |
| 需要模板 | 全文 4.1/4.2/4.3 | 手搓字段会漏项 |

**未读即执行 = 流程违规**，任务卡备注记一笔。

## 一、分级（先判级再定流程重量）

| 级 | 判断 | 做法 |
|---|---|---|
| S | ≤30 分钟、单文件、无歧义 | 直接做 + 交付前自检 |
| M | 半天—2 天、多文件、少量歧义 | 8 步，内部过 G0/G1 |
| L | 2—5 天、跨系统、视觉/数据/发布风险 | 8 步 + 用户确认 G0/G1 |
| XL | 5 天+、多角色/多 Agent | 8 步 + 编排 + 预算与检查点 |

**判据**：做错了是"改几行"还是"整版重做"？后者至少 L。

## 二、七条铁律

1. **整体先于局部**——先定结构/数据/视觉系统，再改单个模块。
2. **参照先于设计**——配色版式先看 2—3 个外部参照，写清借什么/不借什么。
3. **规划先于执行**——没有一页规划不许动手。
4. **证据先于结论**——"能跑/我觉得"不算；截图、运行结果、对账才算。
5. **单一事实来源**——成品由源文件生成不手改；文档是唯一事实源，技能只做路由。
6. **变更分级**——局部补、结构回规划、前提重写任务卡。**不用局部补丁修前提错误。**
7. **上下文是预算**——技能薄、文档按需读；长任务写 `task_notes.md`；校验拆子 Agent 只回摘要。

## 三、八步骨架

| # | 步骤 | 产出 | 闸门 |
|---|---|---|---|
| 0 | 受理与分级 | 级别 | — |
| 1 | 拆解与确认 | **任务卡** | **G0** |
| 2 | 澄清（只问改变方案的，3—5 个） | 已问/假设清单 | 用户确认 |
| 3 | 外部检索（事实/设计/执行三线） | **参照卡** 2—3 个 | — |
| 4 | 整体规划（八块一页） | **一页规划 + 验收矩阵** | **G1** |
| 5 | 细节设计 | 执行清单、规格 | — |
| 6 | 执行（先骨架后血肉，一次只动一层） | 可运行产物 | — |
| 7 | 对照校验（完整性 + 一致性） | 验收矩阵结果 | **G2** |
| 8 | 调优与交付（L1 补/L2 回规划/L3 重写卡） | 终版 + 变更记录 + 交付说明 | 通过 |

**闸门判据**：G0＝能用一句话回答"什么叫做完了"；G1＝能说清"整体长什么样"；G2＝逐项有证据。

## 四、三工件（模板见全文第四章）

- **任务卡**：目标 / 交付物 / 读者与载体 / 范围（含明确不做）/ 约束 / 验收 3—5 条 / 未知 Top3 / 级别
- **一页规划**：方向 / 结构 / 数据逻辑 / 视觉交互 / 步骤 / 风险 / 验收矩阵 / 明确不做
- **验收矩阵**：规划项 → 证据 → 方法 → 通过与否

## 五、变更三级

**L1 局部**（错字/单卡溢出）→ 直接补，记录；**L2 结构**（章节顺序/版式/口径）→ 回第 4 步，全量重验；**L3 前提**（读者/载体/目标变了）→ 停，重写任务卡。
自检：这次改动是在修 L1，还是在给 L3 打补丁？

## 六、交付前 12 项

验收标准全满足 / 规划每项都在产物里 / 整体一致性过 / 数据口径一致 / 交互逐项点过（含空态错误态）/ 构建无错无溢出 / 目标载体真机看过 / 整页联系表+关键区块截图 / 独立复核 / 版本变更记录齐 / 说明文档同步 / 外部动作（发布覆盖删除）已确认且线上复验。

## 七、gotchas（都是真踩过的）

1. **判据脚本先自检再信**：我写过检查脚本，首次跑出 136 个红项，其中大半是脚本自身 bug（标题格式匹配不上、把子目录当空间）。**用已知正确的样本先喂它，确认不误报，再拿它的结论做决策。**
2. **物理移动不等于搬走**：有外部进程持有路径引用时（`.genie` / `applications.yaml` 的 `localDir`、任务 cwd、junction），目录移走后会被**原地重建**。搬前先找引用源，改引用，再移。
3. **改结构名会打断已修好的路径**：先定终结构再修路径；反序要修两遍（本项目一次改名连带 107 处重做）。
4. **增量同步会覆盖"修复过"的文件**：内容修复让文件大小变化，robocopy 按大小判定就会用旧版覆盖。同步后必须重跑修复并复验。
5. **不要用"我觉得可以了"收口**：本项目求职手册连续被否决 3 次，都是因为拿参数当证据、只截局部图。
6. **模板不能替代判断**：八步是骨架，不是保证；每一步的"够不够"仍要自己判。

## 八、与相邻 skill 的关系

- `massive-task-orchestrator`：XL 专项（DAG/波次），判 XL 时叠加。
- 业务 skill（illustrated-story / deep-research-report / frontend-dev 等）：**它们管"这件事怎么做"，本框架管"怎么保证做对"**。

• SKILL.md 6 KB
• references/00_框架全文.md 15 KB