Skip to content
Merged
Show file tree
Hide file tree
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
115 changes: 57 additions & 58 deletions .claude/skills/pm-dispatch/SKILL.md
Original file line numberDiff line numberDiff line change
Expand Up@@ -184,15 +184,15 @@ fire 一轮烟测,判据取**GitHub 上的产出**;③ 每 fire 一轮:读座位

## 多仓协调(五条规则)

产品横跨三仓,依赖方向固定:`objectstack`(后端;`packages/spec` 是唯一契约)→ `objectui`(前端,
建产物经 `pnpm objectui:refresh` 回流)与 `cloud`。链外两仓不入依赖链:分诊照扫(分诊座位保持五
仓唯
一),各归同名 `repo:*` 执行座位,纪律即规则 4 姊妹仓执行座位一套(⛔ 此处不另抄)。第四仓
`objectos`
(纯文档与站点,执行已自 `domain:devx` 迁出):座位由维护者 2026-08-18 开设(「objectos 是新开的项目
经理,是不是少了座位帖。」);无 changeset 流、无 `packages/`;合并队列 + required `build` + `merge_group` 已上线 —— 派发预期照实设,⛔ 不要求不存在的机制。
第五仓 `hotcrm`(样板工程:元数据开发的 CRM 示例应用):收卡判据、宪章原文与边界全在
`references/lanes/hotcrm.md`。
产品依赖方向固定:`objectstack`(后端;`packages/spec` 是唯一契约)→ `objectui`(前端,构建产物经
`pnpm objectui:refresh` 回流)与 `cloud`。**仓分两类**(维护者 2026-08-26 裁定;原话与 skills/决裁归
席见「升级与决策」):**多车道仓** `objectstack`、`objectui` —— 中央分诊是 `domain:*`/type/定级
的唯一生产者;**单车道仓** `cloud`、`objectos`、`hotcrm`、`www.objectos.ai`(未来新仓默认此类)——
其 `repo:*` 席自理无冲突的机械三务(自扫 sweep、自打 `type`、自做 `finding` 首触定级),⛔ 不产
`domain:*`,决策卡默认入 objectstack 收件箱;跨仓查重/shadow 检查恒归中央(全仓视图不可下放)。
**新仓登记是一张清单**:座位贴、标签、类别归属、门禁盘点;准入判据一句 —— 这个仓
真的需要常设席位吗。逐仓事实照实设(objectos 无 changeset 流、无 `packages/`,合并队列已上线;
hotcrm 收卡判据与宪章见 `references/lanes/hotcrm.md`)
**objectui 卡按修复落点分流三流**(维护者 2026-08-21 裁定,`domain:ui` 唯一新增标签,命名定稿原
话:「按 domain:ui 定稿」):`domain:devx`(工程面)/`domain:spec`(契约面)跨仓归各自车道,其余 —— 发
布库与 apps —— `domain:ui` 归 objectui 执行席;症状位置不改流向,docs 随所记录的面走,落点不
Expand DownExpand Up@@ -223,25 +223,17 @@ devx@objectui;触发即规则 4 预登记的拆分条件),各席独立座位贴
3. **联动杂事立单,不靠记忆。** 已验收 PR 的产物流向另一仓时,由**接受那个 PR 的执行座
位**立即
在消费仓立后续单(带 `Blocked-by:`);`domain:*` 仍由分诊补。
4. **纵向拆分:一个分诊 PM + N 个执行 PM,一人一车道双射**(维护者 2026-08-05 拍板;2026-08-16 裁
定分诊统一收归一座)。分诊座位**五仓唯一**(仓单即多仓协调首段的五仓):全部 backlog 的
分诊/
定级/路由/type 由它一座生产,只扫/分类/打标签/拆分/查重/转仓,⛔ 永不认领、永不派发、
永不写代
码。执行座位信任标签、只在本车道认领,误标**不自行改**、挂 `pm:retriage` + 异议评论同
笔;姊妹仓 `repo:*` 座位收窄为**
执行座位**(在本仓认领/派发/复核/落地,同一套执行座位纪律,⛔ 不产 `domain:*`/type/定
级;skills
车道 finding 自分诊例外照旧)。**拆分触发条件预登记**:单轮时长逼近 fire 周期,或某仓在
优先级
全序下持续断粮 ⇒ 按仓拆回多席 —— 扩容是记录在案的出口,不是重设计。⛔ 借调已删
除:突发积压调
频率或 `batch`,持续积压拆域走 PR。**维护者直派通道**(2026-08-10 常设授权):维护者当面指挥
的 PM 会话直接路由,审计评论逐字引用授权指令,只对明示指挥的卡成立。分诊空缺时会话
型执行 PM 可
**代扫**(只做分诊动作,不跨车道认领,座位贴注明),座位有主立即停止 —— 两个分类生产
者并存,单
一生产者的保障当场归零。
4. **纵向拆分:一个分诊 PM + N 个执行 PM,一人一车道双射**(维护者 2026-08-05 拍板;2026-08-16 裁定
分诊统一收归一座)。分诊座位**唯一**:多车道仓 backlog 的分诊/定级/路由/type 由它一座生
产,只扫/分类/打标签/拆分/查重/转仓,⛔ 永不认领、永不派发、永不写代码。执行座位信
任标签、只在本车道认领,误标**不自行改**、挂 `pm:retriage` + 异议评论同笔;单车道仓
`repo:*` 席 = 执行座位 + 机械三务自理(类别与三务见首段;skills 车道 finding 自分诊例外照
旧)。**拆分触发条件预登记**:单轮时长逼近 fire 周期,或某仓在优先级全序下持续断粮 ⇒
按仓拆回多席 —— 扩容是记录在案的出口,不是重设计。⛔ 借调已删除:突发积压调频率
或 `batch`,持续积压拆域走 PR。**维护者直派通道**(2026-08-10 常设授权):维护者当面指挥的 PM
会话直接路由,审计评论逐字引用授权指令,只对明示指挥的卡成立。多车道仓分诊空缺时
会话型执行 PM 可**代扫**(只做分诊动作,不跨车道认领,座位贴注明),座位有主立即停止
—— 双生产者并存即失守。
5. **一块板,不设第二跟踪器(one board, no second tracker)。** pm 标签就是状态机;org Project 只是维
护者的聚合视图,权威层坚持 issue 正文 + REST。

