uipath-planner

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

UiPath Planner — Design & Task Derivation

UiPath 规划工具 — 设计与任务推导

Two jobs, one entry point:

Design — turn a Process Design Document (PDD) into an implementation-ready Solution Design Document (SDD). Select scope (single product or multi-project Solution), write the SDD.
Plan — derive the per-skill task list from an SDD (or a non-PDD request), route to specialists, emit live
```
TaskCreate
```
calls.

Never execute the work. Outputs are SDD markdown, plan/tasks markdown, and live tasks — implementation always routes to a specialist.

The skill has three paths, decided by the Entry Guard:

Phase D — Design. Input is a PDD, or an explicit "design / architect this" request. Author the SDD; the SDD write ends the turn, and Lane A continues on the next turn. See sdd-generation-guide.md. Case Management designs run through Phase D's Case Design Lane (case-design-lane-guide.md): a conversational design that ends in one Case Review confirmation. The lane defines its own entry modes — direct design, build handoff from
```
uipath-maestro-case
```
, and draft finalization.
Lane A — PDD-driven. Input is an SDD with the
```
## Planner Handoff
```
marker (written by Phase D, or hand-written). Read it, derive tasks, emit live tasks. Zero to two user prompts. See pdd-driven-lane-guide.md.
Lane B — Non-PDD. No SDD; a non-PDD multi-project request. Elicit preferences, detect project type, write a plan, emit live tasks. 0–3 prompts (5-call cap). See non-pdd-lane-guide.md.

一项入口，两类职责：

设计 — 将流程设计文档（PDD）转换为可直接落地的解决方案设计文档（SDD）。选择范围（单一产品或多项目解决方案），撰写 SDD。
规划 — 从 SDD（或非 PDD 类需求）中推导分技能的任务列表，路由至专业技能工具，触发实时
```
TaskCreate
```
调用。

绝不执行实际落地工作。输出内容为 SDD 格式的 markdown、规划/任务格式的 markdown，以及实时任务——落地工作始终路由至专业技能工具。

本工具包含三条路径，由入口校验规则决定：

阶段 D — 设计：输入为 PDD，或明确的“设计/架构此流程”请求。生成 SDD；SDD 撰写完成后结束当前轮次，下一轮次进入路径 A。详见 sdd-generation-guide.md。案例管理设计需通过阶段 D 的案例设计路径（case-design-lane-guide.md）：通过对话式设计完成，最终需一次案例评审确认。该路径定义了自身的入口模式——直接设计、从
```
uipath-maestro-case
```
移交的构建任务、草稿定稿。
路径 A — PDD 驱动：输入为带有
```
## Planner Handoff
```
标记的 SDD（由阶段 D 生成或手动撰写）。读取该标记，推导任务，触发实时任务。需 0-2 次用户交互。详见 pdd-driven-lane-guide.md。
路径 B — 非 PDD 驱动：无 SDD；为非 PDD 类多项目请求。收集用户偏好，检测项目类型，撰写规划，触发实时任务。需 0-3 次交互（最多 5 次调用）。详见 non-pdd-lane-guide.md。

When to Use This Skill

何时使用本工具

User provides a PDD or any process-knowledge source — a PDD, Confluence page, BPMN model, meeting/Zoom transcript, SOP, or requirements doc (as PDF / Word / Markdown /
```
.txt
```
/
```
.bpmn
```
/ pasted) — and asks to design or build from it → Phase D
User asks to design / architect / generate an SDD for a UiPath automation → Phase D
User provides an SDD path → Lane A
User asks to design / generate a Case Management SDD conversationally (no PDD), asks for a reviewable case design draft, or asks to finalize a case
sdd.draft.md
→ Phase D — Design (Case Design Lane)
uipath-maestro-case
handed a case build request off to this skill (no
```
sdd.md
```
exists yet; same conversation) → Phase D — Design (Case Design Lane, Build handoff: design with the user, Build-option confirmation, write
```
sdd.md
```
at the working root, the build continues immediately)
The request is non-trivial — spans separate buildable projects that each need their own specialist (a Flow orchestrating standalone RPA processes or agents that must themselves be built) → Lane B
The request is ambiguous — no single specialist clearly matches, or "what can I build?"

Skip this skill for single-project tasks — load the specialist directly. A request is single-project (one specialist owns it end-to-end) even when it bundles several things inside one project: a Flow with script nodes plus an inline HITL approval step plus its own solution wrapper is one

uipath-maestro-flow

task. Inline nodes (HITL QuickForm, script, connector, inline agent) and solution scaffolding are author sub-steps the specialist performs itself — not separate skills to orchestrate. Counting them as distinct skills and emitting a plan is the most common mis-trigger. This skill is only for work spanning separate buildable projects (distinct

.uipx

projects), or for turning a PDD into an architecture.

用户提供PDD 或任何流程知识来源——PDD、Confluence 页面、BPMN 模型、会议/Zoom 记录、SOP 或需求文档（格式为 PDF/Word/Markdown/
```
.txt
```
/
```
.bpmn
```
或直接粘贴内容），并要求基于此进行设计或构建 → 阶段 D
用户要求为 UiPath 自动化设计/架构/生成 SDD → 阶段 D
用户提供SDD 文件路径 → 路径 A
用户要求通过对话方式设计/生成案例管理 SDD（无 PDD）、要求可评审的案例设计草稿，或要求定稿案例
sdd.draft.md
→ 阶段 D — 设计（案例设计路径）
uipath-maestro-case
将案例构建请求移交至本工具（当前对话中尚无
```
sdd.md
```
文件）→ 阶段 D — 设计（案例设计路径，构建移交模式：与用户协作设计、确认构建选项、在工作根目录写入
```
sdd.md
```
，构建工作立即继续）
请求非单一项目——涉及多个独立可构建的项目，每个项目需对应专业技能工具（例如，编排独立 RPA 流程或需单独构建的 Agent 的 Flow）→ 路径 B
请求模糊不清——无明确匹配的专业技能工具，或用户询问“我可以构建什么”

单项目任务请跳过本工具——直接调用对应专业技能工具。即使项目内部包含多个内容（如带有脚本节点、内置人工审批步骤及解决方案包装的 Flow），只要属于同一项目（由一名专业技能工具全程负责），就属于单项目任务。内置节点（人工交互快速表单、脚本、连接器、内置 Agent）及解决方案脚手架是专业技能工具自身需完成的子步骤——无需调用其他工具进行编排。将此类内容视为独立技能并生成规划是最常见的误用场景。本工具仅适用于跨多个独立可构建项目（不同

.uipx

项目）的工作，或从 PDD 转换为架构的场景。

Critical Rules

