用途：omh-ralplan-driver 是 omh-ralplan 的配套技能，供担任编排者（orchestrator）的角色使用。omh-ralplan 由 Planner、Architect、Critic 三类 worker 加载，描述它们在每次 delegate_task 内做什么；本技能描述调度方做什么：准备、派发、蒸馏、复核。两者读者与职责不同，不应合并，以免 worker 上下文被调度手册占用。
主要能力：提供五步编排手册。一是在派发前先确立原则（如项目根目录 PRINCIPLES.md，≤15 条，并纳入每个子代理必读）。二是起草上下文包 docs/design/<domain>/context.md，包含设计问题、产物类型声明、子维度、约束、范围外、必读（仅绝对路径）、争议问题（6–8 个）、META 问题（“这些子维度对吗？”）以及完成标准。三是第一轮按 Planner→Architect→Critic 严格顺序执行，各自写出命名产物（stance-planner.md、review-architect.md、review-critic.md）；仅当有评审未 APPROVE 时进入第二轮，Planner 修订、Architect 与 Critic 并行复审，文件加 -v2 后缀，保留第一轮产物作为过程记录；三个 APPROVE 即收敛，否则最多三轮并附注意事项。四是蒸馏：去掉面向评审的“Round 2 response map”，写成 stance.md（若为需求型产物则写 requirements.md），并在 .omh/plans/ralplan-<instance-id>.md 写共识摘要。五是编排者复核，产出给用户看的 brief.md（决策优先，约 1–2 页）与存档用的 <orchestrator>-review-deep.md。
适用场景：当工作存在多种合理分解、需要跨子代理执行承载性原则、存在编排者单独容易遗漏的横切关注点，或用户否则会陷入逐轮提案循环时使用。单文件、单决策或显而易见的任务不宜使用；目标含糊时应先用 omh-deep-interview。
限制与注意事项：资料列出 P1–P26 编号陷阱，包括不要在派发前引用尚未写出的文件、超时报告不等于未完成（应以磁盘产物为准）、上下文体积增长快、Critic 必须被授权质疑框架、争议问题只做种子而非穷举、优先具体反提案、用反事实顺从测试检验采纳是否基于原则、状态文件不入 git 而计划文件入库、派发前核验本地源码“地面真相”的新鲜度、派发前与用户迭代上下文包、不要重开用户已定的问题、派发含路径目标前先确定文件系统布局等。资料未提供安装命令、收费、平台与效果数据。