Expand DownExpand Up@@ -342,10 +334,12 @@ skills,类似分诊」)—— 贴内指针指向其车道文件,升级走技能

## 分诊座位职责

(执行座位 ⛔ 跳过本节动作 —— 读到标签当既成事实。)本节全部职责**对五仓统一执
行**(仓单与出处见「多仓协调」首段与规则 4):sweep、首触定级、发版板(objectos、hotcrm 无发
版板,跳过)、查重/shadow 检查与代裁通道逐仓各跑一遍;
**代裁权限唯一归本座位**,任何执行座位(含姊妹仓 `repo:*`)⛔ 不代裁。
(执行座位 ⛔ 跳过本节动作 —— 读到标签当既成事实。)职责按仓类执行(类别
见「多仓协调」首段):sweep 与首触定级只对多车道仓(单车道仓机械三务自理);发版板(无板仓
跳过)、查重/shadow 检查与代裁通道全仓照跑。**代裁通道保留、档位硬门**(维护者 2026-08-26
裁定,原话:「代裁通道如果是 fable 可以代裁,其他接受你的建议」):仅当运行席**实测服役模
型** = `claude-fable-5`(降档保险丝机器读数,⛔ 永不凭自述)才可代裁;通道只在分诊 Routine(钉
档)或 skills 席上运行,其余执行座位 ⛔ 不代裁;2026-08-12 置信门其余条件全部照旧。
**工具加载纪律(fire 开局)**:互斥检查/自退判断只按名加载所需工具 —— `ToolSearch` 用
`select:mcp__github__list_issues,mcp__github__issue_read` 形式,判定「本轮有活」之后才加载其余;⛔ 开
局不做泛关键词 ToolSearch(一次注入全家桶 schema —— 分诊席 2026-08-20 自测:空转轮 ~12 万
Expand All@@ -356,14 +350,14 @@ token,~8 万是这张门票);可验判据:空转轮 ~4 万以内。只约束分
2026-08-20:「每次都需要 四仓全量 open issue 盘点 … 吗?建议分诊多久执行一次」→「立卡」)**:小
时轮以 `since` 窗口读增量 —— 锚 = 座位贴上一份收班简报的时间戳(互斥守卫同一读数,零
新状态;标签写入刷新 `updated_at`,窗口锚在简报而非上次 fire,漏 fire 积压自动入窗);每日一
fire 跑四仓全量对账并归集日频职责;选层按 fire 时刻 ⛔ 不用计数器(fresh session 无计数
fire 跑全仓全量对账并归集日频职责;选层按 fire 时刻 ⛔ 不用计数器(fresh session 无计数
器);简报写明本轮跑的层(下轮读者靠它知道窗口盖了什么)。从不更新的卡不入窗是设计:它
上次变更时已被扫过,老化欠账归半状态巡查不归小时轮(`since` 读法与成本对价见 runbook)。

**Backlog sweep(常设职责,不等请求)。** 每轮扫任一析取命中的卡:① 全裸(无`pm:*`、
无 `needs-user-decision`、无 `domain:*`);② 有 `pm:queue` 无 `domain:*`(**凡有车道标签的仓皆扫**,
今日为主仓与 objectui —— 三流拆分见多仓协调;豁免仅余真无车道标签的仓 cloud、objectos,该
形状在那里才是队列卡常态);③ 有 `domain:*` 无 pm-state。②③ 只取 `updated_at`
无 `needs-user-decision`、无 `domain:*`);② 有 `pm:queue` 无 `domain:*`(仅多车道仓 —— 三流拆分
见多仓协调;单车道仓无 `domain:*` 是队列卡常态,自扫归其席);③ 有 `domain:*` 无 pm-state。②③
只取 `updated_at`
早于 ~2 分钟的卡且不是可选项 —— 半标注卡是协议自己按设计生产的(一次标签写入即把
老卡打成半标
注),只带路由或状态机其一的卡对两个视图同时不可见。排除:`tracking`、`status:parked`(其正常
Expand DownExpand Up@@ -404,7 +398,7 @@ sanitizer 截断的卡不
扫必烂),新卡即时打、存量卡下次碰到补。读者三个:代裁路由(`Feature` 机械落人工地板,`Bug`/
`Task` 才是代裁候选)、发版板缺陷扫描(`type:Bug is:open`)、普通队列 Bug 优先平手判据。

