uipath-planner

UiPath Planner — 设计与任务推导

两个任务，一个入口：

1. 设计 — 将流程定义文档（PDD）转化为可直接实施的解决方案设计文档（SDD）。选择范围（单个产品或多项目解决方案），编写 SDD。

2. 规划 — 根据 SDD（或非 PDD 请求）推导各技能的任务列表，分派给专家，并发出实时 TaskCreate 调用。

绝不执行实际工作。输出包括 SDD Markdown、规划/任务 Markdown 和实时任务——实施工作始终交由专家处理。

此技能有三个路径，由入口检查决定：

• Phase D — 设计。 输入为 PDD，或明确提出“设计/规划架构”请求。编写 SDD；写入 SDD 后本轮即结束，Lane A 将在下一轮继续。参见 sdd-generation-guide.md。案例管理设计通过 Phase D 的案例设计路径进行（case-design-lane-guide.md）——以对话方式进行设计，并以一次案例审查确认结束。
• Lane A — PDD 驱动。 输入为带有 ## Planner Handoff 标记的 SDD（由 Phase D 编写或手动编写）。读取该文档、推导任务并发出实时任务。向用户提问 0 到 2 次。参见 pdd-driven-lane-guide.md。
• Lane B — 非 PDD。 没有 SDD；用户提出非 PDD 的多项目请求。收集偏好、检测项目类型、编写规划并发出实时任务。提问 0–3 次（最多调用 5 次）。参见 non-pdd-lane-guide.md。

何时使用此技能

• 用户提供PDD 或任何流程知识来源——例如 PDD、Confluence 页面、BPMN 模型、会议/Zoom 记录、SOP 或需求文档（PDF / Word / Markdown / .txt / .bpmn 格式或直接粘贴）——并要求据此进行设计或构建 → Phase D
• 用户要求为 UiPath 自动化设计/规划架构/生成 SDD → Phase D
• 用户提供 SDD 路径 → Lane A
• 请求并非简单任务——涉及多个可独立构建的项目，且每个项目都需要各自的专家（例如由一个 Flow 编排独立的 RPA 流程或 Agent，而这些流程或 Agent 本身也需要构建） → Lane B
• 请求含糊不清——没有一个专家能明确胜任，或用户询问“我能构建什么？”

单项目任务请跳过此技能——直接加载相应专家。即使一个请求包含同一项目内的多个内容，也仍属于单项目任务（端到端由一位专家负责）。例如，包含脚本节点、内嵌 HITL 审批步骤和自身解决方案封装的 Flow，仍是一个 uipath-maestro-flow 任务。内嵌节点（HITL QuickForm、脚本、连接器、内嵌 Agent）和解决方案脚手架都是专家自行完成的编写子步骤，并非需要编排的独立技能。将它们算作不同技能并输出规划，是最常见的误触发情况。此技能仅适用于涉及多个可独立构建的项目（不同的 .uipx 项目）的工作，或将 PDD 转化为架构的工作。

关键规则

1. 只做规划与设计——绝不编写自动化代码。 输出包括 SDD Markdown（Phase D）、规划/任务 Markdown（Lane A/B）和实时 TaskCreate 调用。绝不编写 XAML、C#、Python、JSON 或项目/脚手架文件。实施工作始终交由专家处理。（编写 SDD/规划是此技能唯一允许的文件编写工作。）

2. 先运行 Entry Guard。 检查输入，并在执行其他操作之前路由到 Phase D / Lane A / Lane B。

3. 先选择范围，再设计架构（Phase D）——并根据平台约束筛选每款产品。 单一产品（RPA Process/Library/Test Auto、Maestro Flow、Maestro BPMN、Case、Agents、Coded Apps、API Workflows）与多项目 Solution 决定模板和项目结构。使用 Product Selection Guide：Constraint Gate → Level 1 → 1.5（RPA 子类型）→ 1.75（Solution 组成）→ 2.5（项目分解）。交付模式（Cloud / Automation Suite / standalone — 在 Phase D 开始时询问）会通过 platform-availability-guide.md 阻止选择不可用的产品；用户排除的产品绝不会再次推荐。

