orch-plan

Files (1)

• SKILL.md

SKILL.md (first lines)

# /orch-plan — 编排计划(方向 + 工程双层)

**存在理由**:20260901,owner 打回一版编排计划,原话——「有方向计划了,但是没有工程计划,没有具体的任务安排和验收清单标准……应该是我在任何一个 session 加载都能马上按照计划内的具体任务和台账去干活。你这个太初级了。」重做的 v2 三件套(总览 HTML + 事实索引 md + 工单集 md,见 §已知参照)被认可。本 skill 把 owner 这次亲口验收过的形态固化成可复用规程,今后任何项目出「编排计划」不许再退化成只有方向的初级版。

## 0 · 使用时机

- owner 或项目制度要求产出「编排计划」「排期」「任务安排」「工单包」类交付物时。
- 已出的计划被打回、理由类似"看不出具体怎么干/验收标准是什么/换个人接得上吗"时,直接重做,不必等第二次打回。
- 不适用:单张任务卡、一次性小修复、纯调研报告——那些不需要双层结构,硬套等于过度工程。判断线同 `feature-dev` 的规模定档:改动面单一、无需多执行体协同、无跨阶段依赖图,就不必发本 skill,直接干或写一张卡即可。

## 1 · 双层结构(合格判据的核心,一条不能丢)

编排计划必须同时有两层,**只有一层=不合格,直接打回自己重做,不要呈给 owner**:

1. **方向层**:目标态是什么、为什么现在做、分几个大阶段、大阶段之间的因果关系。这层回答"我们要去哪、为什么"。
2. **工程层**:方向层拆到底之后,逐条落地的工单——每条工单必须自带**执行体/依赖/输入/步骤/产出/可判定验收标准**六要素(§3 给固定模板)。这层回答"具体谁、干什么、怎么算干完"。

自检一句话:拿掉方向层,工程层能不能独立执行?拿掉工程层,方向层能不能指导任何一个具体动作?两者都答"不能"才算双层齐全。只写方向层=书生做的规划,owner 原话定性为"太初级"。

## 2 · 三件套产出规程

owner 钦定 HTML 为总览与确认层的格式,但**允许 HTML 里套 md 索引避免 HTML 臃肿**——所以标准产出永远是三个文件,分工固定,禁止把三件套压成一件套或反过来拆成四件以上:

| 文件 | 角色 | 内容 |
|---|---|---|
| `<前缀>-编排计划-<主题>-<日期>.html` | **总览与确认层**(owner 第一眼读的) | 老板版首节 + 任务总表 + 依赖图 + 逐站验收门 + 候 owner 清单;链接指向另两个 md |
| `<前缀>-关键事实索引-<日期>.md` | **事实层**(冷启动第一份读物) | 版本/环境/账号/权威规范文件路径/已定谳件清单/会话表/纪律判据——任何新 session 不用问人就能补齐上下文 |
| `<前缀>-工单集-<范围>-<日期>.md` | **执行层**(真正干活时打开的) | 逐任务工单,自包含六要素,禁止"同上"式偷懒到看不出边界(可以写"步骤/产出/验收同模板"但每条的输入与产出文件名必须唯一列出) |

产出顺序:先事实索引(把散落的事实收拢),再工单集(把方向拆成工程),最后 HTML(汇总前两者,写老板版首节)。反过来先写 HTML 空表格再回填,容易漏工程细节。

## 3 · 冷启动自包含判准(验收计划是否合格的唯一硬标准)

owner 验收编排计划只问一件事:**任何一个不带任何背景的的新 session,只读三件套,能不能马上按工单去干活,不用回来问我们、也不用现挖代码史。** 逐条自检:

- 工单里的路径是不是绝对路径、文件是否真实存在(不是"应该在"那种猜测路径)?
- 依赖的分支/tag/commit hash 是否写死(不是"当前分支",因为分支会漂)?
- 权限/账号/环境地址是否在事实索引里给全,而不是要求读者去问 owner 才知道?
- 每条工单的"产出"文件名是否和"验收"里引用的文件名对得上?
- 每条工单是否写了模型档与预算档?复核是否按「只改测试 / 读侧一两行 → 主编排亲核;产品码或库函数 → 派复核员(八项清单、四小时封顶)」分级?

任一条答不上=不合格,回 §1 补,不许呈给 owner。

## 4 · 「第一节 · 总结说人话版」铁律(HTML 第一节;20260902 owner 打回后升级,标题字段名固定)

HTML 的第一个 `<h2>` 固定命名为**「第一节 · 总结说人话版」**(不再叫"老板版"),内容必须完整遵守 `/human-explain` skill 规范(禁 AI 腔与管理黑话:本质上/闭环/链路/落地/对齐/抓手…全禁;禁比喻替代直说;结论先行;术语先说意义再给名字),面向不想读代号的决策者:

- 用"以前……以后……"句式讲清楚现状与变化,不许开局就抛任务 ID、SHA、文件名。
- 明确写清楚"要签的字"是什么——一句话结论 + 需要 owner 做的具体动作(常见形态:回复"确认开工"、点一个启动器、二选一)。
- 技术正文(任务总表/依赖图/验收门)一律排在总结之后,零代号裸奔在首节出现。
- **提到任何编号/术语/文件名之前,先用一句业务语言说清它对生意/交付意味着什么**;首节里能不出现编号就不出现。
- 参照:v2 HTML `.boss` 区块的两段式写法——第一段讲结论,第二段讲今天要并行做的几条线,`.sign` 区块单独列候签动作。

## 5 · 任务总表 + 工单集模板

任务总表(HTML 第二节)每行至少含:ID / 任务名 / 执行体 / 依赖 / 产出 / 验收要点一句话(全文见工单集)。工单集里每条工单套用固定六要素模板(参照 v2 T0-T14):

```markdown
## T<n> · <任务名>
- **执行体**:<谁做——具体会话名/子代理类型/候 owner 亲执,禁写"某人"这种占位>
- **模型档**:<sonnet·high / opus5·high(涉及前端) / sonnet·max 复核 / opus5·max 复核(前端或跨层) / haiku·low 机械;空着不许派;禁子代理继承主会话模型> + **预算档**:<小 / 中 / 大>
- **依赖**:<前置任务 ID 或"无,即刻";依赖必须是真依赖,不是排期习惯>
- **输入**:<读什么——绝对路径/tag/commit/规范文件,全部可定位>
- **步骤**:<编号列表,做到"读一眼就知道从哪下手"的颗粒度>
- **产出**:<文件名/commit/台账行,唯一列出,不与其他任务共用同一文件名却含义不同>
- **验收**:<可判定标准,§6 硬性要求>
- **五门格**(发版/修复批次类计划必带,见 /5gate):①任务门= ②合流门= ③盲测门= ④发车门= ⑤真人门= <每格只许填证据文件绝对路径;空=未过;写「已完成」三个字=无效>
```

发版/修复批次类计划的工单集**就是本车的五门台账**(不另开账本):每张卡的五门格随门次推进由主编排回填证据路径;项目 CLAUDE.md 所指「现役五门台账」即最新一份工单集。

执行体点名纪律:禁止写"某个 agent"或"待定"——写不出真实执行体,这条工单还不能进计划,先解决"谁来做"再落盘(同 compass skill 的活性审计纪律:开放目标必须有叫醒机制,工单必须有执行体)。

## 6 · 依赖图(事件判定式,禁日历日)

只画真依赖:A 的产出是 B 的输入,或 A/B 改动面重叠 → B 必须等 A;其余一律并发,不得因为"看起来该按顺序"就串行。依赖图用文字邻接表或 ASCII 箭头即可,不需要甘特图。每条计划必须标出**最大并行度**(同一时刻最多几条线同飞),这是 owner 判断资源是否闲置的直接依据。