**路由即分诊的技术判断,永不升级「哪个仓?」。** 读五仓代码定落点;跨仓的按contract-first
**路由即分诊的技术判断,永不升级「哪个仓?」。** 读全仓代码定落点;跨仓的按contract-first
拆分;父单已有子结构的,父单队列标签即可(sub-issue 自动成为候选),分诊逐个展开路由、补
`Blocked-by:`
排序,父单是协调节点**永不派发**。每张留一条英文审计评
Expand DownExpand Up@@ -461,14 +455,11 @@ sanitizer 截断的卡不
扩大接受集或公开面**?扩大 ⇒ 功能新增/协议变化 ⇒ 人工;接受集不变、拉回已声明契
约(declared =
enforced 的恢复)⇒ bug/整理 ⇒ 代裁车道。
- **置信门(全部成立才可代裁)**:① 四棱同向(全指向同一选项,任何分裂即升级);②不在人工
地板上
;③ 不收窄、不推翻任何既有维护者裁决;④ 执行是**否决窗口不是许可门**—— 裁定 →
一次标签写入
换 `needs-user-decision` 为工作态 → 卡上贴四棱块 + 结论 + `auto-adjudicated` 标记 → 轮次报
告设**代裁清单**专节(聚合漂移的刹车);⑤ 代裁分析跑在 `claude-fable-5`(与维护者手工流程
同档),达档认定与未达处置同复审链降档保险丝(机器读数为准;未达 ⇒ 本 fire 代裁整体跳
过、卡原样留在决策箱走维护者路径,恒安全)。
- **置信门(全部成立才可代裁)**:① 四棱同向(全指向同一选项,任何分裂即升级);② 不在人工
地板上;③ 不收窄、不推翻任何既有维护者裁决;④ 执行是**否决窗口不是许可门**——
裁定 → 一次标签写入换 `needs-user-decision` 为工作态 → 卡上贴四棱块 + 结论 +
`auto-adjudicated` 标记 → 轮次报告设**代裁清单**专节(聚合漂移的刹车);⑤ 本节首段的档位
硬门达标(未达 ⇒ 本 fire 代裁整体跳过、卡原样留在决策箱走维护者路径,恒安全)。
- **回翻条款**:代裁卡实施中发现契约终究要动 ⇒ dev 停手,卡回`needs-user-decision` —— 报告
分叉,⛔ 永不静默重裁。
- **请示纪律(维护者 2026-08-25:「不要不停的弹出来让我确认,很浪费时间」)**:①方向性授权(
Expand DownExpand Up@@ -769,10 +760,14 @@ os-zhuang 审核。我的手机github 应该会收到推送消息吧」;当日
维护者确认「推送到了」;推送通道仅此一条,同日裁定:「只有需要我审核的pr 推给我。」)—— 「等人
合」清单从此活在 GitHub 的 Review-requested 队列,合并自动消项。**能请审则请审;PR 作者身份即 os-zhuang 的席位,请审必失败**(GitHub 拒绝向 PR 作者请审,author-identity 422)—— 改为把 PR **assign 给 os-zhuang** 替代通知,并在轮次报告点名说明走了 assignee 兜底;④ 轮次报
告单列「awaiting a human merge」(「等人来合」与「被忘了」在 GitHub 上长得一模一样)。混
合 diff 一条命中就分叉,⛔ 不按比例判;要拆就让 dev 单独开 PR;已入队才读到本条 ⇒ 撤回只
转 draft。路径面干净的才转 ready → 入队(队列是唯一被认可的落地路径,⛔ 永不队列
外 `--auto` 合并)。**入队资格 = PR 上每一个 check 全绿,⛔ 不是 required 子集** —— required 集是
合 diff 一条命中就分叉,⛔ 不按比例判;要拆就让 dev 单独开 PR;已入队才读到本条 ⇒ 撤回
只有转 draft。**skills 车道自有 PR 再按 diff 内容分流**(维护者 2026-08-26 裁定,原话:「skills 中的
pr,只有包含md文件时需要推给我审核,其他代码文件你直接自己审核。」):diff 含任一 `.md` 文件 ⇒
上述终局四件套照旧;纯代码面(`scripts/pm/` 工具、`.claude/` hooks/workflows/settings、`skills/**` 非
md 产物)⇒ skills 席按契约复审档自审(清单不减)后直接落地(ready → 入队),⛔ 不推维护者;分
流只及 skills 车道自有 PR,其它车道 governed 面照旧。路径面干净的才转 ready → 入队
(队列是唯一被认可的落地路径,⛔ 永不队列外 `--auto` 合并)。**入队资格 = PR 上每一个 check
全绿,⛔ 不是 required 子集** —— required 集是
队列强制的地板,不是 PM 放行的门槛;非必查门的红要么是真缺陷要么是坏门,两者都归 PM 入
队前处置(实测:一张 required 全绿、非必查类型门与一个测试分片红着的 PR 经队列落地,该仓
main 红了约一小时,逐 PR 连环红到 fix-forward 才止)。本段只适用本循环派发的 dev PR;PM 自己的
Expand DownExpand Up@@ -928,7 +923,7 @@ grep <branch>`),复升级时逐条**跑**一遍,零命中/变形的就地改写
卡面块是落卡与升级的
必备件**(四棱维护者 2026-08-11 接受;标准块 2026-08-18 裁定「同意」;同裁定的摘要视图/批量决
裁通道已退
役,墓碑与原话见「回批入口」;收件箱由维护者定期与 AI
役,墓碑与原话见「常设决裁流程」;收件箱由维护者定期与 AI
讨论消化,⛔ 不 assign 推送 —— 维护者 2026-08-19 裁定:「我感觉决策卡推给我太麻烦了,我需要和ai讨论才能判断,这个还是维
持之前的样子。我会定期和ai讨论。」),每张 `needs-user-decision` 卡落卡即带、⛔
不留待维护者到场再补。**四维分析从业务的角度写**(2026-08-20 裁)—— 落卡分析模板、写法
Expand All@@ -944,10 +939,15 @@ grep <branch>`),复升级时逐条**跑**一遍,零命中/变形的就地改写
指向它,队列其余照常消化,⛔ 永不整席等答复。`AskUserQuestion` 只是**在场加速器**:仅当维护
者在本会话
~30 分钟内有过人类输入才可发,每问必带推荐项,被 Skip 或长挂即转卡通道 ⛔ 不重弹 ——
卡先于弹窗存在,弹窗怎么死盘面都诚实。**回批入口**:维护者说「处理决策卡」= 当轮扫全
部 open
决策卡批量呈报清积压,即上句「定期和ai讨论」的常规触发词,⛔ 不复活已退役的汇总
issue(维护者 2026-08-19:「之前定期生成的决策汇总 issue没什么用」)。
卡先于弹窗存在,弹窗怎么死盘面都诚实。
**常设决裁流程:决裁与跨仓 skills/指令面工作统一归 skills 席,维护者驱动的人工流**(维护者
2026-08-26 两裁,原话:「skills 和决裁的问题,还是由skills席统一人工处理,我会要求你处理某个仓的skills
和决裁。」;「决裁流程今天这样很好,决策卡5张一组,从业务的角度给我具体解释,说明可选项,并进行四维
分析。应该写入技能。」):维护者说「处理决策卡」即入口;每批 ≤5 张按优先序
呈报,每卡业务角度具体解释 + 选项与真实代价 + 四维分析 + 一个推荐;一行回批
(「1A 2B …」;「X, 但…」= 附带条件随执行落地)即全链执行,裁后四件原子执行不再请示;
批间新到滚入下批,收件箱清零才收工 —— 批序与细则见 `references/decision-analysis.md`;
⛔ 不复活已退役的汇总 issue(维护者 2026-08-19:「之前定期生成的决策汇总 issue没什么用」)。

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