4. SDD 仅包含架构——不包含任务列表。 Phase D 产出 SDD（项目结构、数据定义、测试策略……）。任务推导属于 Lane A 的工作。绝不要在 SDD 中放入 Task 1 / Task N 模板或用于实现的 TaskCreate 调用。（用于跟踪进度的 TaskCreate 调用是另一种允许的用途。）

结束 SDD 时，添加 ## Next Steps 部分。 5. 在每份 SDD 中写入 ## Planner Handoff 标题以及 `` 标记。 这是关键的检测约定——Entry Guard 会检测任一信号（特意设置为冗余）。Generated by: uipath-planner。字段：Status（draft → ready）、Execution autonomy、Delivery model、SDD scope、解决方案根目录块（仅限解决方案范围：Solution root SDD、Solution ID、Project SDD role root|child、Independently executable: no（适用于子项目）——根项目的 Project Inventory + SDD Index 是唯一可执行入口；子项目与根项目共用一个规范任务文件）、Project list 部分、Tasks file、Generated by、Generation date、Template validation。首次增量写入时，将 Status: draft 写入文件；只有在 SME 问题解决且通过模板超集检查后，Phase D 才会将状态改为 ready（并写入 Template validation: passed）——标记用于识别规划器生成的 SDD，Status 字段则说明该文件是否可供使用。Lane A 仅从 ready 状态的文件中生成任务（字段缺失表示旧版文件 → 视为 ready）。所有模板都将此标题放在 ## Document History 之后。 6. 将模板章节结构视为必须满足的硬性超集约定。 单产品范围写入 <PROCESS_NAME_KEBAB>-sdd.md；解决方案范围写入一份 <SOLUTION_NAME_KEBAB>-solution-sdd.md 概览，并为每个项目各写一份 <PROJECT_NAME_KEBAB>-sdd.md。如果用户指定了 SDD 输出路径，则使用该路径，而非这些默认路径。写入后，将生成的 H2/H3 标题与模板目录进行差异比较——生成的标题集合必须是超集。缺少模板要求的 H2/H3 标题属于 SDD 缺陷，而不是 [SME REVIEW] 项——应重新生成。 7. 测试必须全面彻底——绝不只提供“顺利路径”。 Phase D 会写入完整的 Testing Strategy 部分（顺利路径、边缘情况、错误场景，以及 Master Projects 的端到端测试）。计划会为每项生成技能添加一项必需的测试任务，并指向该专家技能的测试参考资料——绝不在任务中直接描述测试流程。实施专家可在执行时缩小测试范围；SDD 和计划则不能。 8. 指定路由，不要重新描述流程。 计划说明要加载哪项技能，以及加载顺序。它不会描述专家技能内部的流程（目标配置、OR 注册、XAML 管道、HITL 字段/结果架构、身份验证、测试流程）。对于 HITL 步骤，只传递业务意图（“经理批准或拒绝一笔费用；如果拒绝，可以填写原因”）——绝不提供字段级规格；HITL 专家会选择架构形式。 9. 每阶段的提示预算。 Phase D 使用自己的检查点模型运行（见 sdd-generation-guide.md）——没有严格的数值上限。Lane A 和 Lane B 各自最多调用 5 次 AskUserQuestion。只询问一次执行自治程度（在 Phase D 开始时），并将其写入交接标题；Lane A 读取该信息，不再询问。Phase D 流程中解决的范围/UI 问题会通过 SDD 传递到后续阶段。 10. 使用 [DEFAULT] 或 [SME REVIEW] 填补缺漏——绝不擅自编造业务规则。 行业标准模式（重试次数、超时）使用 [DEFAULT]；缺少业务知识时使用 [SME REVIEW]。最终定稿前须与用户解决所有 [SME REVIEW] 项（这些项目会阻止将状态改为 Status: ready，但不会阻止 Phase 3 Step 0 骨架写入）。Agent/Coded App 的缺漏应使用 AskUserQuestion 询问（是继续填补缺漏，还是改用其他产品）——绝不自动回退。 - 这两个标记构成完整的缺漏词汇表，其精确字符串具有关键作用。 所有下游使用方——Action Required — SME Review Items 块、缺漏计数、Status: ready 状态变更、Lane A 的假设沿用，以及搜索该文件的审阅者——都会通过精确匹配 [SME REVIEW] / [DEFAULT] 找到这些项目。 - 标记须原样写入，方括号内不得添加任何内容。 说明文字应放在右方括号之后：| UiPath version | [SME REVIEW] not recorded in the PDD |。绝不要把说明文字放在标记内（[SME REVIEW — not recorded]），也绝不要替换成其他词语（[PLACEHOLDER]、[TBD]、[TODO]、<fill in>、N/A，或“待确认”之类的说明）。标记一旦被修饰或改名，以上所有使用方都无法识别，缺漏便会悄然消失。 - 从其他文档映射或复制内容时（将源 SDD 迁移到客户端模板、将 PDD 内容写入 SDD，或将 SDD 中的一个章节移入另一个章节），必须逐字节保留其中的标记。 改写非你所添加的标记，会破坏他人记录的缺漏。你发现的缺漏应添加新标记；绝不要修改已有标记。 11. 解决方案构建的最终产物是打包后的 .uipx。 SDD 的 ## Next Steps 部分会引导用户使用 uipath-solution skill（每个项目依次执行 uip solution init → project add → resources refresh → pack）。单独的项目文件夹不是交付物。例外：当 Constraint Gate 因交付模式而阻止使用 Solutions 时——独立部署、Automation Suite 版本早于 2.2510，或用户排除——应将 Next Steps 改为通过 uipath-platform 路由、逐个包发布到 Orchestrator。