反例(v2 认可版的正例可直接参照其"第三节·依赖图"写法):
```
T0(即刻,候<某启动条件>)──────────────── 独立
确认开工 ──┬── T1..T5(五线并行)──→ T6 汇总
           └── T7 合流 ──→ T8 ──→ …
最大并行:确认开工后 N 线同飞
```

## 7 · 验收标准必须可判定

每条工单、每一站验收门,标准必须是**机器能判定(数字/断言/退出码)或可亲验(逐图对照、逐项勾选)**,禁止出现"做完了""基本没问题"这类无法判定真假的句子。可判定标准的形态举例:

- 数字类:`覆盖率 100%`、`全量测试对基线零新增红`、`七门禁 exit=0`、`活会话数=0`。
- 构建物来源/溯源类:`gitTip==tag SHA`、`构建前后 git status --git status 干净 为空`、`ls-remote 三等`。
- 亲验类:`五组场景逐图亲验全绿,图纸 vs 真机并排`、`任何红=拦停回修`。
- 模糊条款处置:调研/对表类工单遇到规范条款本身写得模糊,不许自行解释拍板,原文摘录挂候 owner 清单,不算工单失败。

## 8 · 候 owner 清单格式(20260902 owner 打回后升级:必须说人话,背景与建议都要展开)

**打回原话**:「对于背景和问题的描述太过简单大量缩写让人看不懂,必须 elaborate,建议也必须说人话…必须把背景解释充分 给的建议也要解释充分 用业务语言和自然语言说清楚」。据此每一项固定三列,各列有硬性内容要求:

- **#**:序号。
- **背景与问题(展开讲)**:用业务语言完整交代——①现场发生了什么/谁撞到了什么;②为什么这是个需要拍板的问题(对钱/客户/门店操作的影响);③系统现状。**禁止裸奔缩写与内部编号**(条目号/工单号/单据号这类,要么不用,要么先用一句人话解释它指什么);一项写不满两三句完整中文=背景没交代够,重写。
- **你要做的(选项+推荐+理由+代价)**:给出可选项与明确推荐,并用自然语言说清**为什么推荐这个**、**选它要付出什么代价/承担什么后果**。禁止只丢一个"推荐:甲案"就完事;开放式提问仍然禁止。

写完自检:把这张表单独拿给一个没参与过项目的人读,每一项他能否复述出"出了什么事、要我选什么、选了会怎样"?答不上=重写。全表内容同受 `/human-explain` 禁语清单约束。
有明确默认值的可逆项不进此表,按默认值先行并在工单里注明"按默认值 X 假设";只有真正需要人拍板或不可逆的事项才进候 owner 清单。

## 9 · HTML 骨架模板(含 CSS,可直接复制)

视觉沿用你团队的设计规范(示例口径:白底 · 近黑 #111 主色 · 全站一种边框灰 · 默认态零阴影 · 色彩只出现在状态点/pill · light-only · 零 emoji)。下方模板是 owner 已验收版本的骨架,新项目如有自己的 `design-tokens.css`,优先把颜色值换成项目 token,结构与类名可原样复用;没有独立 token 体系的项目直接照抄这份内联 CSS 即可过审:

```html
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8">
<title>编排计划 · <主题>(工程版)</title>
<style>
  body { font-family: -apple-system, "PingFang SC", "Microsoft YaHei", sans-serif; color: #111; background: #fff; max-width: 960px; margin: 40px auto; padding: 0 24px; line-height: 1.7; }
  h1 { font-size: 25px; border-bottom: 2px solid #111; padding-bottom: 10px; }
  h2 { font-size: 19px; margin-top: 34px; border-left: 4px solid #111; padding-left: 10px; }

From 0fuk/OpenACCP, MIT.

More from 0fuk/OpenACCP