核心规则

Plan & design only — never author automation code. Outputs: SDD markdown (Phase D), plan/tasks markdown (Lanes A/B), and live
```
TaskCreate
```
calls. NEVER write XAML, C#, Python, JSON, or project/scaffold files. Implementation always routes to a specialist. (SDD/plan authoring is the only file authoring this skill does.)
Run the Entry Guard first. Inspect the input and route to Phase D / Lane A / Lane B before anything else.
Select scope before designing architecture (Phase D) — and gate every product by platform constraints. Single product (RPA Process/Library/Test Auto, Maestro Flow, Maestro BPMN, Case, Agents, Coded Apps, API Workflows) vs multi-project Solution determines the template(s) and project structure. Use the Product Selection Guide: Constraint Gate → Level 1 → 1.5 (RPA sub-type) → 1.75 (Solution composition) → 2.5 (project decomposition). The delivery model (Cloud / Automation Suite / standalone — asked at Phase D entry) blocks unavailable products via platform-availability-guide.md; user-excluded products are never re-offered.
The SDD is architecture only — no task lists. Phase D produces the SDD (Project Structure, Data Definitions, Testing Strategy, …). Task derivation is Lane A's job. Never put Task 1 / Task N templates or implementation
```
TaskCreate
```
calls in the SDD. End the SDD with a
```
## Next Steps
```
section. (Progress-tracking
```
TaskCreate
```
calls are a separate, allowed use.)
Write the
## Planner Handoff
header AND the