Expand All@@ -962,10 +962,9 @@ issue(维护者 2026-08-19:「之前定期生成的决策汇总 issue没什么
陷上报。
- **Governed 面由维护者人工合并,合并即审核记录**(三裁一脉:2026-08-08「adr 只能由维护者自己确
认,人工合并,ai 不得擅自合并」;2026-08-11「所有 skills 的更新和adr 类似,需要人工审核」;
2026-08-18 对「人工合并即人工审核,事后审计代替事前门」整包:「同意。」)。面 = ACCEPT 路
径分叉
的统一定义,禁令三条与离队出口同见该节;事后防线 = 审计清单,维护者不认识的条目 = 席
位违规,立案回滚。
2026-08-18 对「人工合并即人工审核,事后审计代替事前门」整包:「同意。」)。面 = ACCEPT
路径分叉的统一定义;skills 车道纯代码 PR 的 md-content 分流、禁令三条与离队出口同见该节;
事后防线 = 审计清单,维护者不认识的条目 = 席位违规,立案回滚。
- **决定属于维护者:永不代维护者回答产品/架构问题**(唯一例外:分诊职责里已裁的代裁车
道,边界恰
与其置信门重合,不得更宽);**永不派发 assignee 是别人的 issue;永不派发带 `needs-user-decision`
Expand Down
20 changes: 10 additions & 10 deletions .claude/skills/pm-dispatch/references/decision-analysis.md
Original file line numberDiff line numberDiff line change
@@ -1,22 +1,23 @@
# 决策分析写法 —— 四维从业务角度写