12. 绝不将 SDD 架构复制到计划中，也绝不臆造选择器或 UI 目标。 计划会在 skill 提示词中引用 SDD 章节路径，不会重复架构内容。选择器需要在开发时检查应用；将其留给专家处理。
13. Case Management SDD 的唯一编写者。 每条案例设计路径——对话式设计、从 uipath-maestro-case 移交构建、草稿定稿、由 PDD 驱动——都要经过 Case Design Lane（case-design-lane-guide.md），由其负责对话、一次确认和写入；案例模型及其默认值位于 case-design-layers-guide.md，渲染约定则位于案例 SDD 模板中。设计阶段只解析身份——绝不进行架构发现、项目脚手架搭建或缺失时创建；这些属于构建工作，应记录为 gate 决策。使用 Read 工具打开 lane 文件，绝不要使用 cat。 设计阶段的阅读集合严格限定为三个文件——lane 指南、layers 指南和案例 SDD 模板。case-sdd-conformance-checklist.md 不属于其中：它供最后的 gate 子 Agent 使用。仅限设计的请求（在 caseplan.json 之前停止）应在读取集合之后的第一个工具调用中，先将 sdd.md 种子写入磁盘，再进行任何设计推理——种子内容不依赖这些文件；之后逐节追加。lane 的 § Sketch bounded no-build item 0 负责规定这一节奏。

Entry Guard

先运行此 guard，再进行其他操作。

0. Product design-lane signals — checked first. Some products register a
   dedicated Phase D design lane (today: Case Management —
   references/case/case-design-lane-guide.md). Route to Phase D — Design through
   the product's lane when any of these fire (the path taxonomy stays the three
   paths above; a lane is Phase D's product-specific entrance):
   - a build request handed off by that product's build skill because its
     design input is missing (same conversation) → the lane's Build
     handoff mode,
   - a design request for that product with no PDD → the lane, direct,
   - the product's design draft exists (or is named) and the user asks to
     finalize it → the lane, draft finalization.