marker into every SDD. Load-bearing detection contract — the Entry Guard detects either signal (redundant on purpose).
```
Generated by: uipath-planner
```
. Fields: Status (draft → ready), Execution autonomy, Delivery model, SDD scope, the solution-root block (solution scope only: Solution root SDD, Solution ID, Project SDD role root|child, Independently executable: no on children — the root's Project Inventory + SDD Index are the sole executable entry; children and root share ONE canonical tasks file), Project list section, Tasks file, Generated by, Generation date, Template validation. The first incremental write stamps
```
Status: draft
```
; only after SME resolution AND the template-superset check does Phase D flip it to
```
ready
```
(+
```
Template validation: passed
```
) — the marker identifies a planner SDD, the Status field says whether it is consumable. Lane A derives tasks from
```
ready
```
only (missing field = legacy → treat as ready). Every template places the header after
```
## Document History
```
.
Honour the template section structure as a hard superset contract. Write single-product scope to
```
<PROCESS_NAME_KEBAB>-sdd.md
```
; write Solution scope to a
```
<SOLUTION_NAME_KEBAB>-solution-sdd.md
```
overview plus one
```
<PROJECT_NAME_KEBAB>-sdd.md
```
per project. If the user specifies an output path for the SDD, use it instead of these defaults. After writing, diff the generated H2/H3 headings against the template TOC — the generated set MUST be a superset. A missing template-required H2/H3 is an SDD defect, not an
```
[SME REVIEW]
```
item — regenerate it.
Testing is mandatory and thorough — never offer "happy path only". Phase D writes a full Testing Strategy section (happy path, edge cases, error scenarios, e2e for Master Projects). The plan adds a mandatory Testing task per generation skill, routing to that specialist's testing references — never describing the procedure inline. Implementation specialists may scope down at execution time; the SDD and plan do not.
Route — do not redescribe. The plan says WHICH skill to load and IN WHAT ORDER. It does NOT describe specialist-internal flows (target configuration, OR registration, XAML pipelines, HITL field/outcome schema, auth, testing procedures). For a HITL step, pass business intent only ("manager approves or rejects an expense; can add a reason if rejected") — never a field-level spec; the HITL specialist chooses the schema shape.
Per-phase prompt budget. Phase D runs under its own checkpoint model (see sdd-generation-guide.md) — no hard numeric cap. Lanes A and B each cap at 5
AskUserQuestion
calls. Ask execution autonomy exactly once (Phase D entry) and write it into the handoff header; Lane A reads it and never re-asks. Scope/UI answers resolved in Phase D flow forward via the SDD.
Fill gaps with
[DEFAULT]
or
[SME REVIEW]
— never silently invent business rules.
```
[DEFAULT]
```
for industry-standard patterns (retry counts, timeouts);
```
[SME REVIEW]
```
for business-knowledge gaps. Resolve
```
[SME REVIEW]
```
items with the user before writing. For Agent/Coded App gaps, use
```
AskUserQuestion
```
(proceed-with-gap-filling vs different product) — never auto-fallback.
The terminal artefact of a Solution build is a packed
.uipx
. The SDD's
```
## Next Steps
```
section points the user at the
```
uipath-solution
```
skill (
```
uip solution init
```
→
```
project add
```
per project →
```
resources refresh
```
→
```
pack
```
). A bare project folder is not the deliverable. Exception: when the Constraint Gate blocks Solutions for the delivery model — standalone, Automation Suite older than 2.2510, or a user exclusion — rewrite Next Steps to per-package Orchestrator publish routed via
```
uipath-platform
```
.
Never copy SDD architecture into the plan, and never invent selectors or UI targets. The plan references SDD section paths in skill prompts; it does not duplicate architecture content. Selectors require application inspection at development time — leave them for the specialist.
This skill is the sole author of Case Management SDDs — it always writes the SDD file. Every case design path (conversational, build handoff from
```
uipath-maestro-case
```
, draft finalization, PDD-driven) runs through the Case Design Lane (case-design-lane-guide.md) — flow, write-early cadence, and the never-overwrite guard on
```
sdd.md
```
— with the content contract in references/case/ (design-time tenant resolution + its ONE batched gate: case/grounding.md). Design time never runs schema discovery, scaffolds projects, or executes create-on-missing — those are build-skill concerns recorded as gate decisions.

仅负责规划与设计——绝不编写自动化代码：输出内容为：阶段 D 生成的 SDD markdown、路径 A/B 生成的规划/任务 markdown，以及实时
```
TaskCreate
```
调用。绝不编写 XAML、C#、Python、JSON 或项目/脚手架文件。落地工作始终路由至专业技能工具。（本工具仅负责撰写 SDD/规划文件。）
优先执行入口校验规则：在执行任何操作前，先检查输入内容并路由至阶段 D/路径 A/路径 B。
设计架构前先选择范围——并根据平台约束筛选所有产品：单一产品（RPA 流程/库/测试自动化、Maestro Flow、Maestro BPMN、案例、Agent、编码应用、API 工作流）与多项目解决方案的选择，决定了模板及项目结构。请使用产品选择指南：约束校验 → 一级分类 → 1.5 级（RPA 子类型）→ 1.75 级（解决方案组成）→ 2.5 级（项目分解）。交付模式（云/自动化套件/独立部署——在阶段 D 入口时询问）通过平台可用性指南限制不可用产品；用户排除的产品不再提供。
SDD 仅包含架构内容——无任务列表：阶段 D 生成 SDD（项目结构、数据定义、测试策略等）。任务推导是路径 A 的职责。绝不在 SDD 中加入任务模板或落地相关的
```
TaskCreate
```
调用。SDD 结尾需包含
```
## 下一步
```
章节。（进度追踪类
```
TaskCreate
```
调用属于允许的例外场景。）
在每个 SDD 中写入
## Planner Handoff
标题及

标记：这是关键的检测约定——入口校验规则会检测任一标记（故意设置冗余）。标记内容为
```
Generated by: uipath-planner
```
。字段包括：状态（草稿 → 就绪）、执行自主性、交付模式、SDD 范围、解决方案根节点块（仅解决方案范围适用：解决方案根 SDD、解决方案 ID、项目 SDD 角色根|子、独立可执行：子项目不可——根项目的项目清单 + SDD 索引是唯一可执行入口；子项目与根项目共享一个标准任务文件）、项目列表章节、任务文件、生成工具、生成日期、模板验证。首次增量写入时标记
```
Status: draft
```
；只有在解决所有专家评审项并通过模板超集检查后，阶段 D 才会将状态改为
```
ready
```
（同时标记
```
Template validation: passed
```
）——该标记用于识别由规划工具生成的 SDD，状态字段表示其是否可被使用。路径 A 仅从
```
ready
```
状态的 SDD 推导任务（缺失状态字段视为遗留文件→按就绪处理）。所有模板均将该标题放置在
```
## 文档历史
```
之后。
严格遵循模板章节结构的超集约定：单一产品范围的 SDD 写入
```
<PROCESS_NAME_KEBAB>-sdd.md
```
；解决方案范围的 SDD 写入
```
<SOLUTION_NAME_KEBAB>-solution-sdd.md
```
概述文件，同时为每个项目生成
```
<PROJECT_NAME_KEBAB>-sdd.md
```
。若用户指定了 SDD 的输出路径，则使用用户指定路径而非默认路径。写入完成后，将生成的 H2/H3 标题与模板目录进行对比——生成的标题集必须是模板的超集。若缺少模板要求的 H2/H3 标题，则属于 SDD 缺陷，需重新生成，而非标记为
```
[SME REVIEW]
```
项。
测试是强制且全面的——绝不提供“仅主流程”选项：阶段 D 需撰写完整的测试策略章节（主流程、边缘场景、错误场景、主项目端到端测试）。规划中需为每个生成类技能添加强制测试任务，路由至该专业技能工具的测试参考文档——绝不在线描述测试流程。落地阶段专业技能工具可根据实际情况缩小测试范围，但 SDD 与规划中需保持全面测试要求。
仅路由——不重述细节：规划需说明调用哪些技能工具及调用顺序。绝不描述专业技能工具的内部流程（目标配置、Orchestrator 注册、XAML 流水线、人工交互字段/结果 schema、权限、测试流程）。对于人工交互步骤，仅传递业务意图（如“经理审批或拒绝费用申请，拒绝时可添加原因”）——绝不提供字段级规范；人工交互专业技能工具会自行选择 schema 结构。
分阶段交互次数限制：阶段 D 采用自身的检查点模型（详见 sdd-generation-guide.md）——无严格次数限制。路径 A 和路径 B 各自最多允许 5 次
AskUserQuestion
调用。仅在阶段 D 入口询问一次执行自主性，并写入移交标题；路径 A 读取该信息，不再重复询问。阶段 D 中解决的范围/UI 相关问题通过 SDD 传递至后续流程。
使用
[DEFAULT]
或
[SME REVIEW]
填补空白——绝不凭空编造业务规则：
```
[DEFAULT]
```
用于行业标准模式（重试次数、超时时间）；
```
[SME REVIEW]
```
用于业务知识空白。写入前需与用户确认解决
```
[SME REVIEW]
```
项。对于 Agent/编码应用的空白，使用
```
AskUserQuestion
```
（选择填补空白或更换产品）——绝不自动回退。
解决方案构建的最终产物是打包后的
.uipx
文件：SDD 的
```
## 下一步
```
章节需引导用户使用
```
uipath-solution
```
技能（
```
uip solution init
```
→ 按项目执行
```
project add
```
→
```
resources refresh
```
→
```
pack
```
）。单独的项目文件夹不属于交付物。例外情况：若约束校验规则限制了当前交付模式下的解决方案功能——独立部署、自动化套件版本早于 2.2510，或用户排除了解决方案功能——则将下一步改为通过
```
uipath-platform
```
路由至每个包的 Orchestrator 发布流程。
绝不将 SDD 架构内容复制到规划中，绝不编造选择器或 UI 目标：规划在技能工具的调用提示中引用 SDD 章节路径；绝不复制架构内容。选择器需在开发阶段通过应用检查确定——留待专业技能工具处理。
本工具是案例管理 SDD 的唯一生成工具——始终负责写入 SDD 文件：所有案例设计路径（对话式设计、从
```
uipath-maestro-case
```
移交的构建任务、草稿定稿、PDD 驱动）均需通过案例设计路径（case-design-lane-guide.md）——流程、提前写入节奏、
```
sdd.md
```
永不覆盖规则——内容约定详见 references/case/（设计时租户解析 + 批量校验规则：case/grounding.md）。设计阶段绝不执行 schema 发现、脚手架生成或缺失项创建——这些属于构建类技能工具的职责，记录为校验规则决策。

Entry Guard

入口校验规则

Run this guard before anything else.

text

0. Product design-lane signals — checked first. Some products register a
   dedicated Phase D design lane (today: Case Management —
   references/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 `<!-- planner-handoff:v1 -->` → 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 Design 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.

Do not pattern-match on filename or extension alone; those are unreliable. The

## Planner Handoff

heading and the

<!-- planner-handoff:v1 -->

marker are the load-bearing detection contract — Phase D writes both deterministically; the guard detects either.

在执行任何操作前先运行此规则。

text

0. 产品设计路径信号——优先检查。部分产品注册了专属的阶段 D 设计路径（当前为：案例管理——
   references/case-design-lane-guide.md）。当以下任一情况触发时，路由至阶段 D — 设计（通过对应产品的路径；整体仍分为三条路径；路径是阶段 D 的产品专属入口）：
   - 对应产品的构建技能工具因缺少设计输入而移交构建请求（同一对话）→ 路径的构建移交模式
   - 针对该产品的无 PDD 设计请求 → 直接进入该路径
   - 该产品的设计草稿已存在（或已命名），且用户要求定稿 → 路径的草稿定稿模式

1. 无文档路径？
   - 明确的设计/架构表述（如“设计此流程”“架构此系统”“生成 SDD”），或内联描述的流程包含足够替代 PDD 的细节（流程步骤 + 应用 + 异常）→ 阶段 D — 设计。
     即使设计/SDD 请求的流程细节不足，仍需路由至阶段 D — 通过 `AskUserQuestion` 收集缺失的步骤/应用/异常（阶段 1），而非降级为路径 B 规划。
   - 其他情况 → 路径 B — 非 PDD 驱动。路径 B 是无文档多项目请求的默认路由。

2. 有文档路径 → 读取前约 50 行内容。
   - 包含 `## Planner Handoff` 或 `<!-- planner-handoff:v1 -->` → 路径 A — PDD 驱动。
     （任一标记即可——故意设置冗余。）
   - 内容为 PDD **或任何流程知识来源**——PDD、Confluence 页面、BPMN 模型、会议/Zoom 记录、SOP 或需求文档中的流程描述（步骤 + 应用 + 异常）；或用户称为 PDD 的二进制 .pdf/.docx 文件 → 阶段 D — 设计。结构较松散的来源（记录、内容单薄的 wiki）仍路由至阶段 D，但会触发更全面的阶段 1 信息收集。

3. 其他情况（无标记、模糊不清或无法解析）——通过 AskUserQuestion 询问：

   > <path> 对应的文档是什么类型？
   > 1. 流程设计文档（PDD）——生成 SDD（阶段 D — 设计），然后推导任务
   > 2. 解决方案设计文档（SDD）——继续生成任务（路径 A — PDD 驱动）
   > 3. 其他上下文——读取内容；用于解决路径 B 的信息收集问题（跳过已回答的问题）并作为规划输入（路径 B — 非 PDD 驱动）

4. 根据选择进行路由。对于无移交标题的 SDD，使用安全默认值——详见 pdd-driven-lane-guide.md 步骤 1 的默认值集及默认值向用户展示的方式。

请勿仅通过文件名或扩展名进行模式匹配；这些信息不可靠。

## Planner Handoff

标题与

<!-- planner-handoff:v1 -->

标记是关键检测约定——阶段 D 会确定性地写入两者；校验规则会检测任一标记。

Phase D — Design (summary)

阶段 D — 设计（摘要）

When triggered: input is a PDD, or an explicit design/architect request. Three phases; full detail in sdd-generation-guide.md. All user questions use numbered-choice format.

Phase 1 — PDD Analysis & Scope Selection. Ask execution mode (Autonomous or Interactive) and delivery model (Cloud / Automation Suite / standalone) in one batched call — skip the delivery question when the PDD or request states it, or when the
```
uip login status
```
preflight resolves it from the session
```
BaseUrl
```
. Read the full PDD, extract structured information (including environment & constraint signals, as-is/to-be), synthesize the need profile (Step 3.5 — product picks reason from the need, not keywords), then run Constraint Gate → Level 1 (primary scope) → Level 1.5 (RPA sub-type) → Level 1.75 (Solution composition) → Level 2.5 (project decomposition). Step 2.5 runs an authenticated
```
uip
```
library search (CLI auth required). In Interactive mode, present a summary with the recommended scope at the top and alternatives below; in Autonomous mode, proceed.
Phase 2 — Architecture Review. Load the product-specific template. Generate the architectural core sections. Present for review in Interactive mode.
Phase 3 — Full SDD Generation. Generate all remaining sections including the thorough Testing Strategy. Resolve
```
[SME REVIEW]
```
items first (unresolved items carry recorded defaults and do not block
```
ready
```
; only architecture-blocking items keep
```
draft
```
). Write the
```
## Planner Handoff
```
header + marker with
```
Status: draft
```
. Write the SDD to disk — write early and append incrementally so a long turn still leaves a gradeable file; the LAST write flips
```
Status
```
to
```
ready
```
after the superset check passes. The SDD write is a turn boundary: in autonomous mode, end the turn after the SDD summary and continue into Lane A on the next turn (do not stack both phases in one turn).

触发条件：输入为 PDD，或明确的设计/架构请求。分为三个阶段；详细内容见 sdd-generation-guide.md。所有用户问题均采用编号选项格式。

阶段 1 — PDD 分析与范围选择：通过一次批量调用询问执行模式（自主或交互）和交付模式（云/自动化套件/独立部署）——若 PDD 或请求中已说明交付模式，或
```
uip login status
```
预检查从会话
```
BaseUrl
```
中解析出交付模式，则跳过交付模式询问。读取完整 PDD，提取结构化信息（包括环境与约束信号、现状/目标状态），合成需求概况（步骤 3.5——根据需求选择产品，而非关键词），然后执行约束校验 → 一级分类（主范围）→ 1.5 级（RPA 子类型）→ 1.75 级（解决方案组成）→ 2.5 级（项目分解）。步骤 2.5 执行已认证的
```
uip
```
库搜索（需 CLI 认证）。交互模式下，展示摘要，顶部为推荐范围，下方为替代选项；自主模式下，直接执行。
阶段 2 — 架构评审：加载产品专属模板。生成架构核心章节。交互模式下，提交评审。
阶段 3 — 完整 SDD 生成：生成所有剩余章节，包括全面的测试策略。先解决
```
[SME REVIEW]
```
项（未解决项会记录默认值，不影响
```
ready
```
状态；仅架构阻塞项会保持
```
draft
```
状态）。写入
```
## Planner Handoff
```
标题 + 标记，状态为
```
Status: draft
```
。将 SDD 写入磁盘——提前写入并增量追加，确保长耗时操作仍会生成可评估的文件；最后一次写入在超集检查通过后将状态改为
```
ready
```
。SDD 写入是轮次边界：自主模式下，写入 SDD 摘要后结束当前轮次，下一轮次进入路径 A（不可在一轮次中同时执行两个阶段）。

Lane A — PDD-driven (summary)

路径 A — PDD 驱动（摘要）

When triggered: an SDD with the

Planner Handoff

marker is detected (or Phase D just wrote one).

Read the SDD's
```
## Planner Handoff
```
header. Status: draft
→ refuse task derivation (unfinished Phase D or a blocking SME item — offer resume or regenerate; missing field = legacy → ready; open default-carried SME items on a
```
ready
```
SDD travel into tasks as assumptions). Reuse the execution autonomy chosen in Phase D — do not re-ask. If
```
SDD scope: solution
```
, run the root algorithm: resolve the Solution root, verify every indexed child (exists, same Solution ID, ready), read every child's architecture, merge shared resources, emit ONE canonical tasks file (see pdd-driven-lane-guide Step 3).
If
```
<process>-tasks.md
```
already exists, ask
```
continue / regenerate
```
(1 prompt). See plan-and-tasks-format.md → Regenerate logic.
Parse the SDD project list section. Pick the multi-skill pattern.
Ask the UI batch (3 questions, 1 call) only if the SDD's Application Inventory lists UI applications and the answers aren't already resolved.
Derive tasks. Write
```
<process>-tasks.md
```
.

Execution autonomy: interactive

→

EnterPlanMode

for review. If

autonomous

→ emit live tasks directly.

Emit
```
TaskCreate
```
calls +
```
addBlockedBy
```
edges. Hand off.

Full procedure: pdd-driven-lane-guide.md.

触发条件：检测到带有

Planner Handoff

标记的 SDD（或阶段 D 刚刚生成该 SDD）。

读取 SDD 的
```
## Planner Handoff
```
标题。Status: draft
→ 拒绝任务推导（阶段 D 未完成或存在阻塞性专家评审项——提供继续或重新生成选项；缺失状态字段视为遗留文件→就绪；就绪状态 SDD 中未解决的默认专家评审项会作为假设带入任务）。复用阶段 D 中选择的执行自主性——不再重复询问。若
```
SDD scope: solution
```
，执行根节点算法：解析解决方案根节点，验证所有已索引的子项目（存在、同一解决方案 ID、就绪状态），读取每个子项目的架构，合并共享资源，生成一个标准任务文件（详见 pdd-driven-lane-guide 步骤 3）。
若
```
<process>-tasks.md
```
已存在，询问
```
继续/重新生成
```
（1 次交互）。详见 plan-and-tasks-format.md → 重新生成逻辑。
解析 SDD 的项目列表章节。选择多技能模式。
仅当 SDD 的应用清单包含 UI 应用且相关答案未解析时，通过一次调用询问 UI 相关批量问题（3 个问题）。
推导任务。写入
```
<process>-tasks.md
```
。
若
```
Execution autonomy: interactive
```
→ 进入
```
EnterPlanMode
```
进行评审。若为
```
autonomous
```
→ 直接触发实时任务。
触发
```
TaskCreate
```
调用 +
```
addBlockedBy
```
依赖关系。移交任务。

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

Lane B — Non-PDD (summary)

路径 B — 非 PDD 驱动（摘要）

When triggered: no SDD; a document-less multi-project request (the default route when no explicit design/architect language or inline-described process points to Phase D).

Step 1 — detect before asking (no prompts): read any provided context doc, filesystem detection (
```
Glob
```
/
```
Read
```
/
```
Grep
```
— cross-platform), multi-skill pattern classification, need-driven project-type inference, delivery-model resolution.
Step 2 — single-skill exit: one project owned end-to-end by one specialist → stop Lane B, load that specialist directly with the detected context (no plan file, no tasks).
Step 3 — batched elicitation: generation approach + execution autonomy + project-type fallback (when still vague) + delivery model (when a gated product is a candidate) in one
```
AskUserQuestion
```
call. Drop any question already resolved.
Step 4 UI batch — only when the plan includes UI automation in
```
uipath-rpa
```
.
Write
```
YYYY-MM-DD-<feature>.md
```
to
```
docs/plans/
```
(project) or
```
./plans/
```
(no project). Every task prompt embeds the plan path.
If explore-first →
```
EnterPlanMode
```
. If simultaneous → emit plan as text + live tasks.

Full procedure: non-pdd-lane-guide.md.

触发条件：无 SDD；为无文档多项目请求（当无明确设计/架构表述或内联流程描述指向阶段 D 时，默认路由至此）。

步骤 1 — 询问前先检测（无交互）：读取提供的上下文文档、文件系统检测（
```
Glob
```
/
```
Read
```
/
```
Grep
```
——跨平台）、多技能模式分类、基于需求的项目类型推断、交付模式解析。
步骤 2 — 单技能退出：单一项目由一名专业技能工具全程负责 → 终止路径 B，直接加载对应专业技能工具并传入检测到的上下文（无规划文件、无任务）。
步骤 3 — 批量信息收集：通过一次
```
AskUserQuestion
```
调用询问生成方式 + 执行自主性 + 项目类型回退（仍模糊时）+ 交付模式（当受限产品为候选时）。跳过已解析的问题。
步骤 4 UI 批量问题——仅当规划中包含
```
uipath-rpa
```
的 UI 自动化时询问。
将
```
YYYY-MM-DD-<feature>.md
```
写入
```
docs/plans/
```
（项目内）或
```
./plans/
```
（无项目）。每个任务提示均嵌入规划路径。
若为探索优先模式 → 进入
```
EnterPlanMode
```
。若为同步模式 → 输出规划文本 + 实时任务。

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

Skill capability map

技能能力映射

High-level view of what each specialist owns. Do not describe internal flows of any specialist in your plan — each skill documents its own procedures and will drift out of sync if duplicated here.

Skill	What it owns	Handles auth?	Handles deploy?
`uipath-rpa`	RPA workflows (XAML and C# coded): create, edit, build, run, debug. Owns all UI automation authoring end-to-end, including live-app exploration and probing.	No (relies on Studio)	No — defer to `uipath-solution` for `.uipx` multi-project, `uipath-platform` for single non-solution packages
`uipath-agents`	AI agents — code-based (LangGraph / LlamaIndex / OpenAI Agents) and low-code ( `agent.json` )	Yes ( `uip login` )	Yes — end-to-end
`uipath-coded-apps`	Web apps ( `.uipath/` dir): build, sync, package, publish, deploy	Yes ( `uip login` )	Yes — end-to-end
`uipath-functions`	Coded Functions — TypeScript (default), JavaScript, or Python ( `uip function new -l ts / js / py` ; typed I/O — Pydantic for Python) — atomic deterministic logic: transforms, custom-auth API calls, ERP/IS-connection queries. Runs serverless or on an RPA robot. Invoked from Maestro (Flow/BPMN), agents-as-tools, Orchestrator API. No LLM/agent loop (that → `uipath-agents` )	Yes ( `uip login` )	Yes — `uip function pack/publish`
`uipath-maestro-flow`	`.flow` files orchestrating RPA, agents, apps	Yes ( `uip login` )	Partial — Orchestrator deploy of `.uipx` -wrapped solutions → `uipath-solution` ; non-solution single package → `uipath-platform`
`uipath-maestro-bpmn`	`.bpmn` files — standards-based BPMN 2.0 process orchestration (gateways, events, boundary timeouts, subprocesses, multi-instance) over RPA, agents, APIs, HITL. Authors its own inline userTask/HITL nodes.	Yes ( `uip login` )	Yes — packages, uploads, publishes/deploys, and runs via `uip maestro bpmn` ; Orchestrator deploy of `.uipx` -wrapped solutions → `uipath-solution`
`uipath-maestro-case`	Case Management authoring ( `caseplan.json` + generated BPMN) from an SDD	Yes ( `uip login` )	No — deploys via `uipath-solution` ( `.uipx` )
`uipath-api-workflow`	API Workflows (JSON `document.dsl` ): author, run locally ( `uip api-workflow run` ), connector activities	Yes ( `uip login` )	No — `uip solution pack/publish` via `uipath-solution`
`uipath-human-in-the-loop`	HITL node authoring — approval gates, escalations, write-back validation inside Flow projects. Coded-agent HITL → `uipath-agents` ; BPMN / Case / RPA own theirs inline (userTask / task type / Action Center)	No (authoring only)	No — ships inside the host project
`uipath-platform`	Auth ( `uip login` ), Orchestrator (folders, processes, jobs, machines, users, roles), resources (assets, queues, storage buckets + bucket files, libraries, webhooks, triggers), Integration Service (connectors, connections, activities, IS triggers), Data Fabric entities/records/files/choice-sets ( `uip df` ), traces, licensing	Yes (auth hub)	Yes — for non-solution single packages and Orchestrator-side post-deploy ops
`uipath-ixp`	Document Understanding / IXP — extraction from semi-structured documents (invoices, forms): taxonomy, model, classify / extract / validate. Standalone project, or the extraction step a primary consumes	Yes ( `uip login` )	Partial — model publish/tag via `uip ixp` ; consumed by the host project
`uipath-connector-builder`	Integration Service custom connector authoring (REST+JSON) on disk via `uip is connectors builder` — build a connector when the catalog has none for a required integration (needed by API Workflows / Maestro / Agents; RPA can call the API directly instead)	Yes ( `uip login` )	Yes — import/publish is deployment ( `uip is connectors` )
`uipath-mcp-servers`	UiPath AgentHub MCP server registration (6 types: `uipath` , `coded` , `command` , `remote` , `swagger` , `platform` ) and resource-tool authoring on `uipath` -type servers ( `automation` , `agent` , `agentic-process` , `api-workflow` ). Wraps Orchestrator resources, external HTTP MCP endpoints, OpenAPI specs, published coded agents, local subprocess commands, or first-party UiPath services as MCP tools. NOT for FastMCP / Python `mcp` SDK work.	Yes ( `uip login` )	Yes — registration is deployment (posts directly to AgentHub)
`uipath-solution`	`uip solution` lifecycle (init, pack, publish, deploy, activate) for `.uipx` solutions. Runs as the final skill in PDD-driven flows (deploy of `.uipx` solutions).	Yes ( `uip login` )	Yes — for multi-project Solution ( `.uipx` ) deploys

各专业技能工具职责的概览。请勿在规划中描述任何专业技能工具的内部流程——每个技能工具均有自身的流程文档，若在此处复制会导致内容不同步。

Skill	职责范围	是否处理权限？	是否处理部署？
`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`	编码函数——TypeScript（默认）、JavaScript 或 Python（ `uip function new -l ts / js / py` ；类型化输入输出——Python 使用 Pydantic）：原子确定性逻辑，如转换、自定义权限 API 调用、ERP/集成服务连接查询。支持无服务器运行或在 RPA 机器人上运行。可从 Maestro（Flow/BPMN）、Agent 作为工具、Orchestrator API 调用。不包含 LLM/Agent 循环（此类需求请使用 `uipath-agents` ）	是（ `uip login` ）	是——通过 `uip function pack/publish` 完成
`uipath-maestro-flow`	编排 RPA、Agent、应用的 `.flow` 文件	是（ `uip login` ）	部分支持—— `.uipx` 包装的解决方案的 Orchestrator 部署委托给 `uipath-solution` ；单一非解决方案包部署委托给 `uipath-platform`
`uipath-maestro-bpmn`	`.bpmn` 文件——基于标准 BPMN 2.0 的流程编排（网关、事件、边界超时、子流程、多实例），支持 RPA、Agent、API、人工交互。自行创作内置 userTask/人工交互节点。	是（ `uip login` ）	是——通过 `uip maestro bpmn` 完成打包、上传、发布/部署与运行； `.uipx` 包装的解决方案的 Orchestrator 部署委托给 `uipath-solution`
`uipath-maestro-case`	基于 SDD 的案例管理创作（ `caseplan.json` + 生成的 BPMN）	是（ `uip login` ）	否——通过 `uipath-solution` （ `.uipx` ）完成部署
`uipath-api-workflow`	API 工作流（JSON `document.dsl` ）：创作、本地运行（ `uip api-workflow run` ）、连接器活动	是（ `uip login` ）	否——通过 `uipath-solution` 执行 `uip solution pack/publish`
`uipath-human-in-the-loop`	人工交互节点创作——Flow 项目内的审批网关、升级、回写验证。编码 Agent 人工交互请使用 `uipath-agents` ；BPMN/案例/RPA 自行处理内置人工交互（userTask/任务类型/操作中心）	否（仅创作）	否——随宿主项目交付
`uipath-platform`	权限（ `uip login` ）、Orchestrator（文件夹、流程、作业、机器、用户、角色）、资源（资产、队列、存储桶及桶文件、库、Webhook、触发器）、集成服务（连接器、连接、活动、集成服务触发器）、数据 Fabric 实体/记录/文件/选择集（ `uip df` ）、追踪、许可	是（权限中心）	是——处理非解决方案单一包部署及 Orchestrator 端部署后操作
`uipath-ixp`	文档理解/IXP——从半结构化文档（发票、表单）提取信息：分类、模型、分类/提取/验证。支持独立项目，或作为主流程的提取步骤	是（ `uip login` ）	部分支持——通过 `uip ixp` 完成模型发布/标记；由宿主项目调用
`uipath-connector-builder`	集成服务自定义连接器创作（REST+JSON），通过磁盘上的 `uip is connectors builder` 完成——当目录中无所需集成的连接器时（API 工作流/Maestro/Agent 需要；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` ）部署

Reference Navigation

参考文档导航

Phase D — Design

阶段 D — 设计

File	Purpose
SDD Generation Guide	Phase orchestrator — Phase 1, 2, 3 step-by-step instructions
Case Design Lane Guide	Conversational case authoring — entry modes (Build handoff / direct / draft finalization), Listen/Sketch/Case Review single confirmation, full design-time tenant resolution + the resolution gate, template conformance gate, terminal-step fork
Case References	Case SDD content contract, one file per concern: model (node/task types, lifecycle gates, secondary stages, sequencing, naming) · variables (data flow, expressions) · slas · principles (authority, provenance, review items) · authoring (process → model method, task typing) · render-case-definition + render-stages-tasks (SDD §1/§2 cell contracts) · grounding (tenant resolution) · review (Case Review + finalization gate)
PDD Analysis Guide	How to extract structured data from PDDs in any format
Product Selection Guide	Constraint Gate (delivery model + exclusions filter), Level 1 (primary scope), Level 1.75 (Solution composition), Level 2.5 Part B (cross-product project list merge), Level 3 (capability add-ons), template mapping
Platform Availability Guide	Product × delivery-model availability matrix (Cloud / Automation Suite / standalone), alternatives for blocked products, verification rule for uncertain cells. Load whenever the Constraint Gate runs — every delivery model: "Cloud is not uniform", variants (GovCloud / Dedicated / Test Cloud) and per-tenant entitlements can block products inside the Cloud column.
RPA Product Guide	RPA Level 1.5 (sub-type), Level 2 (authoring mode), Level 2.5 Part A (RPA decomposition), R-07 naming, REFramework. Load when Level 1 = RPA or a Solution includes RPA.
Package Selection Guide	NuGet package selection; Integration Service vs NuGet rules; per-product dependency manager. Load when filling §14 Packages or equivalent.
Tenant Library Search Guide	Step 2.5 procedure for discovering deployed libraries via `uip or libraries list` + JMESPath filtering — auth preflight, ranking, zero-results branch, manual fallback.
Attended Re-auth Pattern Guide	Design contract for portal automations with a human-only login (hardware 2FA token, smart card, biometric): handoff point, state-verified resume, attended robot, routing to `uipath-rpa` . Load when the PDD signals a non-scriptable interactive sign-in.
ASDD Crosswalk Guide	Generate the client-facing Word SDD/ASDD: warn the user for the template path, match the markdown SDD into its sections, compute missing pieces. Includes the crosswalk for the standard UiPath SDD template. Load at Step 2.5 when the user wants the official document.

文件	用途
SDD 生成指南	阶段编排——阶段 1、2、3 分步说明
案例设计路径指南	对话式案例创作——入口模式（构建移交/直接/草稿定稿）、倾听/草拟/案例评审单次确认、完整设计时租户解析 + 解析校验规则、模板一致性校验规则、终端步骤分支
案例参考文档	案例 SDD 内容约定，按关注点分文件：模型（节点/任务类型、生命周期校验规则、二级阶段、排序、命名）· 变量（数据流、表达式）· 服务水平协议（SLA） · 原则（权限、来源、评审项）· 创作（流程→模型方法、任务分类）· 渲染案例定义 + 渲染阶段与任务（SDD §1/§2 单元格约定）· 基础校验（租户解析）· 评审（案例评审 + 定稿校验规则）
PDD 分析指南	如何从任意格式的 PDD 中提取结构化数据
产品选择指南	约束校验规则（交付模式 + 排除项筛选）、一级分类（主范围）、1.75 级（解决方案组成）、2.5 级 B 部分（跨产品项目列表合并）、3 级（能力附加组件）、模板映射
平台可用性指南	产品×交付模式可用性矩阵（云/自动化套件/独立部署）、受限产品的替代方案、不确定项的验证规则。每次执行约束校验规则时均需加载——所有交付模式需注意：“云并非统一”，变体（政务云/专属云/测试云）及租户权限可能会限制云分类下的产品。
RPA 产品指南	RPA 1.5 级（子类型）、2 级（创作模式）、2.5 级 A 部分（RPA 分解）、R-07 命名规则、REFramework。当一级分类为 RPA 或解决方案包含 RPA 时加载。
包选择指南	NuGet 包选择；集成服务 vs NuGet 规则；各产品的依赖管理器。填写 §14 包或对应章节时加载。
租户库搜索指南	步骤 2.5 流程：通过 `uip or libraries list` + JMESPath 筛选发现已部署的库——权限预检查、排序、无结果分支、手动回退。
交互式重新授权模式指南	仅支持人工登录的门户自动化设计约定（硬件双因素认证令牌、智能卡、生物识别）：移交点、状态验证恢复、交互式机器人、路由至 `uipath-rpa` 。当 PDD 显示存在不可脚本化的交互式登录时加载。
ASDD 交叉映射指南	生成面向客户的 Word 格式 SDD/ASDD：提示用户模板路径，将 markdown 格式 SDD 映射至对应章节，补充缺失内容。包含标准 UiPath SDD 模板的交叉映射。当用户需要官方文档时，在步骤 2.5 加载。

SDD templates

SDD 模板

File	Purpose
RPA Template	SDD template for RPA Process / Library / Test Automation
Flow Template	SDD template for Maestro Flow
BPMN Template	SDD template for Maestro BPMN
Case Management Template	SDD template for Case Management (downstream Case Definition Blueprint shape)
Case SDD Worked Examples	Worked case-authoring patterns by use case (variables, outputs operators, file In-args, multi-trigger)
Agent Template	SDD template for UiPath Agents
Coded App Template	SDD template for Coded Apps (web)
API Workflow Template	SDD template for API Workflows

文件	用途
RPA 模板	RPA 流程/库/测试自动化的 SDD 模板
Flow 模板	Maestro Flow 的 SDD 模板
BPMN 模板	Maestro BPMN 的 SDD 模板
案例管理模板	案例管理的 SDD 模板（下游案例定义蓝图格式）
案例 SDD 示例	按用例划分的案例创作模式示例（变量、输出运算符、文件输入参数、多触发器）
Agent 模板	UiPath Agent 的 SDD 模板
编码应用模板	编码应用（Web）的 SDD 模板
API 工作流模板	API 工作流的 SDD 模板

Scripts (Phase D)

脚本（阶段 D）

Script	Purpose
`scripts/docx-extract.{sh,ps1}`	.docx PDD → UTF-8 markdown + extracted screenshots (pandoc). Run at Phase D Step 1 when a Word PDD renders garbled — never drive Word via COM. Cross-platform twins: `bash …/docx-extract.sh` on macOS/Linux/Git-Bash; `pwsh -File …/docx-extract.ps1` (or `powershell -File …` for Windows PowerShell 5.1) on Windows. Keep the two files behaviorally identical.
`scripts/sdd-to-docx.{sh,ps1}`	Generated SDD markdown → styled .docx, optional corporate `--reference-doc` . Run at Phase D Step 2.5 only when the user asks for Word output. Same cross-platform twin invocation ( `bash` `.sh` / `pwsh -File` `.ps1` ).

脚本用途

脚本	用途
`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}`	生成的 markdown 格式 SDD → 带样式的 .docx 文件，可选企业 `--reference-doc` 。仅当用户要求 Word 输出时，在阶段 D 步骤 2.5 运行。使用相同的跨平台调用方式（ `bash` 运行 `.sh` / `pwsh -File` 运行 `.ps1` ）。

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}

生成的 markdown 格式 SDD → 带样式的 .docx 文件，可选企业

--reference-doc

。仅当用户要求 Word 输出时，在阶段 D 步骤 2.5 运行。使用相同的跨平台调用方式（

bash

运行

.sh

pwsh -File

运行

.ps1

）。

Lanes A & B — Planning

路径 A & B — 规划

File	Purpose
PDD-driven Lane Guide	Lane A end-to-end — read SDD header, parse project list, derive tasks, write tasks.md, emit live tasks
Non-PDD Lane Guide	Lane B end-to-end — elicitation, project-type inference, filesystem detection, UI batch, write plan.md
Multi-skill Patterns Guide	The named multi-skill patterns (RPA build+deploy, Flow with local/deployed resources, Agent with RPA tools, etc.). Used by both lanes.
Plan and Tasks Format	Header schema, task row schema, identity tuple, status states, regenerate-with-preservation algorithm, TaskCreate mapping, anti-hallucination rule, quality rules

文件	用途
PDD 驱动路径指南	路径 A 端到端流程——读取 SDD 标题、解析项目列表、推导任务、写入 tasks.md、触发实时任务
非 PDD 驱动路径指南	路径 B 端到端流程——信息收集、项目类型推断、文件系统检测、UI 批量问题、写入 plan.md
多技能模式指南	命名的多技能模式（RPA 构建+部署、包含本地/已部署资源的 Flow、带 RPA 工具的 Agent 等）。路径 A 和 B 均会使用。
规划与任务格式	标题 schema、任务行 schema、身份元组、状态、保留式重新生成算法、TaskCreate 映射、防幻觉规则、质量规则

Anti-patterns

反模式

Skipping the entry guard. Always inspect the input first. A PDD silently treated as a generic doc produces a degraded deliverable.
Writing automation code or modifying the project. SDD and plan/tasks markdown only. In explore-first Lane B mode, non-mutating
```
uip
```
discovery is the upper limit.
Treating a single-project request as a plan — the most common mis-trigger. The inline-nodes rule lives in the Skip paragraph under When to Use This Skill.
Copying the PDD structure into the SDD. The SDD reorganizes content for implementation — it does not mirror the PDD's document flow.
Defaulting to RPA Process when the need profile points elsewhere. Use the Product Selection Guide decision tree on the synthesized need, not keywords: genuine judgment/reasoning → Agents; stages/SLA/approval lifecycle → Case Management ("AI" over a rule-expressible decision is still RPA). Forcing single-product scope when the PDD describes multiple coordinated projects is the same mistake — offer Solution.
Generating an Implementation Plan / task list inside the SDD. Architecture only; the SDD ends with
```
## Next Steps
```
. Task derivation is Lane A's job.
Describing specialist-internal flows in the plan or SDD. Target configuration, OR registration, scaffolding, auth, pack/publish, testing procedures, HITL field schema — all owned by the specialist's own docs. Inlining creates drift.
Asking about test coverage depth. Testing is always thorough. The implementation specialist scopes down at execution time if the user wants a quick MVP; the planner does not offer the option.
Recommending a skill that contradicts filesystem signals.
```
.flow
```
→
```
uipath-maestro-flow
```
, not
```
uipath-rpa
```
.
Inventing selectors from screenshots, or asking the user what the planner / library / filesystem can already answer. Default first; spend a prompt only on decisions only the user can make.
Renaming the
## Planner Handoff
heading or stripping the

marker. Either signal alone is sufficient for detection, but both should remain — removing both breaks Lane A detection silently.
Recommending a product the customer's platform cannot run, or re-offering an excluded one. Defaulting to cloud-modern picks (Maestro, Coded Apps, Document Understanding) on an Automation Suite engagement is the most expensive design error — every blocked product survives review only to fail at delivery. Run the Constraint Gate; once a user says "we don't want X", X stays blocked for the whole session.

跳过入口校验规则：始终先检查输入内容。若将 PDD 默认为通用文档，会导致交付物质量下降。
编写自动化代码或修改项目：仅生成 SDD 和规划/任务格式的 markdown。在路径 B 的探索优先模式下，最多允许执行非破坏性的
```
uip
```
发现操作。
将单项目请求视为规划场景——最常见的误用场景。单项目判断规则见“何时使用本工具”下的跳过说明。
将 PDD 结构复制到 SDD 中：SDD 需重新组织内容以适配落地需求——无需镜像 PDD 的文档流程。
当需求概况指向其他产品时，默认选择 RPA 流程：请根据合成的需求使用产品选择指南决策树，而非关键词：真正需要判断/推理的场景→Agent；包含阶段/SLA/审批生命周期的场景→案例管理（即使是可通过规则表达的“AI”决策仍属于 RPA）。若 PDD 描述了多个协同项目却强制选择单一产品范围，属于同类错误——应提供解决方案选项。
在 SDD 中生成落地计划/任务列表：SDD 仅包含架构内容；结尾需为
```
## 下一步
```
。任务推导是路径 A 的职责。
在规划或 SDD 中描述专业技能工具的内部流程：目标配置、Orchestrator 注册、脚手架、权限、打包/发布、测试流程、人工交互字段 schema——均由专业技能工具自身的文档负责。在此处内联会导致内容不同步。
询问测试覆盖深度：测试始终是全面的。若用户需要快速最小可行产品（MVP），落地阶段专业技能工具可缩小测试范围；规划工具不提供该选项。
推荐与文件系统信号矛盾的技能工具：
```
.flow
```
文件应使用
```
uipath-maestro-flow
```
，而非
```
uipath-rpa
```
。
从截图中编造选择器，或询问规划工具/库/文件系统已能回答的问题。优先使用默认值；仅在用户才能做出决策时使用交互次数。
重命名
## Planner Handoff
标题或移除

标记：任一标记即可满足检测需求，但两者均应保留——同时移除会导致路径 A 检测失败且无提示。
推荐客户平台无法运行的产品，或重新提供用户已排除的产品：在自动化套件项目中默认选择云原生产品（Maestro、编码应用、文档理解）是代价最高的设计错误——所有受限产品即使通过评审，最终也会在交付阶段失败。请执行约束校验规则；一旦用户表示“我们不需要 X”，X 在整个会话中保持禁用。