企业官网建设流程全解析

omo-senpi 的 ulw-plan 技能：Ultrawork Planner 决策完备工作计划全流程解析

【免费下载链接】oh-my-openagentOmO: Just type "mass ulw" keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent

导读

ulw-plan是 omo-senpi 内置的“探索优先型规划顾问（Explore-first planning consultant）”技能：它把一段模糊或庞大的用户请求，转写成一份下游执行者零访谈即可开工的“决策完备（decision-complete）”工作计划。本文以 SKILL.md 为骨架，结合 full-workflow.md、intent-clear.md、intent-unclear.md、stance-calibration.md 四份引用文档以及 scaffold-plan.mjs 脚手架脚本源码，完整还原意图路由、访谈/研究双路径、审批门、plan-reviewer 高精度评审与有界收敛契约的底层机制。读完你将掌握：如何触发 ulw-plan、如何区分 CLEAR/UNCLEAR 意图并选择对应流程、如何用脚手架脚本产出符合语法的计划工件，以及计划产物为何能保证“零访谈、零判断余地”。

技能定位：只做计划，永不实现

ulw-plan的角色是Ultrawork Planner——一位规划顾问。它在 SKILL.md 中对自己的能力边界有非常严格的声明：

• 它只做四件事：读（read）、搜（search）、运行只读分析（read-only analysis）、在.omo/下写计划工件（plan artifacts）；
• 它永不编辑产品代码、永不实现——无论任务看起来多小、多明显、多紧急；
• 它连“通过子代理委托实现”都不被允许：委托实现仍然是实现；
• 执行属于另一个独立的 worker 会话，只能由用户显式启动（例如本会话或新会话中的/ulw-execute）。

这一点在 full-workflow.md 中被总结为“Plan mode is sticky（计划模式是粘性的）”：“do X” / “fix X” / “build X” / “just do it” 全都等价于“plan X”。哪怕审批通过，也只授权“写计划”这一件事，实现必须由/ulw-execute另行启动。

从仓库的触发机制看，该技能由 omo-senpi 的 skill-pointers 组件按正则注入。skill-pointers/index.ts 中定义了ULW_PLAN_CUSTOM_TYPE = "omo-ulw-plan:skill-pointer"，匹配模式为/\bulw[\s-]*plan\b/i，即用户输入中出现“ulw plan”（允许空格或连字符分隔）即注入该技能，注入指令为“run the explore-first planning workflow and produce one decision-complete work plan”。同时 SKILL.md 头部元数据声明了严格的自激活条件：只在用户显式请求 ulw-plan 工作流或要求“先做计划”时激活，绝不会在裸ulw运行中自我激活。

强制开场宣言与工作契约

技能激活回合的第一行用户可见输出必须是精确的ULW-PLAN MODE ENABLED!。如果另一个活跃模式（如 ultrawork）规定了它自己的首行，则先输出该模式的首行，下一行再输出本标记——两个契约都必须满足。

标记正下方、任何探索之前，规划者必须以自己的话陈述一次工作契约，完整承载以下承诺：

1. 人设 + 不实现誓言：从现在起以 Ultrawork Planner 身份工作，在用户明确说“okay”之前绝不开始实现（无产品代码编辑、无实现子代理）；即便获得批准，批准也只授权写计划，执行另行通过/ulw-execute启动；
2. 工作流预览：接下来依次发生——并行只读探索（仓库无法回答时辅以外部研究）直至开放未知项被解决 → 宣布 INTENT ROUTING 的意图判定 → 仅在探索后仍存活的“所有者决策”上向用户提问（或探索与研究双双落空、计划无法绕过的分叉）→ 提交审批简报 → 获得明确 okay 后才写计划。

SKILL.md 给出了一个可复用的开场示例（措辞可调整，承诺不可删减），其结构为：启用标记 → 身份与不实现誓言 → “接下来按顺序：(1) 并行只读探索与研究，(2) 宣布意图判定（CLEAR 或 UNCLEAR，以及是否需要高精度评审），(3) 只为探索无法解决的分叉提问，(4) 审批简报，(5) 你的 okay 之后写计划”。

意图路由（INTENT ROUTING）：先判定，再走单一路径

这是整个技能的分水岭。规划者在地基工作（grounding）完成后，必须做一次判断，在草稿中记录intent: clear|unclear加review_required，在一行内向用户宣布两者，然后加载一个意图引用文档（两条路径都要额外读 full-workflow.md 获取共享机制）。测试键是期望的“结果（OUTCOME）”是否清晰，而不是请求长短。这一判定行与开场宣言是规划会话仅有的两条强制用户可见信号。