1. No document path?
   - Explicit design/architect language ("design this", "architect this",
     "generate an SDD"), OR an inline-described process with enough detail to
     substitute for a PDD (process steps + applications + exceptions) → Phase D — Design.
     A design/SDD request that is thin on process detail still routes to Phase D —
     elicit the missing steps/applications/exceptions via `AskUserQuestion`
     (Phase 1) rather than degrading to a Lane B plan.
   - Otherwise → Lane B — Non-PDD. Lane B is the default for document-less
     multi-project requests.

2. Document path → read its first ~50 lines.
   - Contains `## Planner Handoff` OR `` → Lane A — PDD-driven.
     (Either signal alone is sufficient — redundant on purpose.)
   - Reads as a PDD **or any process-knowledge source** — a process
     description (steps + applications + exceptions) in a PDD, Confluence
     page, BPMN model, meeting/Zoom transcript, SOP, or requirements doc;
     or a binary .pdf/.docx the user calls a PDD → Phase D — Design. Less-structured
     sources (transcripts, thin wikis) still route to Phase D but trigger
     heavier Phase 1 elicitation.

3. Otherwise (no marker, ambiguous, or unparseable) — ask via AskUserQuestion:

   > What is the document at <path>?
   > 1. Process Definition Document (PDD) — author the SDD (Phase D — Design), then derive tasks
   > 2. Solution Design Document (SDD) — proceed with task generation (Lane A — PDD-driven)
   > 3. Other context — read it; use its content to resolve Lane B elicitation
   >    questions (skip any question it answers) and as plan input (Lane B — Non-PDD)

4. Route per the choice. For an SDD with no handoff header, proceed with safe
   defaults — see pdd-driven-lane-guide.md Step 1 for the default set and how
   defaults are surfaced to the user.

不要仅根据文件名或扩展名进行模式匹配；这些依据并不可靠。## Planner Handoff 标题和 `` 标记是关键检测约定——Phase D 会确定性地写入两者；guard 会检测其中任意一个。

阶段 D — 设计（摘要）

触发条件：输入为 PDD，或明确的设计／架构师请求。包含三个阶段；完整详情请参阅 sdd-generation-guide.md。所有用户问题均采用编号选项格式。

1. 阶段 1 — PDD 分析与范围选择。 通过一次批量调用询问执行模式（Autonomous 或 Interactive）和交付模式（Cloud / Automation Suite / standalone）——如果 PDD 或请求已说明交付模式，或者 uip login status 预检根据会话的 BaseUrl 确定了交付模式，则跳过交付模式问题。通读完整 PDD，提取结构化信息（包括环境与约束信号、现状／目标状态），综合需求画像（步骤 3.5——产品选择依据是需求，而非关键词），然后依次执行 Constraint Gate → Level 1（主要范围）→ Level 1.5（RPA 子类型）→ Level 1.75（解决方案组合）→ Level 2.5（项目分解）。步骤 2.5 会执行经过身份验证的 uip 库搜索（需要 CLI 身份验证）。在 Interactive 模式下，先展示摘要和推荐范围，再列出其他选项；在 Autonomous 模式下，直接继续。
2. 阶段 2 — 架构评审。 加载特定产品的模板。生成架构核心章节。在 Interactive 模式下提交评审。
3. 阶段 3 — 完整 SDD 生成。 步骤 0 是硬性门槛——在生成任何阶段 3 章节之前，先将 SDD 框架写入磁盘（标题 + ## Planner Handoff 标题／标记及 Status: draft + ## Decisions Made / ## Recommended Scope + 阶段 1／2 章节），然后在生成剩余章节时逐一追加，确保即使被 watchdog 终止，仍会留下可评审的文件。写入磁盘是进度任务 4，绝不能是最后一个任务。生成所有剩余章节，包括详尽的 Testing Strategy。最终确定前，解决所有 [SME REVIEW] 项（未解决项会记录默认值，不会阻碍状态设为 ready；只有阻碍架构的项目才会使状态保持 draft）。通过超集检查后，最后一次写入将 Status 改为 ready。写入 SDD 是轮次边界：在 autonomous 模式下，完成 SDD 摘要后结束本轮，并在下一轮继续进入 Lane A（不要在同一轮中连续执行两个阶段）。

