Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 12 additions & 16 deletions .claude/skills/pm-dispatch/SKILL.md
Original file line numberDiff line numberDiff line change
Expand Up@@ -73,7 +73,7 @@ references);② 创建后手动 fire 一轮烟测,判据取**GitHub 上的产出
| open + 队列标签 + **无 assignee** | 可派发 |
| **assignee 已设** | 已认领/在飞 —— 不是你的就永不碰 |
| `pm:dispatched` | 已派发(派发评论记轮次);与摘 `pm:queue` **同一次标签写入**成对落地 |
| `needs-user-decision` | 决定**待做** —— 永不派发、除已裁代裁通道外永不代答;维护者的收件箱 |
| `needs-user-decision` | 决定**待做** —— 永不派发、除已裁代裁通道外永不代答;维护者的收件箱 = 其 **Assigned 队列**(维护者 2026-08-19 裁定含义:「在等维护者」必须是 GitHub 原生可推送状态,不是座位贴/生成视图里的一段文字):挂标的同一笔 assign `os-zhuang`,裁决誊录/代裁换态的同一笔摘指派 —— 此指派是收件箱路由不是认领,不入死认领回收 |
| `pm:on-hold` | 决定**已做**且答案是「不是现在」—— 不派发也不催;**仅当正文带机器可读行 `Restart-when: closed <owner/repo>#N`(由 `Blocked-by:` 的同一遍解锁扫描点火、同一正文单通道)或 `Restart-when: <一行可执行判据>` 时才合法**;hold 评论带日期、理由、出处(维护者裁或座位定级,⛔ 不设第二个标签区分);**放行双查(两查皆机械、零判断)**:① 只对**最近一次** `pm:on-hold`/`pm:blocked` 转换评论所载条件放行,⛔ 永不对线程里更早的 blocker —— 已放行过的条件是花掉的,再点火就把过期前提立成现行;② 该转换评论之后卡上有**更新的 merged PR** ⇒ 拒绝放行 —— 那是条件写下后卡已前进的信号(引用的事实可以为真而不再是现行条件) |
| `pm:blocked` + 正文行 `Blocked-by: #N` | 等上游 —— 选择期跳过,#N 关闭时由解锁扫描放回。**工已完、PR 被外部门禁缺陷卡住的卡同用本态,⛔ 不设新标签**:`Blocked-by:` 指向门禁缺陷卡,正文另加机器可读行 `Unlock-action: re-check PR #M` —— 解锁扫描读到它就把解锁动作从「回队重派」换成「重查该 PR 的落地」(回队前提检查见到已完工的 open PR 即按落地工作处理,⛔ 永不给完工卡重派 dev);停放的 PR 正文必须点名门禁卡,让链路从任一端可读、不依赖会被整篇改写的座位贴 |
| `pm:blocking` | 有 open 下游依赖者(分诊 sweep 自 `Blocked-by:` 索引推导的缓存,⛔ 不手工挂);进选择优先级全序 |
Expand DownExpand Up@@ -265,8 +265,7 @@ objectui pin 落后且其队列已空 ⇒ 在本仓立/刷新 console bump 单;
**必带四棱卡面块**(见「升级与决策」),⛔ 不留待有人接手再补;**`finding`** —— 观察类(死代码、未演
练漂移、抛光;真实但今天没有用户撞上),待首次定级;**先修复(repair first)** —— 正文被 sanitizer 截断的卡不
可派发,评论修复指令后跳过;停摆指令判据必须比其它分类更硬(双读取),事后证伪同处公开作废。
**决策箱勤务(常设)**:落卡入箱时校验/补全标准四棱卡面块;存量卡低频子轮回填;摘要 issue 按轮刷新
—— 块形状、批量决裁通道与脚本化出口见「升级与决策」。
**决策箱勤务(常设)**:落卡入箱时校验/补全标准四棱卡面块(块形状见「升级与决策」);存量卡低频子轮回填。