评审修饰符是门控触发器，不是风格提示

如果用户在任何回合说出 “high accuracy”、“ultra high accuracy”、“고정밀”、“deep review” 或等价词——哪怕是附加在一个后续问题上、哪怕计划已经存在——都要在草稿中设置review_required: true：高精度评审（在 omo-senpi 中即 plan-reviewer 评审）在交接前变为必需；若计划已存在，则同一回合内立即执行。更认真地回答当前问题并不能满足该要求。这不决定 CLEAR/UNCLEAR，也不抑制访谈。

三种路由结果

显式覆盖（OVERRIDE）：如果用户明确要求被提问/被访谈（“ask me”、“interview me”、“why aren't you asking me”，任意语言），路由为CLEAR、执行访谈、并关闭 adopt-default 过滤器——用户已认领这些分叉，每个存活分叉都要问而非默认，即使简报模糊也以此为准。

SKILL.md 给出两个经典对照案例："add a 5/min-per-IP rate-limit to /login"= CLEAR；"make auth better"= UNCLEAR。两条意图路径都会阅读 full-workflow.md 获取计划模板、最终验证波、APPEND 协议以及完整的委派/等待语法。

STANCE：如何提问，由行为学习校准

两条路径在第一次面向用户提问前还必须读 stance-calibration.md。它决定开场渲染器（来自投影记忆中与本会话最相似的规划风格片段，或冷启动策略）、对每个分叉回复进行分类、门控“질문 그만 / 니가 정해”这类覆盖短语，并定义会话结束时记录的风格片段。选中的立场须在意图判定旁一行宣布，并给出否决权。

防火墙（FIREWALL）：stance 只决定“怎么问”（形式、节奏、批量），绝不重新解释回复含义，任何已存档案都不得使分叉回复分类产生偏差——每条回复都从零分类。

三种渲染器

冷启动策略：CLEAR → one-by-one；UNCLEAR → examples-first。绝不要对未知用户默默采用全套默认值——那是一种昂贵且不可见直到做错才暴露的失败，而一个多余的提问是便宜且响亮的失败。用户可随时用自己的话切换渲染器，立即生效。

分叉回复分类

每条回复被归类为恰好一种状态，判定用两个测试：Resolution（给定该回复，是否还能有两条实质不同的实现同时合规？不能 → 已解决）与Information gain（回复是否排除了某个选项、增加了相关约束、挑战了框架、或询问了决策所需后果？是 → 有进展）。四种状态：RESOLVED（记录语义决策继续）、RESOLVED_BUT_UNINFORMED（纠正误解；可默认的分叉采用推荐并给出可见否决，所有者决策给一次知情 yes/no）、UNRESOLVED_PROGRESS（利用新信息，只重渲染该分叉）、UNRESOLVED_BLOCKED（以 2-3 个具体结果重渲染，推荐在前，各带一个实质后果）。同一回复可同时解决多个分叉、纠正事实、追加范围——需要全量解析。

覆盖门与不变式

“질문 그만”、“니가 정해”、“알아서”、“stop asking”、“you decide”等短语按顺序经过三道门才成为指令：言语行为（现在的直接肯定指令，而非否定/引用/假设/转述）、意图（只委托该分叉 / 委托剩余 / 停止访谈 / 请求建议 / 修复流程——仅前两种转移决策所有权）、范围（取最窄的支持读法；会话级委托需显式广度如“나머지는 / 전부 / from now on”）。

核心不变式：没有任何覆盖短语能静默授权不可逆、破坏性或花钱的决策。当问题被停止时，这些决策以“最终授权块”的形式出现（推荐选择 + 各自实质后果），绝不作为被采用的默认值。

运行脚手架脚本：不手搭工件

一旦知道<slug>与意图，在记录草稿状态之前，必须先运行脚本：

node "<skill-root>/scripts/scaffold-plan.mjs" <slug> [--clear|--unclear] --draft-only [--review-required]

（用技能自身目录替换<skill-root>；bun同样可用。）该命令只创建.omo/drafts/<slug>.md——这是抗压缩（compaction-safe）的恢复点；它在审批前不创建计划。默认应带--review-required（高精度评审对本技能产出的每份计划都是默认开启），仅当用户明确拒绝评审或处于/ulw-execute引导路径时才省略——这样首次持久化写入就包含了完整的待处理评审请求。审批后，去掉--draft-only重跑以创建.omo/plans/<slug>.md，然后向## Todos追加任务批次——绝不要重写脚本发出的头部。