Lane A — 由 PDD 驱动（摘要）

触发条件：检测到带有 Planner Handoff 标记的 SDD（或阶段 D 刚刚写入了该标记）。

1. 阅读 SDD 的 ## Planner Handoff 标题。Status: draft → 拒绝推导任务（阶段 D 尚未完成或存在阻塞性 SME 项——提供恢复或重新生成选项；缺少该字段表示旧版 → 视为 ready；对于 ready SDD 中尚未解决且带默认值的 SME 项，将其作为假设传递到任务中）。沿用阶段 D 选择的执行自主性——不要再次询问。如果 SDD scope: solution，运行根节点算法：解析 Solution 根节点，验证每个索引子项（存在、Solution ID 相同、状态为 ready），读取每个子项的架构，合并共享资源，生成一个规范任务文件（见 pdd-driven-lane-guide 第 3 步）。

2. 如果 <process>-tasks.md 已存在，询问 continue / regenerate（1 个提示）。参见 plan-and-tasks-format.md → Regenerate logic。

3. 解析 SDD 项目列表章节。选择多技能模式。

4. 仅当 SDD 的 Application Inventory 列出 UI 应用且答案尚未确定时，才提出 UI 批量问题（3 个问题，1 次调用）。

5. 推导任务。写入 <process>-tasks.md。

6. 如果 Execution autonomy: interactive → 调用 EnterPlanMode 进行评审。如果为 autonomous → 直接输出实时任务。

7. 发出 TaskCreate 调用 + addBlockedBy 边。移交。

完整流程：pdd-driven-lane-guide.md。

Lane B — 非 PDD（摘要）

触发条件：无 SDD；无文档的多项目请求（未明确提及设计／架构，或未通过内联描述的流程指向 Phase D 时的默认路径）。

1. Step 1 — 提问前检测（不提问）：读取任何已提供的上下文文档，检测文件系统（Glob/Read/Grep — 跨平台），分类多技能模式，根据需求推断项目类型，确定交付模式。

2. Step 2 — 单技能退出：一个项目由一位专家端到端负责 → 停止 Lane B，直接加载该专家并提供已检测到的上下文（无计划文件、无任务）。

3. Step 3 — 批量收集信息：在一次 AskUserQuestion 调用中询问生成方式 + 执行自主程度 + 项目类型备选项（仍不明确时）+ 交付模式（候选方案为设有门槛的产品时）。已解决的问题不再询问。

4. Step 4 UI 批次 — 仅当计划包含 uipath-rpa 中的 UI 自动化时执行。

5. 将 YYYY-MM-DD-<feature>.md 写入 docs/plans/（项目中）或 ./plans/（无项目时）。每个任务提示词都必须包含计划路径。

6. 如果先探索 → EnterPlanMode。如果同时进行 → 将计划作为文本输出 + 创建实时任务。

完整流程：non-pdd-lane-guide.md。

技能能力图

概述每位专家负责的内容。不要在计划中描述任何专家的内部流程 — 每项技能都会记录自己的流程，在此重复会导致内容不同步。