**原生 issue 类型 Bug/Feature/Task 是分诊的固定产出**(维护者 2026-08-12 裁定「同意」):分诊
座位是 `type` 字段的唯一权威生产者(立单者可预填,分诊校正 —— 与 `domain:*` 同一纪律);判据即
Expand DownExpand Up@@ -497,10 +496,13 @@ issue 评论;④ draft PR 一存在立即 `subscribe_pr_activity` 硬步骤)全
「同意」):`docs/adr/**` + `.claude/**`(全量,含 agents/hooks/settings)+ `skills/**` +
`AGENTS.md` + `CLAUDE.md`;agent 指令文件按此跨仓同判 —— objectui、cloud、objectos 一并在内(维护者
2026-08-18:「任何对 agents.md 等文件的修改…包括 objectui cloud仓库」→「同意」;objectos 指令面
PR 照样 draft/人工合并)。路径面**一条命中** ⇒ ACCEPT 换终局三件套:① 复核结论照常写在
PR 照样 draft/人工合并)。路径面**一条命中** ⇒ ACCEPT 换终局四件套:① 复核结论照常写在
issue 上(不能合 ≠ 不复核;技能面 PR 的复核席须跑在契约复审档位,档位单源见条款②闸门);
② PR 留给维护者,**看得见地悬着** —— **人工合并即审核记录,本条座位纪律是唯一的 merge 前防线**
(per-PR 事前门已退役,没有机器会替你挡):⛔ 永不翻 ready、永不入队、永不挂 auto-merge;③ 轮次报
(per-PR 事前门已退役,没有机器会替你挡):⛔ 永不翻 ready、永不入队、永不挂 auto-merge;③ 在
draft PR 上 **request review `os-zhuang`**(维护者 2026-08-19:「还是应该在 pr 的审核流程,发给
os-zhuang 审核。我的手机github 应该会收到推送消息吧」;当日实测 draft 可点名审核且推送到达手机,
维护者确认「推送到了」)—— 「等人合」清单从此活在 GitHub 的 Review-requested 队列,合并自动消项;④ 轮次报
告单列「awaiting a human merge」(「等人来合」与「被忘了」在 GitHub 上长得一模一样)。混
合 diff 一条命中就分叉,⛔ 不按比例判;要拆就让 dev 单独开 PR;已入队才读到本条 ⇒ 撤回只有
转 draft。路径面干净的才转 ready → 入队(队列是唯一被认可的落地路径,⛔ 永不队列
Expand DownExpand Up@@ -588,10 +590,10 @@ issue 上(不能合 ≠ 不复核;技能面 PR 的复核席须跑在契约复审
**落卡/升级流程**:① **先刷新卡片前提** —— 隔夜没动的卡默认按「前提未经验证」处理;**卡上每条前提
行自带一条 re-check 命令**(`git log … -- <path>`、REST compare、带引号精确名 grep、`ls-remote |
grep <branch>`),复升级时逐条**跑**一遍,零命中/变形的就地改写或撤卡。② 决策默认**锚在所属 issue**
(分析发评论 —— 英文,模板见 references;挂 `needs-user-decision`、退出活动队列),无自然锚才单开
(分析发评论 —— 英文,模板见 references;挂 `needs-user-decision` + assign `os-zhuang` 同笔、退出活动队列),无自然锚才单开
`[Decision] <一句话>` 卡。③ **答复/代裁到手,裁决记录是一个原子动作,四件同笔**(维护者 2026-08-13)
:鲜度门(录前重读晚于正文最后编辑的评论,有修正的先调和正文)/ 状态转换同笔(决策标签或 finding 定
级换结果态,永不留挂)/ `Blocked-by:` 活性现验(合并一半也算解除,耗尽行同笔删)/ 条件已判即判(输入已知的就地判掉);案例与机械两旗见 `references/dispatch-runbook.md`。
级换结果态、`os-zhuang` 指派同笔摘,永不留挂)/ `Blocked-by:` 活性现验(合并一半也算解除,耗尽行同笔删)/ 条件已判即判(输入已知的就地判掉);案例与机械两旗见 `references/dispatch-runbook.md`。
**每个方案必须沿四条固定评估轴分析,这是决策分析的核心原则,不是可选项:**

- **实际业务需求** — 它服务的是**真实存在的业务场景**,还是投机性能力面?判据要求**实测**(谁在
Expand All@@ -606,8 +608,9 @@ grep <branch>`),复升级时逐条**跑**一遍,零命中/变形的就地改写
布零消费的能力不因沉没成本获得豁免。

推荐意见必须基于这四条轴给出理由;四轴冲突时如实呈现权衡,交维护者拍板。**标准四棱卡面块是落卡与
升级的必备件**(四棱维护者 2026-08-11 接受;标准块/摘要视图/批量决裁通道 2026-08-18 裁定「同意」——
块标准化把提取从 LLM 理解题降级成 grep),每张 `needs-user-decision` 卡落卡即带、⛔ 不留待维护者到
升级的必备件**(四棱维护者 2026-08-11 接受;标准块 2026-08-18 裁定「同意」—— 块标准化把提取从 LLM
理解题降级成 grep;同裁定的摘要视图/批量决裁通道已退役 —— 维护者 2026-08-19:「之前定期生成的决策
汇总 issue没什么用」,收件箱改走 Assigned 队列,见状态模型),每张 `needs-user-decision` 卡落卡即带、⛔ 不留待维护者到
场再补。固定形状:首行**机器可寻固定标记** `<!-- os-decision-facets -->`(转义拼写写入,写后回读核
验存活;提取按字面文本 grep,不依赖注释形状 —— sanitizer 纪律见平台读数);四棱各一行 —— ① platform
long-term coherence(缩小还是扩大特例/契约增生);② measured business pull(今天谁撞上;零拉动默认
Expand All@@ -618,13 +621,6 @@ scope discipline(remove 优于 declare-and-maintain,每个已声明的键都是
四棱是四条评估轴的卡面序列化,一一对应,同一个框架不是第二套;也是分诊代裁置信门的输入(见分诊职责)。交互会
话可另发 `AskUserQuestion`,带标签的 issue 恒为持久记录。

**摘要视图与批量决裁**(同一 2026-08-18 裁定;实施既有批量裁决 2026-08-15 原话「还是等我批量决裁
吧。」):恒设一张钉住的摘要 issue,分诊 Routine 以通用查询 + 标记提取刷其**正文**(编辑历史即存档)
,逐卡**逐字粘贴**标准块,⛔ 零转述;权威恒在卡上 —— 摘要是生成视图,永不是第二跟踪器(one-board 规
则)。维护者可在摘要下一条评论批量裁多张(逐卡「编号 + 选项字母」对);分诊席把每条裁决转录回其卡,
走既有裁决记录原子四件,引批量评论为出处。**脚本化升级触发(记录在案的出口,不是重设计)**:收件箱
持续 >20 张 open,或刷新节奏到达每日(内联命令开始跨 fire 漂移)⇒ 把提取冻结进 `scripts/pm/` rollup 脚本。

## 护栏(Guardrails,有约束力)

- PM **不写任何文件**(唯一例外及其全部条件见全体座位不变量,⛔ 不另抄第二份);合并只对**已复核
Expand Down
Loading