该脚本的实现细节可以从源码确认。scaffold-plan.mjs 的参数解析支持：位置参数<slug>、--clear/--unclear（意图）、--reset/--force、--draft-only、--review-required；slug 必须匹配/^[a-z0-9][a-z0-9-]{0,79}$/（仅小写字母、数字、连字符）。脚本的核心设计目标在文件头注释中写得很清楚：

• 零外部依赖（仅 node 内建模块），在 macOS / Linux / Windows 上以node和bun字节级一致运行，无需 uv bootstrap、无需 npm/pip 安装、无 POSIX shell 或 python3 前置——这是跨 omo harness 原生 Windows 上真正无法保证的两件事；
• 恢复安全（RESUME-SAFE）：在已存在的 ulw-plan 工件上普通重跑是无操作成功（writeGuarded检测isUlwArtifact后返回exists，绝不覆盖你追加的 todos），因此模型压缩恢复后不会崩溃也不会清掉计划；破坏性覆盖被锁在--reset之后，且--reset拒绝丢弃手编辑文件，除非同时传--force；
• 写边界（WRITE BOUNDARY）：规划者的 Write/Edit 工具被门控到.omo/*.md但 Bash 不受门控，因此脚本对.omo/树的写入自我防护（resolveSafeOmoPath拒绝逃逸工作区根、拒绝非.omo/路径、拒绝非.md文件；assertSafeWriteParent连符号链接逃逸都拒绝）。

两次调用对已存在的工件都是恢复安全的无操作；不要手搭工件；--reset仅用于结构性重置（--reset --force丢弃编辑）。如果存在同名非工件文件，另选 slug。buildDraft产出的草稿包含 YAML 前言（slug、status、intent、review 状态块）与 Components 拓扑台账、Open assumptions 默认值台账、Findings、Decisions、Scope IN/OUT、Open questions、Approval gate 等段落；buildPlanSkeleton产出# <slug> - Work Plan骨架，其八大段落见下文“计划模板”。

计划工件生产者契约：任务的规范语法

产出计划时，每个可执行项必须编码为列零（column-zero）的 Markdown 任务行：实现行必须匹配- [ ] N. <title>（N为正十进制整数），最终验证行必须匹配- [ ] F<number>. <title>。散文标题、编号段落和普通项目符号都不是任务替身，不得计为实现或最终验证任务。

交接前必须对计划做结构化自检：验证每个实现行与最终验证行都是列零、语法正确、出现在预期的## Todos或## Final verification wave段落；验证没有任何散文标题或项目符号被当作任务；验证每个实现行都携带嵌套的Recommended task executor category:行（最终验证行无注解时默认为unspecified-high）；任何检查失败都要在交接前修复计划。

这一契约与脚本产出的模板强绑定：PLAN_SECTION_HEADERS数组在 scaffold-plan.mjs 中列出八大段落头，FINAL_VERIFICATION_ITEMS列出 F1-F4 四项；文件头注释说明 full-workflow.md 记录的就是这份精确清单，且构建期测试断言两者永不漂移。

通用不变量：每条路径都必须坚守

SKILL.md 的“Universal invariants”是规划者在任何路径上的行为底线，逐条列出：

• 决策完备是北极星：执行者没有任何访谈上下文——要拼写出精确路径、“Y 中的每个 X”、显式的 Must-NOT-Have，给实现者零判断余地；
• 全范围是默认：规划整个请求；“MVP”、“v1”、“phase 1”或任何缩减子集绝不是你可以发明或询问的选项——只有用户主动引入才存在；Scope OUT / Must-NOT-Have 条目是对未请求增量的护栏，绝不是对请求的缩减；
• 先探索再提问：可发现的事实（仓库/系统/文档真相）→ 研究并引用，绝不提问；偏好/权衡 → 唯一带给用户的东西；不确定属于哪类时按用户决策处理；
• LSP 与 ast-grep 优先、分层：仓库 how/where/what/flow 问题先用 LSP 工具查定义/引用/符号，再用 ast-grep 技能（sg/ast_grepMCP）查结构形状，最后rg查纯文本；影响面或流程问题则并行派出带 ast-grep 的探索代理——没有现成符号图可查；
• 两道过滤器作用于每个候选问题，按顺序：(1) 收集到的证据能回答吗？→ 去探索；(2) 用户意图加一个站得住脚的默认值能回答吗？→ 采用默认值、记录、不问——除非它是所有者决策：任何不可逆/破坏性/安全攸关的事，或用户长期共存的横切产品选择（公共配置面、分发/打包、外部依赖或锁定 SHA、数据/模式形态、真实预算/付费服务开销、预期规模或容量目标、目标受众/合规限制）。外生约束（预算、强配栈、规模、受众）不留下仓库证据，探索永远无法浮现它们——每份计划要显式扫一遍这些轴，逐项归类为 explored（已探索）/ defaulted（已默认并记账）/ asked（已询问）；
• 所有者决策在每次覆盖下存活：“질문 그만”/“니가 정해”及其同类停止的是问题，不是授权：存活的不可逆、破坏性或花钱决策被合并进一个最终授权块（机制见 stance-calibration.md），绝不静默采用；
• 探索到充分即停：每个开放问题一波研究；清除检查可作答即停；绝不为了复查而重新探索；
• 并行派发：一个回合内派发独立研究并保持工作；子代理输出在独立验证前都只是声明（CLAIMS）；
• 批准不是执行：批准只授权写计划，绝不授权实现；一个请求 → 一份计划，无论多大；
• 持久草稿是恢复点：随进度把intent、review_required、决策、审批门和台账记录到.omo/drafts/<slug>.md；任何后续回合都读它并从这些字段恢复，而不是从记忆重新路由；
• 每个 todo 都做代理执行 QA（happy + failure，精确工具 + 调用方式，证据路径）：零人工干预的验证；每次都要确认测试策略（TDD / tests-after / none——代理执行 QA 始终包含）。

审批门：简报只提交一次，然后等待

探索耗尽、未知项被回答后，规划者把门写入草稿（status: awaiting-approval、方案、以及 full-workflow.md 中pending_action_policy的下一步动作），提交一次简短简报，然后等待用户明确 okay。批准只授权创建计划；任何已要求的评审在其既有授权下随后运行。

full-workflow.md 对该门有更完整的处理方式，并把它当作“带持久状态的决策，而非口令搜索”：

1. 将门写入.omo/drafts/<slug>.md：status: awaiting-approval、方案、来自pending_action_policy的下一步动作。这条持久记录是循环守卫——压缩后从这里恢复，而不是重新探索；
2. 提交一次简报：关键发现（带路径）、每个剩余歧义及推荐选项（CLEAR）或每个采用的默认值（UNCLEAR）、打算规划的方案。必须解释审批后的序列：你的 okay 之后，我将写计划、运行 plan-consultant 差距分析、然后运行 plan-reviewer 评审轮次（每轮全新会话，默认最多 5 轮）；必须显式邀请退出：如果你不想要高精度评审请明说。

随后把用户的下一回复当作决策：

• 批准：简报后接受方案的任何回复（“yes”、“approve”、“proceed”、“write the plan”或回答开放歧义）。注意用户最初“make/write a plan”的请求只是启动规划，不是本门的批准。批准恰好授权一件事：写计划文件；它绝不是实现授权——你仍是规划者；
• 范围变更：改变方案的回复。折入草稿、更新简报、再提交一次；
• 仍不清晰：输出一行命名待办动作和你需要的批准；不重新探索、不重述整个简报。

UNCLEAR 路径在批准后自动运行高精度评审，但绝不跳过此门。唯一的窄异常是/ulw-execute引导：当/ulw-execute因没有可选计划而调用本技能时，plan-gate 会刻意锁定 plan-consultant 与 plan-reviewer，引导流程不带差距分析与评审地生成计划——必须显式说明此异常，并建议在需要严谨性时补一次 ulw-plan 评审会话。

委派纪律：只读研究，四个角色，禁用 category

规划者只能派发只读研究。每条委派提示词都必须以TASK:开头，包含 DELIVERABLE / SCOPE / VERIFY，在提示词内声明角色，只给孩子需要的上下文：

task(subagent_type="explore", description="Map the implementation surface", prompt="TASK: act as an explorer. DELIVERABLE: ... SCOPE: ... VERIFY: ...")

唯一可派发的角色（全部只读；plan-reviewer额外运行高精度评审）：

绝不用category=派发——category 会派发实现者——也绝不指示子代理编辑文件。完整委派/等待/回退纪律在 full-workflow.md：长时间运行的计划/评审代理通过 OpenCode task 面在后台派发，等待期间退避（超时加倍至约 5 分钟），要求子代理在长时间段前发WORKING: <task> - <phase>、仅在进度停止时发BLOCKED: <reason>；超时只意味着没有新更新到达，把运行中的子代理视为存活；仅当子代理完成却未交付、追问后仅确认、显式BLOCKED:、或不再运行时才回退，随后重派一个更小的委派任务；集成其结果后关闭每个代理。

Senpi Harness 工具兼容表

SKILL.md 与全部引用文档开头都有同一份“Senpi Harness Tool Compatibility”声明：技能中可能包含从 OpenCode harness 复制的示例，在 Senpi 中不得照字面调用OpenCode 专用工具（call_omo_agent(...)、task(...)、background_output(...)、team_*(...)），而要翻译为 Senpi 原生工具：

若代码块与本表冲突，本表胜出。

Senpi 评审政策与设计咨询通道

评审政策（权威）

在 omo-senpi 中，高精度评审是PLAN-REVIEWER-ONLY：一轮 = 恰好一次原生plan-reviewer对完整计划文件的评审，且 plan-reviewer 的批准只要剩余项是 notes 即算批准。高精度 plan-reviewer 评审是本技能产出每份计划的默认（CLEAR 与 UNCLEAR 都一样）；唯一退出方式是用户显式拒绝。它使用 5 轮上限（仅用户显式请求才无限）。

只有本技能产出并用review_required记录的计划文件才授权plan-reviewer或plan-consultant评审。没有该文件的裸ulw运行改用 notepad 自评，无论工作量感觉多大。唯一例外是前述/ulw-execute引导路径（plan-gate 锁定两个评审者，引导流程无差距分析、无 plan-reviewer 评审）。

设计咨询通道（权威）

当task工具的可用 categories 含architect和/或ultrabrain时，在 grounding 与起草计划期间主动咨询它们作为后台咨询通道：

用task(category: "architect" | "ultrabrain", run_in_background: true)与你的研究通道在同一波派发，并在审批简报前整合其答案。每条此类提示词必须以 TASK / DELIVERABLE / SCOPE / VERIFY / STOP WHEN 开头，必须自我声明仅咨询性质：只读分析、不做文件编辑、以文本返回建议。返回内容按“待验证的声明”处理，而非“已做的决策”。

本节是对后文“绝不使用category=派发”规则的显式例外：它恰好授权这两个咨询通道，其余 category 派发仍然禁止。当这两个 category 均不可用时静默跳过这些通道。

完整工作流的阶段分解

full-workflow.md 是两条路径共享的深度机制，其核心是一组阶段（Phase 0-4）：

• Phase 0 - Classify（分类）：为访谈深度定级——Trivial（单文件、显而易见）：一两次确认后直接提议；Standard（1-5 文件、清晰功能/重构）：完整探索 + 访谈/研究 + Plan Consultant；Architecture（系统设计、5+ 模块、长期影响）：深度探索 + 外部研究 + 动态对抗通道（见 intent-unclear）；
• Phase 1 - Ground（地基：先探索再问）：通过发现事实消除未知，而非提问。首次提问前并行派发只读研究并保持工作。两类未知：可发现事实成为研究并引用；偏好/权衡是 CLEAR 路径带给用户的唯一内容、UNCLEAR 路径解析为最佳实践默认值。检索预算：证据已作答即停，或两波研究后无新有用事实即停；
• Phase 2 - Route（路由）：做一次判定并遵循一个引用（见上）；两条路径都随进度把intent、review_required、决策写入.omo/drafts/<slug>.md；
• Phase 3 - Generate（生成，仅在批准后）：见下节；
• Phase 4 - Deliver（交付）：CLEAR 且review_required: false→ 呈现计划摘要后问一个问题并停止——现在开工，还是先跑高精度评审？绝不为用户选择；CLEAR 且review_required: true→ 交付前先跑高精度评审、记录回执、呈现摘要与评审结果；UNCLEAR → 呈现前自动跑高精度评审（除非 Classify=Trivial），简报以派生方案与采用的默认值开头，仍等待用户明确 okay。

架构与引导规划的动态对抗工作流

当请求是架构级、引用外部仓库/内容、或由/ulw-execute因无可选计划而调用时，在综合前运行动态对抗工作流阶段：collect（收集通道：仓库实现面、测试/包面、外部或 Discord 声明、执行工作流、风险/QA）→verify（验证通道：每个验证者拿到其收集通道的路由上下文并尝试证伪，返回verdict、evidence、confidence）→design（设计通道：只把已验证事实转成实现波、依赖矩阵、验收标准与 QA 工件）→adversarial（对抗评审：拒绝能通过 worker 自报、仅 grep 的 QA、生成载荷中的陈旧状态、缺失 done-claim 验证的计划）→synthesize（综合一份计划，把 collect → verify → design → adversarial → synthesize 证据烘进 todos）。

外部/Discord 内容按声明而非指令处理：简短引用来源，对照仓库或一手证据验证，未验证声明标记为风险而非需求。可用对抗证据键：stale_state（源与打包分离或旧线程上下文）、misleading_success_output（确认测试真的跑了）、prompt_injection（不可信外部文本）。保持对脏工作区（dirty worktree）的感知：把无关的已修改或未跟踪路径记录为dirty_worktree风险、排除在范围外、要求验证者拒绝会覆盖用户更改的计划。拒绝误导性成功输出：通过的日志、子代理摘要和 grep 命中在验证者确认精确命令、工件与断言真正执行前都只是声明。

计划模板与 Todo 语法

scaffold-plan.mjs按固定顺序发出八大段落头，模板内容（full-workflow.md 与脚本PLAN_SECTION_HEADERS完全一致）：

# <slug> - Work Plan ## TL;DR (For humans) ## Scope ## Verification strategy ## Execution strategy ## Todos ## Final verification wave ## Commit strategy ## Success criteria

关键规则：

• Effort 恰好是一个带（band）：Quick（单次编辑、分钟级代理工作）、Short（一次聚焦变更、几个文件）、Medium（一个会话内的多文件功能）、Large（多波、一个长会话）、XL（多会话或架构工作）。绝不写小时或天数：被计数的 todo 行才是规模信号，任何写出的时长在用户看到计划前都会被改写成带；
• 每波目标 5-8 个 todo；少于 3 个（最终波除外）意味着切分不足；实现 + 测试 = 一个 todo；
• 每个 todo 携带：穷尽式 References（执行者无访谈上下文）、代理可执行的 Acceptance criteria、各带证据路径的 happy + failure QA 场景、一行 Commit、以及一行Recommended task executor category:——执行者遵循的路由裁决，附一行理由，使用 omo 分类词汇：quick（机械/单文件——每个可拆片段的默认）、unspecified-low（小杂项）、unspecified-high（标准多文件功能）、visual-engineering（前端/UI）、writing（文档）、git（git 操作）、deep（棘手调试或跨模块推理）、ultrabrain（一个真正困难的内聚问题，整体委派）。偏好把多数小 todo 按quick路由到并行波；当拆分会切断共享推理时，保持一个路由到deep/ultrabrain的 todo——绝不强制拆分共享同一洞察的部分。无 category 的 harness 按难度映射：quick/unspecified-low/writing/git = low，unspecified-high/visual-engineering = medium，deep/ultrabrain = high；
• HR6 后备检查：确认计划首个##标题是## TL;DR (For humans)，且其下每个标题都按模板顺序出现；
• ## TL;DR (For humans)最后填，让人类摘要总结真实计划而非意图；其中的 “Decisions I made for you” 块（UNCLEAR）或 “Decisions to sanity-check” 块（CLEAR）给用户否决权。

最终验证波

所有 todos 完成后并行运行，全部必须 APPROVE；呈现结果并等待用户明确 okay 后才宣布完成：F1 计划合规审计、F2 代码质量评审、F3 真实手动 QA、F4 范围保真。脚本在 scaffold-plan.mjs 中内置了这四项FINAL_VERIFICATION_ITEMS。

执行交接摘要的强制结构

每个“呈现计划摘要/简报”都按此结构交付（以用户语言，从完成后的计划文件推导——数行数，绝不估算）：(1) 本计划驱动什么（1-2 句）；(2) 终态（执行结束后会存在或行为不同的具体事物）；(3) 形态（多少阶段/波与多少任务：N 个实现 todo- [ ] N.+ F 个最终验证任务- [ ] F<n>.，加执行者类别构成，如 6xquick、2xunspecified-high、1xultrabrain）；(4) 超出请求的增补（探索浮现并折入、用户从未显式要求的每项，各带一行理由；“无”就写 none）；(5) 验证（最终验证波加关键 QA 场景/命令如何证明完成）；(6) 执行交接（通过本会话或新会话的/ulw-execute <plan-name>执行；介绍选项：--worktree <absolute-path>任务自有工作树（PR/分支工作必需）、--make-pr以 PR 交付（自动创建任务自有工作树）、--ship隐含--make-pr且持续工作直到 PR 被评审并合并）。

高精度评审：plan-reviewer 与有界收敛

评审机制与状态契约

在 omo-senpi，高精度评审是 PLAN-REVIEWER-ONLY：一轮 = 恰好一次原生plan-reviewer对完整计划文件的评审。Plan Reviewer 运行于 High 档，可能比其他代理耗时显著更长。一轮 = 恰好一次plan-reviewer评审，派发对象是完整计划文件（todos + TL;DR 都填好），路径为草稿中记录的精确plan_path。规则包括：

• 保持 Plan Reviewer 在飞并等待其终态结果：仅凭耗时绝不取消、复制、替换或视为失败；
• 裁决返回后，修复每个合格 blocker 并按有界收敛契约重新提交；不合格发现转为非阻塞 notes；
• 每轮都新开一个全新 plan-reviewer 会话；派发提示词只有计划路径——harness 强制规范契约并丢弃其余一切，plan-reviewer 派发不再适用字面替换；
• 向 plan-reviewer 发task_send被禁止并被 harness 拒绝；唯一重试是修计划后派发新的plan-reviewer；
• 达到上限仍未批准：停止，报告未决 blockers，询问用户——继续 / 接受 / 调整。

父会话在派发时把round_id、plan_sha256与派生的会话 id（回执）记录到草稿；完成时通过重新哈希活计划对照记录的plan_sha256、并把完成包的会话 id 与记录回执匹配来验证；任何不匹配或计划变更都将该轮终态化为 inconclusive 并要求一轮全新的 plan-reviewer 评审。

full-workflow.md 用三段 JSON 状态契约精确定义评审状态机：ulw-plan-review-request-state-contract（评审请求态：transition: replace、phase: review_requested、review_round_limit: 5）、ulw-plan-review-round-state-contract（轮次初始化态：带plan_sha256、review_round_id、round_status: active与完成 CAS 列表）、以及ulw-plan-review-lifecycle-state-contract（生命周期迁移表：launch → receipt → complete 的单射转换，launch_interrupted终态化为 inconclusive 并要求新一轮）。文件还规定了路径安全要求：plan_path必须等于.omo/plans/<validated-slug>.md，拒绝绝对路径、..与规范化漂移；以“打开工作区根目录描述符 → 逐段 no-follow 相对打开.omo、plans与最终文件 → 祖先必须是目录、最终必须是常规文件 → 只从该最终描述符读取字节计算plan_sha256”的方式绑定文件操作；平台无法保证该描述符链时返回INCONCLUSIVE，不用基于路径的 validate-then-open 检查替代。核心原则：绝不从聊天历史重建状态；压缩后从持久化的轮次与通道状态恢复——只派发pending、把搁浅的launching终态化、只等待匹配的in_flight完成、绝不变更终态通道。

有界收敛：评审必须终止

评审轮次上限为 5（仅显式用户请求才无限），批准后剩余项只有 notes 也计为批准。一条发现只有在其点名至少一个blocker_eligibility类别并给出具体证据时才可 BLOCK；其余发现——接受范围从未要求的推测性持久性、重放/崩溃恢复、schema、CLI 解析、状态机或加固问题——记录为非阻塞 notes，变成实现/测试工作，绝不扩展计划。第 1 轮后 blocker 台账冻结：后续轮次只验证已接受的台账 blockers、修复引入的回归、以及通过资格的新发现——绝不从头重新发现计划。修复应用能解决被引用 blocker 的最小编辑；评审与修复都不增长计划范围。ulw-plan-review-convergence-contract的 JSON 完整列出这些规则，包括五类 blocker 资格：显式需求或已接受决策、现有失败回归、可复现的破损流程、具体安全/数据丢失/兼容风险、外部 API 提供商或发布契约冲突。

交接前必须用同一套活路径 + SHA-256 校验复核计划并匹配已批准轮次的摘要；漂移使批准失效并开始新一轮。不得声称“高精度评审已完成”，除非回执存在、最终裁决是无条件批准、且最终活计划校验通过。

评审接收契约

ulw-plan-review-intake-contract规定评审者的只读访问纪律：first_action: read_exact_plan_path，读取机制为“打开工作区根再 openat 逐段 no-follow、fstat、读取、哈希”；pre_read_validation包含工作区相对规范化等价、目录描述符打开、逐段 no-follow、常规文件检查；forbidden_fallbacks为["search", "memory", "summaries", "alternate_files"]——任何漂移条件（读失败、路径不匹配、不安全路径、祖先描述符不匹配、摘要不匹配、运行时主目录不匹配、派发身份不匹配、回执身份不匹配、陈旧或不同工件、不完整检索）都返回INCONCLUSIVE，绝不搜索或使用其他工件。

停止规则：计划完成即停，绝不自我执行

SKILL.md 的停止规则是规划会话的终点定义：

• 计划文件存在、模板填满、每个 todo 都有引用 + 验收 + QA + commit、依赖矩阵一致、任何必需的高精度回执已记录：呈现交接说明（full-workflow.md Phase 4 交付格式），然后——CLEAR 且无review_required→ 问“开始还是先高精度评审”问题；CLEAR 且有review_required/ UNCLEAR → 报告评审结果——并停止。绝不自己开始执行；
• 简报已呈现且status: awaiting-approval已记录：等待。除非用户改变范围，否则不重新探索；
• 结束一次完成的规划会话前：运行 stance-calibration.md 中的收尾步骤——通过 memory 工具追加 0-2 条合格规划风格片段；memory 工具缺失时静默跳过。

full-workflow.md 还补充一条：两波研究后无新有用事实：停止探索，提交简报。而规划风格片段的记录有严格资格要求：只有用户显式选择/请求渲染器或陈述交互偏好（记为declared），或同一自发立场在 2+ 个不同分叉上出现（记为observed）时才记录；会话片段格式为- [YYYY-MM-DD] <context> - <observed behavior, one line>并携带src、model、pattern、confidence元数据。绝不存储分数、计数器、阈值、已定标志或归纳出的人设——泛化在读取时进行，原始片段不会过期而缓存摘要会。记忆文件位于system/human/planning-style.md（memory 工具，首个合格片段时惰性创建）。种子（seed）条目永远confidence: low，带完整溯源，措辞为假设（“appears to …”）而非结论；优先级为原生片段 > 用户显式陈述 > 种子，一旦有 2-3 条原生片段就停止参考种子。

与相邻技能的协同关系

ulw-plan 不是孤立运行。从仓库的技能目录（packages/omo-senpi/skills/）可以看到它处于一整套“ulw 家族”工作流中：mass-ulw 负责“mass ulw”关键词驱动的依赖序 DAG 编排；ultrawork 是绑定式 ultrawork 模式指令；ulw-loop 与 ulw-research 分属执行循环与探索研究。skill-pointers 组件在 skill-pointers/index.ts 中对mass-ulw（MASS_ALIAS = (?:mass[\s-]*ulw|ulw[\s-]*mass|mulw|meth)）与ulw-plan（\bulw[\s-]*plan\b）分别注入指针，说明“mass ulw”触发编排技能、“ulw plan”触发规划技能——规划在前、按依赖序的图执行在后，正是从“模糊请求”到“决策完备计划”再到“DAG 执行”的完整链路。而ulw-plan自己产出的计划最终通过/ulw-execute <plan-name>交接给 worker，执行属于独立的 worker 会话，规划者永远停留在规划侧。

结语：一份“零访谈执行”计划是如何炼成的

把整个技能串起来看，ulw-plan 的设计哲学可以用一条主线概括：用一次强制的、结构化的规划会话，换取下游执行会话的零访谈与零判断。开场宣言锁定人设与不实现边界；意图路由决定“问用户还是研究出答案”；stance 校准决定“怎么问”；脚手架脚本保证工件的持久化恢复点与规范语法；审批门把“写计划”与“批准计划”严格分离；plan-reviewer 高精度评审配合 5 轮有界收敛契约，为模糊意图下的默认值选择补上对抗性质量网；最终验证波与停止规则确保计划在交付时已被完整校验。从 SKILL.md 到 scaffold-plan.mjs 的实现，每一层都在回答同一个问题：如何在不让实现者与用户再次对话的前提下，交付一份可以直接开工、且质量可被独立验证的计划。

【免费下载链接】oh-my-openagentOmO: Just type "mass ulw" keyword with your prompt. Now you are the master of graph engineering.项目地址: https://gitcode.com/gh_mirrors/oh/oh-my-openagent