技能	负责内容	处理身份验证？	处理部署？
uipath-rpa	RPA 工作流（XAML 和 C# 编码）：创建、编辑、构建、运行、调试。负责端到端的所有 UI 自动化编写工作，包括实时应用探索和探测。	否（依赖 Studio）	否 — .uipx 多项目交由 uipath-solution 处理，单个非解决方案包交由 uipath-platform 处理
uipath-agents	AI Agent — 基于代码的（LangGraph / LlamaIndex / OpenAI Agents）和低代码（agent.json）	是（uip login）	是 — 端到端
uipath-coded-apps	Web 应用（.uipath/ 目录）：构建、同步、打包、发布、部署	是（uip login）	是 — 端到端
uipath-functions	编码函数 — Python（uip function new -l py；Pydantic 类型化 I/O）或 TypeScript/JavaScript（-l ts / js，默认使用 TypeScript；defineFunction + 架构优先的类型化 I/O）— 用于转换、自定义身份验证 API 调用、ERP/IS 连接查询等原子化确定性逻辑。以无服务器方式运行，或在 RPA 机器人上运行；JS/TS 函数以作业运行函数或 HTTP 端点（编码应用后端）的形式交付 — 每个函数只能选择一种调用模式。可由 Maestro（Flow/BPMN）、作为工具的 Agent、Orchestrator API 或其 HTTP 触发器调用。不包含大模型/Agent 循环（此类场景请使用 uipath-agents）	是（uip login）	是 — uip function pack/publish
uipath-rules	业务规则项目 — 每个项目包含一个 .dmn 决策表（DMN 1.5）：uip rules init、refresh、validate、debug。由 BPMN 业务规则任务、Case business-rule 任务和 RPA 调用	是（debug 需要 uip login）	否 — 通过 uipath-solution 使用 uip solution pack/publish/deploy
uipath-maestro-flow	编排 RPA、Agent、应用的 .flow 文件	是（uip login）	部分支持 — .uipx 封装解决方案的 Orchestrator 部署 → uipath-solution；单个非解决方案包 → uipath-platform
uipath-maestro-bpmn	.bpmn 文件 — 基于标准的 BPMN 2.0 流程编排（网关、事件、边界超时、子流程、多实例），可编排 RPA、Agent、API 和 HITL。可编写内联的 userTask/HITL 节点。	是（uip login）	是 — 通过 uip maestro bpmn 打包、上传、发布/部署和运行；.uipx 封装解决方案的 Orchestrator 部署 → uipath-solution
uipath-maestro-case	Case Management 编写 — 根据 SDD 生成 caseplan.case（case pack 会将其编译为 caseplan.case.bpmn；直接编写 .bpmn 请使用 uipath-maestro-bpmn）	是（uip login）	部分支持 — 可自行发布到 Studio Web 和 Orchestrator；.uipx 解决方案部署 → uipath-solution
uipath-api-workflow	API 工作流（JSON document.dsl）：编写、本地运行（uip api-workflow run）、连接器活动	是（uip login）	否 — 通过 uipath-solution 使用 uip solution pack/publish
uipath-human-in-the-loop	HITL 节点编写 — 在 Flow 项目中设置审批关卡、升级处理、回写验证。编码 Agent 的 HITL → uipath-agents；BPMN / Case / RPA 各自在项目内处理（userTask / 任务类型 / Action Center）	否（仅编写）	否 — 随宿主项目一同交付
uipath-platform	身份验证（uip login）、Orchestrator（文件夹、流程、作业、计算机、用户、角色）、资源（资产、队列、存储桶及桶中文件、库、Webhook、触发器）、Integration Service（连接器、连接、活动、IS 触发器）、Data Fabric 实体/记录/文件/选项集（uip df）、追踪、许可	是（身份验证中心）	是 — 用于单个非解决方案包和部署后的 Orchestrator 端操作
uipath-ixp	Document Understanding / IXP — 从半结构化文档（发票、表单）中提取信息：分类体系、模型、分类 / 提取 / 验证。可作为独立项目，或作为主项目使用的提取步骤	是（uip login）	部分支持 — 通过 uip ixp 发布/标记模型；由宿主项目使用
uipath-connector-builder	通过磁盘上的 uip is connectors builder 编写 Integration Service 自定义连接器（REST+JSON）— 当目录中没有所需集成的连接器时，构建连接器（API Workflows / Maestro / Agents 需要；RPA 也可以直接调用 API）	是（uip login）	是 — 导入/发布即为部署（uip is connectors）
uipath-mcp-servers	注册 UiPath AgentHub MCP 服务（6 种类型：uipath、coded、command、remote、swagger、platform），并在 uipath 类型的服务上编写资源工具（automation、agent、agentic-process、api-workflow）。可将 Orchestrator 资源、外部 HTTP MCP 端点、OpenAPI 规范、已发布的编码 Agent、本地子进程命令或 UiPath 第一方服务封装为 MCP 工具。不适用于 FastMCP / Python mcp SDK 开发。	是（uip login）	是 — 注册即为部署（直接发布到 AgentHub）
uipath-solution	.uipx 解决方案的 uip solution 生命周期管理（初始化、打包、发布、部署、激活）。在 PDD 驱动的流程中作为最后一个技能运行（部署 .uipx 解决方案）。	是（uip login）	是 — 用于多项目解决方案（.uipx）部署

