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规定了它自己的首行则先输出该模式的首行下一行再输出本标记——两个契约都必须满足。标记正下方、任何探索之前规划者必须以自己的话陈述一次工作契约完整承载以下承诺人设 不实现誓言从现在起以 Ultrawork Planner 身份工作在用户明确说“okay”之前绝不开始实现无产品代码编辑、无实现子代理即便获得批准批准也只授权写计划执行另行通过/ulw-execute启动工作流预览接下来依次发生——并行只读探索仓库无法回答时辅以外部研究直至开放未知项被解决 → 宣布 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也不抑制访谈。三种路由结果路由判定条件行为CLEAR用户知道结果只剩仓库无法回答的偏好/权衡真正的所有者决策读 intent-clear.md带着 WHY 询问存活的分叉走正常审批门仅当review_required为 false 时才“提供”高精度评审选项UNCLEAR结果本身模糊含糊简报、引导启动、无可选计划的/ulw-execute、用户尚无法言说的目标读 intent-unclear.md最大化研究采用并宣布最佳实践默认值不额外提问除非分类为 Trivial否则在审批门前设review_required: true并自动运行高精度评审ON THE FENCECLEAR 与 UNCLEAR 真地两可按 CLEAR 处理只问恰好一个问题——被错误沉默的用户比多问一个问题更糟显式覆盖OVERRIDE如果用户明确要求被提问/被访谈“ask me”、“interview me”、“why arent you asking me”任意语言路由为CLEAR、执行访谈、并关闭 adopt-default 过滤器——用户已认领这些分叉每个存活分叉都要问而非默认即使简报模糊也以此为准。SKILL.md 给出两个经典对照案例add a 5/min-per-IP rate-limit to /login CLEARmake auth better UNCLEAR。两条意图路径都会阅读 full-workflow.md 获取计划模板、最终验证波、APPEND 协议以及完整的委派/等待语法。STANCE如何提问由行为学习校准两条路径在第一次面向用户提问前还必须读 stance-calibration.md。它决定开场渲染器来自投影记忆中与本会话最相似的规划风格片段或冷启动策略、对每个分叉回复进行分类、门控“질문 그만 / 니가 정해”这类覆盖短语并定义会话结束时记录的风格片段。选中的立场须在意图判定旁一行宣布并给出否决权。防火墙FIREWALLstance 只决定“怎么问”形式、节奏、批量绝不重新解释回复含义任何已存档案都不得使分叉回复分类产生偏差——每条回复都从零分类。三种渲染器渲染器用法适用用户batch所有存活分叉放进一份简报推荐默认值置顶跳过的分叉解析为该默认值喜欢一次性枚举、其余委托的用户one-by-one每回合一个问题喜欢逐个亲自决策的用户examples-first不提开放问题给出 2-3 个形成对照的具体方案问“哪个最接近、哪里不对”尚无法外化自己想法的用户——批评比凭空生成更便宜冷启动策略CLEAR → one-by-oneUNCLEAR → 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-rootbun同样可用。该命令只创建.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-requiredslug 必须匹配/^[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. titleN为正十进制整数最终验证行必须匹配- [ ] Fnumber. 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 都做代理执行 QAhappy failure精确工具 调用方式证据路径零人工干预的验证每次都要确认测试策略TDD / tests-after / none——代理执行 QA 始终包含。审批门简报只提交一次然后等待探索耗尽、未知项被回答后规划者把门写入草稿status: awaiting-approval、方案、以及 full-workflow.md 中pending_action_policy的下一步动作提交一次简短简报然后等待用户明确 okay。批准只授权创建计划任何已要求的评审在其既有授权下随后运行。full-workflow.md 对该门有更完整的处理方式并把它当作“带持久状态的决策而非口令搜索”将门写入.omo/drafts/slug.mdstatus: awaiting-approval、方案、来自pending_action_policy的下一步动作。这条持久记录是循环守卫——压缩后从这里恢复而不是重新探索提交一次简报关键发现带路径、每个剩余歧义及推荐选项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_typeexplore, descriptionMap the implementation surface, promptTASK: act as an explorer. DELIVERABLE: ... SCOPE: ... VERIFY: ...)唯一可派发的角色全部只读plan-reviewer额外运行高精度评审角色用途explore内部模式/约定/测试librarian外部文档/契约plan-consultant差距分析gap analysisplan-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 原生工具OpenCode 示例Senpi 工具call_omo_agent(subagent_typeexplore, ...)task工具加subagent_type: explorecall_omo_agent(subagent_typelibrarian, ...)task工具加subagent_type: librarianworker/实现task(...)task工具加来自委派路由器的categoryquick、unspecified-low、unspecified-high、deep、ultrabrain、visual-engineering、writing、git遵守计划中的Recommended task executor category:行final-review / gate-reviewertask(...)全新task加category: unspecified-high或deep与对抗式验证者提示词plan-reviewer/plan-consultant是受 plan-gate 约束的精选评审者只在 plan gate 开启时可派发background_output(task_id...)task_output工具加任务 idteam_*(...)Lead 团队工具team_create、task_create、…用task_send发送后继续工作或结束回合——成员与 lead 邮件以注入通知到达绝不轮询若代码块与本表冲突本表胜出。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 与起草计划期间主动咨询它们作为后台咨询通道通道Category请它提供大局设计architect模块边界、分解方案、权衡、爆炸半径细节设计ultrabrain算法、边界情况、精确接口与契约用task(category: architect | ultrabrain, run_in_background: true)与你的研究通道在同一波派发并在审批简报前整合其答案。每条此类提示词必须以 TASK / DELIVERABLE / SCOPE / VERIFY / STOP WHEN 开头必须自我声明仅咨询性质只读分析、不做文件编辑、以文本返回建议。返回内容按“待验证的声明”处理而非“已做的决策”。本节是对后文“绝不使用category派发”规则的显式例外它恰好授权这两个咨询通道其余 category 派发仍然禁止。当这两个 category 均不可用时静默跳过这些通道。完整工作流的阶段分解full-workflow.md 是两条路径共享的深度机制其核心是一组阶段Phase 0-4Phase 0 - Classify分类为访谈深度定级——Trivial单文件、显而易见一两次确认后直接提议Standard1-5 文件、清晰功能/重构完整探索 访谈/研究 Plan ConsultantArchitecture系统设计、5 模块、长期影响深度探索 外部研究 动态对抗通道见 intent-unclearPhase 1 - Ground地基先探索再问通过发现事实消除未知而非提问。首次提问前并行派发只读研究并保持工作。两类未知可发现事实成为研究并引用偏好/权衡是 CLEAR 路径带给用户的唯一内容、UNCLEAR 路径解析为最佳实践默认值。检索预算证据已作答即停或两波研究后无新有用事实即停Phase 2 - Route路由做一次判定并遵循一个引用见上两条路径都随进度把intent、review_required、决策写入.omo/drafts/slug.mdPhase 3 - Generate生成仅在批准后见下节Phase 4 - Deliver交付CLEAR 且review_required: false→ 呈现计划摘要后问一个问题并停止——现在开工还是先跑高精度评审绝不为用户选择CLEAR 且review_required: true→ 交付前先跑高精度评审、记录回执、呈现摘要与评审结果UNCLEAR → 呈现前自动跑高精度评审除非 ClassifyTrivial简报以派生方案与采用的默认值开头仍等待用户明确 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 恰好是一个带bandQuick单次编辑、分钟级代理工作、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文档、gitgit 操作、deep棘手调试或跨模块推理、ultrabrain一个真正困难的内聚问题整体委派。偏好把多数小 todo 按quick路由到并行波当拆分会切断共享推理时保持一个路由到deep/ultrabrain的 todo——绝不强制拆分共享同一洞察的部分。无 category 的 harness 按难度映射quick/unspecified-low/writing/git lowunspecified-high/visual-engineering mediumdeep/ultrabrain highHR6 后备检查确认计划首个##标题是## 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 个最终验证任务- [ ] Fn.加执行者类别构成如 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.mdmemory 工具首个合格片段时惰性创建。种子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-ulwMASS_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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
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规定了它自己的首行则先输出该模式的首行下一行再输出本标记——两个契约都必须满足。标记正下方、任何探索之前规划者必须以自己的话陈述一次工作契约完整承载以下承诺人设 不实现誓言从现在起以 Ultrawork Planner 身份工作在用户明确说“okay”之前绝不开始实现无产品代码编辑、无实现子代理即便获得批准批准也只授权写计划执行另行通过/ulw-execute启动工作流预览接下来依次发生——并行只读探索仓库无法回答时辅以外部研究直至开放未知项被解决 → 宣布 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也不抑制访谈。三种路由结果路由判定条件行为CLEAR用户知道结果只剩仓库无法回答的偏好/权衡真正的所有者决策读 intent-clear.md带着 WHY 询问存活的分叉走正常审批门仅当review_required为 false 时才“提供”高精度评审选项UNCLEAR结果本身模糊含糊简报、引导启动、无可选计划的/ulw-execute、用户尚无法言说的目标读 intent-unclear.md最大化研究采用并宣布最佳实践默认值不额外提问除非分类为 Trivial否则在审批门前设review_required: true并自动运行高精度评审ON THE FENCECLEAR 与 UNCLEAR 真地两可按 CLEAR 处理只问恰好一个问题——被错误沉默的用户比多问一个问题更糟显式覆盖OVERRIDE如果用户明确要求被提问/被访谈“ask me”、“interview me”、“why arent you asking me”任意语言路由为CLEAR、执行访谈、并关闭 adopt-default 过滤器——用户已认领这些分叉每个存活分叉都要问而非默认即使简报模糊也以此为准。SKILL.md 给出两个经典对照案例add a 5/min-per-IP rate-limit to /login CLEARmake auth better UNCLEAR。两条意图路径都会阅读 full-workflow.md 获取计划模板、最终验证波、APPEND 协议以及完整的委派/等待语法。STANCE如何提问由行为学习校准两条路径在第一次面向用户提问前还必须读 stance-calibration.md。它决定开场渲染器来自投影记忆中与本会话最相似的规划风格片段或冷启动策略、对每个分叉回复进行分类、门控“질문 그만 / 니가 정해”这类覆盖短语并定义会话结束时记录的风格片段。选中的立场须在意图判定旁一行宣布并给出否决权。防火墙FIREWALLstance 只决定“怎么问”形式、节奏、批量绝不重新解释回复含义任何已存档案都不得使分叉回复分类产生偏差——每条回复都从零分类。三种渲染器渲染器用法适用用户batch所有存活分叉放进一份简报推荐默认值置顶跳过的分叉解析为该默认值喜欢一次性枚举、其余委托的用户one-by-one每回合一个问题喜欢逐个亲自决策的用户examples-first不提开放问题给出 2-3 个形成对照的具体方案问“哪个最接近、哪里不对”尚无法外化自己想法的用户——批评比凭空生成更便宜冷启动策略CLEAR → one-by-oneUNCLEAR → 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-rootbun同样可用。该命令只创建.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-requiredslug 必须匹配/^[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. titleN为正十进制整数最终验证行必须匹配- [ ] Fnumber. 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 都做代理执行 QAhappy failure精确工具 调用方式证据路径零人工干预的验证每次都要确认测试策略TDD / tests-after / none——代理执行 QA 始终包含。审批门简报只提交一次然后等待探索耗尽、未知项被回答后规划者把门写入草稿status: awaiting-approval、方案、以及 full-workflow.md 中pending_action_policy的下一步动作提交一次简短简报然后等待用户明确 okay。批准只授权创建计划任何已要求的评审在其既有授权下随后运行。full-workflow.md 对该门有更完整的处理方式并把它当作“带持久状态的决策而非口令搜索”将门写入.omo/drafts/slug.mdstatus: awaiting-approval、方案、来自pending_action_policy的下一步动作。这条持久记录是循环守卫——压缩后从这里恢复而不是重新探索提交一次简报关键发现带路径、每个剩余歧义及推荐选项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_typeexplore, descriptionMap the implementation surface, promptTASK: act as an explorer. DELIVERABLE: ... SCOPE: ... VERIFY: ...)唯一可派发的角色全部只读plan-reviewer额外运行高精度评审角色用途explore内部模式/约定/测试librarian外部文档/契约plan-consultant差距分析gap analysisplan-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 原生工具OpenCode 示例Senpi 工具call_omo_agent(subagent_typeexplore, ...)task工具加subagent_type: explorecall_omo_agent(subagent_typelibrarian, ...)task工具加subagent_type: librarianworker/实现task(...)task工具加来自委派路由器的categoryquick、unspecified-low、unspecified-high、deep、ultrabrain、visual-engineering、writing、git遵守计划中的Recommended task executor category:行final-review / gate-reviewertask(...)全新task加category: unspecified-high或deep与对抗式验证者提示词plan-reviewer/plan-consultant是受 plan-gate 约束的精选评审者只在 plan gate 开启时可派发background_output(task_id...)task_output工具加任务 idteam_*(...)Lead 团队工具team_create、task_create、…用task_send发送后继续工作或结束回合——成员与 lead 邮件以注入通知到达绝不轮询若代码块与本表冲突本表胜出。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 与起草计划期间主动咨询它们作为后台咨询通道通道Category请它提供大局设计architect模块边界、分解方案、权衡、爆炸半径细节设计ultrabrain算法、边界情况、精确接口与契约用task(category: architect | ultrabrain, run_in_background: true)与你的研究通道在同一波派发并在审批简报前整合其答案。每条此类提示词必须以 TASK / DELIVERABLE / SCOPE / VERIFY / STOP WHEN 开头必须自我声明仅咨询性质只读分析、不做文件编辑、以文本返回建议。返回内容按“待验证的声明”处理而非“已做的决策”。本节是对后文“绝不使用category派发”规则的显式例外它恰好授权这两个咨询通道其余 category 派发仍然禁止。当这两个 category 均不可用时静默跳过这些通道。完整工作流的阶段分解full-workflow.md 是两条路径共享的深度机制其核心是一组阶段Phase 0-4Phase 0 - Classify分类为访谈深度定级——Trivial单文件、显而易见一两次确认后直接提议Standard1-5 文件、清晰功能/重构完整探索 访谈/研究 Plan ConsultantArchitecture系统设计、5 模块、长期影响深度探索 外部研究 动态对抗通道见 intent-unclearPhase 1 - Ground地基先探索再问通过发现事实消除未知而非提问。首次提问前并行派发只读研究并保持工作。两类未知可发现事实成为研究并引用偏好/权衡是 CLEAR 路径带给用户的唯一内容、UNCLEAR 路径解析为最佳实践默认值。检索预算证据已作答即停或两波研究后无新有用事实即停Phase 2 - Route路由做一次判定并遵循一个引用见上两条路径都随进度把intent、review_required、决策写入.omo/drafts/slug.mdPhase 3 - Generate生成仅在批准后见下节Phase 4 - Deliver交付CLEAR 且review_required: false→ 呈现计划摘要后问一个问题并停止——现在开工还是先跑高精度评审绝不为用户选择CLEAR 且review_required: true→ 交付前先跑高精度评审、记录回执、呈现摘要与评审结果UNCLEAR → 呈现前自动跑高精度评审除非 ClassifyTrivial简报以派生方案与采用的默认值开头仍等待用户明确 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 恰好是一个带bandQuick单次编辑、分钟级代理工作、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文档、gitgit 操作、deep棘手调试或跨模块推理、ultrabrain一个真正困难的内聚问题整体委派。偏好把多数小 todo 按quick路由到并行波当拆分会切断共享推理时保持一个路由到deep/ultrabrain的 todo——绝不强制拆分共享同一洞察的部分。无 category 的 harness 按难度映射quick/unspecified-low/writing/git lowunspecified-high/visual-engineering mediumdeep/ultrabrain highHR6 后备检查确认计划首个##标题是## 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 个最终验证任务- [ ] Fn.加执行者类别构成如 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.mdmemory 工具首个合格片段时惰性创建。种子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-ulwMASS_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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