出处(维护者 2026-08-20 裁定,逐字,未译):「四维分析应该从业务的角度写我才好判断」。范例
实测一
行:同一问题,实现视角的分析让维护者追问「给我从业务的角度具体解释」,业务视角版当场
裁决 —— 一次
追问 vs 当场可裁,就是本指引的全部理由。
出处(维护者 2026-08-20 裁定,逐字,未译):「四维分析应该从业务的角度写我才好判断」。

## 适用面(边界)

- 只约束 **`needs-user-decision` 卡与决策箱讨论**的四维分析;内部工具卡(dev 派发用)的四维照
旧,不强加行业类比。四条轴本身不变,轴定义与绑定句在主文件「升级与决策」。
- 只适用新记录,存量分析 ⛔ 不回改(new-records-only,与四维中文化同款先例)。

## 常设决裁批流程(2026-08-26 裁;裁决原话与归席见主文件「升级与决策」)

- 每批 ≤5 张,批序:在飞被阻塞 > 运营阻塞 > 用户可见 > 结构性;每卡 = 六项写法 + 四棱块;
回批一行式「1A 2B …」,「X, 但…」= 附带条件随执行落地;裁后四件原子执行不再请示,
一口气跑完;批间新入箱的卡滚入下一批,收件箱读数为零才收工。

## 落卡分析模板(主文件「落卡/升级流程」②的 references 细则;中文,2026-08-19 裁)

段落骨架:背景 / 带 re-check 命令的前提 / 具体问题 / 选项 / 推荐 / 相关单与 PR;标签就是维护
者的
收件箱,答复后按四件录裁。正文六项写法要求:
段落骨架:背景 / 带 re-check 命令的前提 / 具体问题 / 选项 / 推荐 / 相关单与 PR;录裁与状态
转换归主文件「落卡/升级流程」③。正文六项写法要求:

1. **一句话问题**:开头一句话说清冲突是什么,不带实现名词 —— 写「三家公司住一个数据库,管理员打
开权限管理,三个页面全空」,不写「organization_id = NULL 的行是什么,两个互相矛盾的答案都已落地」。
Expand All@@ -27,8 +28,7 @@
4. **四轴从业务立场论证**:每轴的论据是客户/产品/事故后果,机制只作括号补
充;「防 AI 犯错」轴写清
出错时**谁看到什么**(响亮拒绝 vs 静默泄露)。
5. **推荐 + 回退 + 置信缺口**:荐一项、给回退项、明说本分析看不见什么;结尾给低摩擦裁决格式(「回
一个字母即可;或『C,但 X』= 自动落到 B」)。
5. **推荐 + 回退 + 置信缺口**:荐一项、给回退项、明说本分析看不见什么;格式见批流程。
6. **裁后执行段**:「裁后我会怎么执行(你不用管)」—— 让维护者只裁方向不背执行。

## 四棱卡面块固定形状(落卡即带,⛔ 不留待维护者到场再补)
Expand Down
Loading