参考导航

阶段 D — 设计

文件	用途
SDD 生成指南	阶段协调器 — 阶段 1、2、3 的分步说明
案例设计流程指南	案例设计对话 — 入口、租户背景确认、编写策略、唯一一次案例评审，以及写入
案例设计层指南	案例模型和每项设计默认值 — 框架（触发器、阶段、十种任务类型）、关卡（生命周期规则、退出条件、排序、辅助流程）、数据（变量、输出、表达式）、时间（SLA、升级、响应）、命名规则和关闭清单
PDD 分析指南	如何从任意格式的 PDD 中提取结构化数据
业务规则指南	验证规则、决策规则与推理规则；DMN 风格的决策表；推理清单。在填写 RPA §4 或 BPMN §5 时加载。
产品选择指南	约束关卡（交付模式 + 排除项筛选）、级别 1（主要范围）、级别 1.75（解决方案组合）、级别 2.5 B 部分（跨产品项目列表合并）、级别 3（能力附加项）、模板映射
平台可用性指南	产品 × 交付模式可用性矩阵（Cloud / Automation Suite / 独立部署）、受限产品的替代方案、单元格不确定时的验证规则。每当运行约束关卡时都要加载 — 适用于所有交付模式：“Cloud 并非一概而论”；不同变体（GovCloud / Dedicated / Test Cloud）和各租户的授权可能会限制 Cloud 列中的产品。
RPA 产品指南	RPA 级别 1.5（子类型）、级别 2（编写模式）、级别 2.5 A 部分（RPA 分解）、R-07 命名规则、REFramework。当级别 1 = RPA 或某个解决方案包含 RPA 时加载。
包选择指南	NuGet 包选择；Integration Service 与 NuGet 规则；各产品的依赖管理器。填写 §14 Packages 或对应部分时加载。
租户库搜索指南	通过 uip or libraries list + JMESPath 筛选来发现已部署库的步骤 2.5 流程 — 身份验证预检、排序、无结果分支、手动回退。
有人值守重新认证模式指南	适用于只能由人工登录的门户自动化的设计约定（硬件 2FA 令牌、智能卡、生物识别）：交接点、经状态验证后恢复、有人值守的机器人、路由到 uipath-rpa。当 PDD 显示存在无法通过脚本实现的交互式登录时加载。
ASDD 交叉映射指南	生成面向客户端的 Word SDD/ASDD：提醒用户提供模板路径，将 Markdown SDD 匹配到相应章节，并计算缺失项。包含标准 UiPath SDD 模板的交叉映射。用户需要官方文档时，在步骤 2.5 加载。

SDD 模板

文件	用途
RPA 模板	RPA 流程 / 库 / 测试自动化的 SDD 模板
Flow 模板	Maestro Flow 的 SDD 模板
BPMN 模板	Maestro BPMN 的 SDD 模板
案例管理模板	案例管理的 SDD 模板（下游案例定义蓝图形态）
Agent 模板	UiPath Agents 的 SDD 模板
编码应用模板	编码应用（Web）的 SDD 模板
API 工作流模板	API 工作流的 SDD 模板

脚本（阶段 D）

