这套系统在解决什么
先看目标：把 AI 协作交付从“碰运气”变成“可审计流程”。
从产品视角看它
把它想成一个“项目机场塔台”：每个任务不是直接起飞，而是要先过排班、航线、安检。仓库把执行拆成两个平面：OpenSpec specification plane 与 Ultra-Orchestrator execution plane。
OpenSpec
管理 Program → Milestone → Change → Slice 的规格与状态。
Ultra-Orchestrator
管理 Intake → Plan → Dispatch → Execute → Review → QA → Deliver → Retro。
读一段真实仓库代码
OpenSpec specification plane: Program -> Milestone -> Change -> Slice
Ultra-Orchestrator execution plane: Intake -> Plan -> Dispatch -> Execute -> Review -> QA -> Deliver -> Retro
This repository is the source-of-truth for the skill system, references, and orchestration methodology.
第一行在说“项目规格怎么分层”，像目录结构。
第二行在说“执行动作怎么走”，像工单流水线。
第三行在说“这里是官方基线”，不是零散脚本集合。
把“规格”与“执行”分开，是典型的 separation of concerns。你给 AI 下指令时，也会更容易定位“该改文档，还是该改实现”。
快速测验
你让 AI 并行改 6 个文件，最先应该落在哪个平面？
核心角色与分工
这不是一个巨型 prompt，而是一组有边界的技能角色。
像剧组一样分工
可以把它想成拍电影：编剧管故事、导演管调度、后期管质检。仓库里每个 skill 都有明确职责，比如 dispatch、QA、risk vetter。
主控状态机和阶段顺序
把 OpenSpec 文档翻译为执行工件
分别看行为正确性与工程质量
角色对话动画
$clarify-and-intake for intake normalization
$decision-complete-planner for task graph creation
$dispatch-and-track for work package assignment and ledger updates
先把用户需求“翻成可执行文本”。
再把任务拆成可依赖、可并行的图。
最后分发工作包并更新执行账本。
快速测验
两个工作包都要改同一目录时，dispatch 最安全的做法是？
一次任务如何流转
把八阶段看成地铁线路：每一站都在降低后续返工概率。
八阶段不是装饰
这里的 state machine 思路很硬核：阶段顺序固定，但允许回环。也就是 Review 不通过会回 Execute，QA 发现架构问题会回 Plan。
Intake
Plan
Dispatch
Execute
Review / QA / Deliver / Retro
消息流动画
代码翻译 + 测验
Execute stages in this exact order:
Intake
Plan
Dispatch
Execute
Review
QA
Deliver
Retro
先声明有“固定顺序”这个规则。
中间四步负责把任务从想法变成可检查成果。
后四步负责验收、交付、复盘，避免重复踩坑。
Review 发现代码不符合既定规范，但需求本身没变，回到哪一站最合理？
状态与桥接契约
Change 是账本单位，Slice 是施工单位，二者不能混用。
为什么要硬性状态词表
把它想成物流面单：每个包裹只能处于少数固定状态，才能被全链路系统识别。这里同理，canonical statuses 是自动同步的前提。
slice_0_not_opened尚未打开实施slice_0_spec_ready规格已备齐，可进入实现slice_1_completed ... slice_4_done从实现完成到 QA 待审再到最终完成真实桥接规则代码
Map change-id to TaskManifest.id.
Map proposal summary to goal.
Map design constraints to constraints.
Map task acceptance criteria or spec delta checks to success_criteria and acceptance_checks.
先把变更编号绑定到执行任务主键。
再把提案摘要变成可执行目标。
把设计约束与验收规则转成机器可检字段。
bridge 的职责是“映射”，不是把 OpenSpec 全部重写成 Ultra 格式。这样才能保留长期文档资产。
快速测验
某 slice 已改完代码但还没验证，状态最合理的是？
质量门禁与反馈回路
“能跑”不等于“可交付”，所以要把 Review、QA、Risk 拆开。
三道关卡
像发布会彩排：导演看节奏，品控看细节，法务看风险。这里对应 code review、QA verify、risk vetter。尤其 regression 检查，是防止“修 A 坏 B”。
QA Verify
验证行为，不只看代码形状。
Code Review
检查规范、一致性、可维护性。
Risk Vetter
高影响动作前先分级再执行。
真实 QA 规则代码
Validate behavior, not just code shape.
Treat QA as two-mode verification:
Static baseline: reason over code, diffs, existing tests, and available evidence
Dynamic verification: run tests or commands when the host environment allows it
第一句强调：不要只看代码像不像“正确答案”。
第二句说 QA 有静态与动态两种模式。
后两句给出实操：能跑就跑，不能跑也要基于证据推理。
快速测验
你准备执行破坏性命令清理目录，第一步应是什么？
安装与实战启动
最后把知识落到动作：如何装到 Cursor 并跑一个最小闭环。
最短上手路径
可以把安装看成“给你的 AI 助手装一组新插件”。先拷贝 skill 目录到全局路径，再刷新上下文。这里的 global installation 可以避免每个项目重复配置。
把核心 skill 文件夹复制到 `C:\Users\<you>\.cursor\skills\`
重启或刷新 agent context，让新技能被索引
先做一个 bounded slice，验证效率与稳定性
真实安装代码与解释
Copy-Item -Recurse -Force .\skills\ultra-orchestrator C:\Users\<you>\.cursor\skills\ultra-orchestrator
Then restart Cursor or refresh agent context.
edit/update skills in this repository
validate in a real project
第一行是“把技能复制到全局目录”的命令。
第二行提醒你必须刷新编辑器上下文。
后两行说明发布节奏：先改源码，再在真实项目验证。
只复制 skill 不刷新 context，经常会让你误以为“技能没生效”。先确认加载，再开始执行任务。