脚本	用途
scripts/docx-extract.{sh,ps1}	.docx PDD → UTF-8 Markdown + 提取的屏幕截图（pandoc）。当 Word PDD 显示乱码时，在阶段 D 步骤 1 运行；切勿通过 COM 操作 Word。**跨平台对应脚本：**在 macOS/Linux/Git-Bash 上运行 bash …/docx-extract.sh；在 Windows 上运行 pwsh -File …/docx-extract.ps1（或在 Windows PowerShell 5.1 上运行 powershell -File …）。两个文件的行为必须保持一致。
scripts/sdd-to-docx.{sh,ps1}	将生成的 SDD Markdown 转换为样式化的 .docx，可选使用企业版 --reference-doc。仅当用户要求 Word 输出时，在阶段 D 步骤 2.5 运行。跨平台调用方式相同（bash .sh / pwsh -File .ps1）。

通道 A 和 B——规划

文件	用途
PDD 驱动的通道指南	通道 A 全流程——读取 SDD 标题、解析项目列表、推导任务、编写 tasks.md、输出实时任务
非 PDD 通道指南	通道 B 全流程——需求引导、推断项目类型、检测文件系统、批量处理 UI、编写 plan.md
多技能模式指南	命名的多技能模式（RPA 构建 + 部署、本地/已部署资源的 Flow、使用 RPA 工具的 Agent 等）。供两个通道使用。

| 计划和任务格式 | 标题架构、任务行架构、身份元组、状态、带保留机制的重新生成算法、TaskCreate 映射、防幻觉规则、质量规则 |

反模式

1. 跳过入口检查。 始终先检查输入。将 PDD 默默当作通用文档处理，会导致交付成果质量下降。
2. 编写自动化代码或修改项目。 仅编写 SDD 和计划/任务 Markdown。在先探索的 Lane B 模式下，非变更型 uip 探索是允许的上限。
3. 将单项目请求当作计划——这是最常见的误触发。内联节点规则位于“何时使用此技能”下的“跳过”段落中。
4. 将 PDD 结构照搬到 SDD 中。 SDD 会为了实现而重新组织内容，不会照搬 PDD 的文档顺序。
5. 当需求特征指向其他产品时，仍默认选择 RPA Process。 根据综合后的需求使用 Product Selection Guide 决策树，而不是依据关键词：确实需要判断/推理 → Agents；阶段/SLA/审批生命周期 → Case Management（对于可用规则表达的决策，即使冠以“AI”之名，仍属于 RPA）。当 PDD 描述多个协调配合的项目时，仍强行限定为单一产品范围，也是同样的错误——应提供 Solution。
6. 在 SDD 中生成 Implementation Plan / 任务列表。 SDD 仅涵盖架构，并以 ## Next Steps 结尾。任务推导是 Lane A 的工作。
7. 在计划或 SDD 中描述专业技能内部的流程。 目标配置、OR 注册、脚手架搭建、身份验证、包的打包/发布、测试流程、HITL 字段架构——这些都由专业技能自己的文档负责。将其内联会造成偏差。
8. 询问测试覆盖深度。 测试始终要全面。如果用户想要快速 MVP，实现专家会在执行时缩小范围；规划者不应提供此选项。
9. 推荐与文件系统信号矛盾的技能。 .flow → uipath-maestro-flow，而不是 uipath-rpa。
10. **根据截图臆造选择器，**或询问用户规划器/库/文件系统已经能够回答的问题。优先采用默认设置；只有在决策必须由用户做出时，才消耗一次提示。
11. 重命名 ## Planner Handoff 标题或删除 `` 标记。 任一信号都足以用于检测，但两者都应保留——同时移除会导致 Lane A 检测失效，且不会发出提示。
12. 推荐客户平台无法运行的产品，或重新推荐已排除的产品。 在 Automation Suite 项目中默认选择云端现代产品（Maestro、Coded Apps、Document Understanding），是代价最高的设计错误——每个受阻产品都能通过评审，直到交付时才失败。执行 Constraint Gate；用户一旦表示“不想要 X”，X 在整个会话中都必须保持禁用。