@uipath/skills 1.195.0 → 1.196.0

package/skills/uipath-maestro-flow/references/shared/cli-commands.md

@@ -14,14 +14,16 @@ uip solution init "<SolutionName>" --output json
 
 # 2. Init the flow project inside the solution folder.
 #    When run from inside a solution directory, `flow init` auto-registers
-#    the project with the parent `.uipx` — no manual `solution project add`
-#    is required. Confirm via `Data.SolutionRegistration.Status` in the
-#    response (`Registered` or `AlreadyRegistered`).
+#    the project with the parent `.uipx` (pass `--skip-solution-registration` to skip) —
+#    no manual `solution project add` is required. Confirm via
+#    `Data.SolutionRegistration.Status` in the response (`Registered` or
+#    `AlreadyRegistered`).
 cd <directory>/<SolutionName> && uip maestro flow init <ProjectName> --output json
 
 # 3. (Fallback only) Wire the project manually if auto-registration was
-#    `Skipped` or `Failed` — typically because init was run outside the
-#    solution dir and produced a single-nested layout.
+#    `NotInSolution` / `Skipped` / `Failed` — typically because init was run
+#    outside the solution dir and produced a single-nested layout. (`OptedOut`
+#    means `--skip-solution-registration` was passed and the skip was intentional.)
 uip solution project add \
   <directory>/<SolutionName>/<ProjectName> \
   <directory>/<SolutionName>/<SolutionName>.uipx
@@ -67,7 +69,7 @@ uip maestro flow format <path/to/file.flow> --output json
 
 Format:
 - Arranges nodes horizontally (left-to-right) and anchors to the leftmost node's original position so the user's general layout intent is preserved
-- Sets every non-`stickyNote` node's `size` to `{ "width": 96, "height": 96 }` — preserving sticky-note custom sizes
+- Sets each node's `size` to match its canvas shape — inline agents (`shape: rectangle`) → `{ "width": 288, "height": 96 }`, containers (loops/groups) → `{ "width": 560, "height": 320 }`, everything else (incl. referenced `uipath.core.agent.<guid>`) → `{ "width": 96, "height": 96 }`; sticky-note custom sizes are preserved
 - Recurses into subflows and rewrites `subflows[<id>].layout` for each
 - Backfills missing `position`/`size` entries
 - Does not modify node logic, edges, definitions, or variables — only layout coordinates
@@ -88,36 +90,36 @@ Requires `content/package-descriptor.json` and `content/operate.json` in the pro
 
 > **Note:** `pack` + `uip solution publish` deploys directly to Orchestrator — the user cannot visualize or edit the flow in Studio Web via this path. Only use this when the user explicitly asks to deploy to Orchestrator. The default publish path is `uip solution upload` (see below). See [uipath-solution](/uipath:uipath-solution) for `solution publish` commands.
 
-## uip solution resource refresh
+## uip solution resources refresh
 
 Re-scan all projects in the solution and sync resource declarations (connections, processes, queues, etc.) from their `bindings_v2.json` files. Creates new resources for bindings not yet in the solution, imports from Orchestrator when a matching resource exists. **Always run this before `uip solution upload` or `uip maestro flow debug`.**
 
 ```bash
-uip solution resource refresh <SolutionDir> --output json
+uip solution resources refresh --solution-folder <SolutionDir> --output json
 ```
 
-The argument is the solution directory (containing the `.uipx` file). Defaults to the current directory if omitted.
+`<SolutionDir>` is the solution directory (containing the `.uipx` file). The command has no positional solution argument; omit `--solution-folder` only when the current directory is already the solution root.
 
-## uip solution resource add / remove / edit
+## uip solution resources add / remove / edit
 
 Atomic single-resource mutations. Use these when you need to add, delete, or change one resource and don't want to scan every project's bindings the way `refresh` does — for example, when a flow needs a new local queue but no `bindings_v2.json` change is involved yet.
 
 ```bash
 # Local virtual stub (offline, no auth)
-uip solution resource add --source local --kind Queue --name InvoiceQueue --output json
+uip solution resources add --source local --kind Queue --name InvoiceQueue --output json
 
 # Import an existing Orchestrator resource
-uip solution resource add --source remote --kind Queue --name InvoiceQueue --folder-path Sales/CRM --output json
+uip solution resources add --source remote --kind Queue --name InvoiceQueue --folder-path Sales/CRM --output json
 
 # Delete one resource by key
-uip solution resource remove <KEY> --output json
+uip solution resources remove <KEY> --output json
 
 # Patch an existing resource's spec by key (JSON object is the only input)
-uip solution resource edit <KEY> --patch '{"maxNumberOfRetries":5}' --output json
-uip solution resource edit <KEY> --patch '{"acceptAutomaticallyRetry":false,"retentionPeriod":14}' --output json
+uip solution resources edit <KEY> --patch '{"maxNumberOfRetries":5}' --output json
+uip solution resources edit <KEY> --patch '{"acceptAutomaticallyRetry":false,"retentionPeriod":14}' --output json
 
 # Read the patch from stdin
-echo '{"slaInHours":"4"}' | uip solution resource edit <KEY> --patch - --output json
+echo '{"slaInHours":"4"}' | uip solution resources edit <KEY> --patch - --output json
 ```
 
 `add` is idempotent on `(kind, name, folder)` for local and on resource key for remote; a retry returns `Status: "Unchanged"`. `edit` is the only command that mutates an existing resource's spec — `refresh` never overwrites; it skips resources already in the solution. None of these touch `bindings_v2.json` — if a flow node still binds the resource, the next `refresh` will re-import it. See [uipath-solution Step 9–11](/uipath:uipath-solution) for the full contract.
@@ -130,7 +132,7 @@ Upload a solution directly to Studio Web. **Requires `uip login`.**
 uip solution upload <SolutionDir> --output json
 ```
 
-`uip solution upload` accepts the solution directory (the folder containing the `.uipx` file) directly — no intermediate bundling step is required. Uploads the solution to Studio Web where the user can visualize, inspect, edit, and publish the flow from the browser.
+`uip solution upload` accepts the solution directory (the folder containing the `.uipx` file) directly — no intermediate bundling step is required. Use the exact solution root path (or `.` from inside the solution root). If your shell is inside a nested project folder, pass the absolute solution root path or `..`; do not pass the solution name again. Uploads the solution to Studio Web where the user can visualize, inspect, edit, and publish the flow from the browser.
 
 > **This is the default publish path.** When the user asks to "publish" without specifying where, run `uip solution upload <SolutionDir>` to push to Studio Web. Share the resulting URL with the user.
 

package/skills/uipath-maestro-flow/references/shared/cli-conventions.md

@@ -119,7 +119,7 @@ Always check `Result` first. On failure, `Message` and `Instructions` carry the
 | Capability | Login required? |
 |---|---|
 | **Author** | No — `flow init`, `validate`, `format`, registry (OOTB nodes), `Edit` / `Write` edits, planning all work offline |
-| **Operate** | **Yes** — `solution upload`, `solution resource refresh`, `flow debug`, `flow pack`, `process run`, `job status`, `job traces` all require `uip login` |
+| **Operate** | **Yes** — `solution upload`, `solution resources refresh`, `flow debug`, `flow pack`, `process run`, `job status`, `job traces` all require `uip login` |
 | **Diagnose** | **Yes** — `instance incidents`, `instance variables`, `instance asset`, `incident get`, `incident summary` all require `uip login` |
 
 Tenant-specific connector and resource nodes in the registry also require login. Without login, registry shows OOTB nodes only. **In-solution sibling projects** are always available via `--local` without login.

package/skills/uipath-maestro-flow/references/shared/file-format.md

@@ -215,7 +215,7 @@ Each key in `layout.nodes` is a node `id`. `flow format` creates an entry for ev
 
 **What format does:**
 - Arranges nodes horizontally (left-to-right) with `nodeSpacing: 96`, anchored to the leftmost node's original position
-- Sets `size` to `{ "width": 96, "height": 96 }` on every non-`stickyNote` node — non-96 sizes render as rectangles in Studio Web
+- Sets each node's `size` to match its canvas shape: inline agents (`uipath.agent.autonomous` / `uipath.agent.conversational`, `shape: rectangle`) → `{ "width": 288, "height": 96 }`; containers (loops/groups) → `{ "width": 560, "height": 320 }`; everything else — including referenced `uipath.core.agent.<guid>` nodes — → `{ "width": 96, "height": 96 }`. A size that disagrees with the node's shape renders misshapen in Studio Web.
 - Skips `stickyNote` nodes from layout (they keep their custom position and size)
 - Recurses into every subflow and rewrites its `subflows[<id>].layout` map
 

package/skills/uipath-maestro-flow/references/shared/ux-narration-and-todos.md

@@ -12,14 +12,14 @@ Engage narration + todos when **any** of these hold:
 - User expresses a standing preference for verbosity (in-session, or via a recalled memory / preference).
 - User asks a question that only makes sense with running commentary ("what are you doing right now?", "where are we?").
 
-**Default — silent mode.** When none of the above hold, do the work quietly. Surface only: decisions (`AskUserQuestion`), failures, consent gates (`flow debug`), and the final result. No per-step narration line; no user-facing `TodoWrite` list. The agent MAY still keep todos privately on large journeys for its own tracking, but it is not required and is not a user-facing contract.
+**Default — silent mode.** When none of the above hold, do the work quietly. Surface only: decisions (user questions), failures, consent gates (`flow debug`), and the final result. No per-step narration line; no user-facing todo list. The agent MAY still keep todos privately on large journeys for its own tracking, but it is not required and is not a user-facing contract.
 
 ## The two rules
 
 These apply **only once engaged** (see When to engage):
 
 1. **Narrate every logical step in plain English** — one short line before each step explaining what the agent is doing and why, in terms of the user's request. The user should never need to know `bash`, `uip` flags, or `.flow` JSON internals to follow along.
-2. **Maintain a granular `TodoWrite` list** for any journey above the trivial threshold — one todo per logical step, kept current as work proceeds. Standard journeys typically land at 10+ items; complex flows go higher. The count emerges from the journey's actual logical steps — do not target a number.
+2. **Maintain a granular progress list** for any journey above the trivial threshold — one todo per logical step, kept current as work proceeds. Standard journeys typically land at 10+ items; complex flows go higher. The count emerges from the journey's actual logical steps — do not target a number.
 
 ## What is a "logical step"
 
@@ -42,7 +42,7 @@ Bash plumbing inside a step is invisible to the user — the step's narration li
 | Start of a logical step | **Narrate.** One short line, plain English, user terms. |
 | Multiple actions within the same step | No additional narration — the step's opening line covers them |
 | Step transitions (one outcome done, next starting) | Narrate the next step |
-| Decision point | Brief one-liner before `AskUserQuestion` ("This decision affects which connection binding I generate — choose one:") |
+| Decision point | Brief one-liner before asking the user ("This decision affects which connection binding I generate — choose one:") |
 | Failure / retry | Always narrate — explain what failed and what's being tried next. Failures surface even in silent mode. |
 | Trivial probe (`uip --version`, repeated `login status` in same minute) | Skip |
 | Non-`uip` shell commands (`ls`, `cat`, `mkdir`, `cd`) used as plumbing inside a step | Skip — covered by the step's opening narration |
@@ -91,11 +91,11 @@ Reference table — adapt to context. Add subject (what's being acted on) when s
 | Flow correlation | "Mapping the faulting element ID back to a node in your `.flow` file…" |
 | Traces (last resort) | "Pulling traces. Last resort — the previous steps weren't enough." |
 
-## Threshold for `TodoWrite`
+## Threshold for the progress list
 
 This table applies only once narration/todos are engaged (see [When to engage](#when-to-engage)). In silent mode there is no user-facing narration or todo list regardless of journey size.
 
-| Journey size | Narration | TodoWrite |
+| Journey size | Narration | Progress list |
 | --- | --- | --- |
 | Single edit (1–2 actions, no decisions) | Yes — 1 line | No |
 | Small edit (3–5 actions or 1 decision) | Yes — line per logical step | Optional, agent's call |
@@ -131,7 +131,7 @@ A todo is a **state-changing outcome the user cares about**. One logical step
 If the user redirects scope mid-journey ("skip the connector — use HTTP instead"):
 
 1. Narrate the pivot — "Switching from connector to HTTP node. Updating todos."
-2. Update `TodoWrite`:
+2. Update the progress list:
    - Mark obsolete in-flight todos as cancelled and drop them from the list.
    - Insert new todos for the new direction at the right spot.
    - Leave completed todos in place — they're history, not work.
@@ -145,6 +145,6 @@ If the user redirects scope mid-journey ("skip the connector — use HTTP instea
 - **Never narrate or spin up a user-facing todo list when the user hasn't asked for verbosity.** Silent by default. Surfacing every step unprompted is noise.
 - **When engaged, never skip narration on a step transition.** Silent transitions leave the user lost.
 - **Never create a todo per bash call.** Todos are user-meaningful outcomes, not the agent's internal action log.
-- **When engaged, never skip `TodoWrite` on a standard journey.** Above the trivial threshold, the granular list is mandatory.
+- **When engaged, never skip the progress list on a standard journey.** Above the trivial threshold, the granular list is mandatory.
 - **Never use first-person filler.** "Let me…", "I'll go ahead and…", "I'm going to…" — drop. Lead with the verb.
 - **Never repeat the prior line's content.** If the previous narration said "Adding the Slack node and wiring its inputs", the next line is *not* "Adding the Slack node now" — it's the next step.

package/skills/uipath-planner/SKILL.md

@@ -1,84 +1,99 @@
 ---
 name: uipath-planner
-description: "UiPath task planner — reads SDDs from uipath-solution or elicits non-PDD requests, derives multi-skill task lists, emits live TaskCreate calls. Detects project type (.cs, .xaml, .flow, .bpmn, .py). For PDDs→uipath-solution first."
-when_to_use: "User makes a non-trivial UiPath request that spans SEPARATE buildable projects — e.g. 'build a UiPath solution for X', 'set up a process from scratch', a Flow that orchestrates standalone RPA processes or agents — OR provides an SDD path. Skip when the request targets a SINGLE project, even a Flow/Agent/RPA project with inline HITL, script, or connector nodes wrapped in its own solution (e.g. a Flow with an inline approval step is one uipath-maestro-flow task, not a plan) — invoke that specialist directly."
-allowed-tools: Bash, Read, Glob, Grep, AskUserQuestion, EnterPlanMode, ExitPlanMode, TaskCreate, TaskUpdate, TaskList
+description: "UiPath solution planner & designer. Always invoke for `pdd.md` / `sdd.md` files. Authors a Solution Design Document (SDD) from a Process Design Document (PDD), then derives the multi-skill, multi-project task list and emits live TaskCreate calls. Detects project type (.cs, .xaml, .flow, .bpmn, .py). For `uip solution` init/pack/publish/deploy/activate & `.uipx`→uipath-solution. For non-solution Orchestrator/IS/auth/traces→uipath-platform. For .xaml/.cs→uipath-rpa. For .flow→uipath-maestro-flow. For .bpmn→uipath-maestro-bpmn. For agent.json/.py→uipath-agents. For caseplan.json→uipath-maestro-case."
+when_to_use: "User provides a PDD/SDD, says 'generate SDD'/'analyze this PDD'/design/architect/'turn this PDD into' a UiPath solution (selects product scope), OR makes a non-trivial request spanning SEPARATE buildable projects (a Flow orchestrating standalone RPA processes or agents that must themselves be built, 'build a solution from scratch'). Load BEFORE authoring an SDD or deriving tasks. Skip for SINGLE-project requests — even a Flow/Agent/RPA project with inline HITL/script/connector nodes in its own solution — invoke that specialist directly. Flow calling only existing/deployed processes→uipath-maestro-flow."
+allowed-tools: Bash, Read, Write, Glob, Grep, AskUserQuestion, EnterPlanMode, ExitPlanMode, TaskCreate, TaskUpdate, TaskList
 ---
 
-# UiPath Task Planner
+# UiPath Planner — Design & Task Derivation
 
-Your job is to **derive task lists, route to specialists, and emit live tasks** — never execute the work yourself.
+Two jobs, one entry point:
 
-The planner has two lanes:
+1. **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.
+2. **Plan** — derive the per-skill task list from an SDD (or a non-PDD request), route to specialists, emit live `TaskCreate` calls.
 
-- **Lane A — PDD-driven.** Triggered when the input is an SDD with a `## Planner Handoff` header. Reads the SDD, derives tasks per the project list, writes `<process>-tasks.md`, emits live `TaskCreate` calls. Zero or one user prompt. See [pdd-driven-lane-guide.md](references/pdd-driven-lane-guide.md).
-- **Lane B — Non-PDD.** Triggered when there's no SDD. Elicits preferences via a batched `AskUserQuestion`, detects project type, multi-skill patterns or filesystem signals, writes `<feature>.md`, emits live tasks. Typically 0–3 user prompts (5-call hard cap). See [non-pdd-lane-guide.md](references/non-pdd-lane-guide.md).
+Never execute the work. Outputs are SDD markdown, plan/tasks markdown, and live tasks — implementation always routes to a specialist.
 
-The lane is decided by the **Entry Guard** below.
+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, then fall through into Lane A. See [sdd-generation-guide.md](references/sdd-generation-guide.md).
+- **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](references/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](references/non-pdd-lane-guide.md).
 
 ## When to Use This Skill
 
-- The request is **non-trivial** — spans **separate buildable projects** that each need their own specialist (e.g. a Flow orchestrating standalone RPA processes or agents), or UI automation with unclear scope
-- The request is **ambiguous** — no single specialist skill clearly matches
-- The user asks "what can I build?" or needs help choosing a project type
-- The user provides an SDD path — Lane A runs
+- User provides a **PDD** (PDF, docx, markdown) 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
+- 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 planner 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 the solution scaffolding are author sub-steps the specialist performs itself — they are **not** separate skills to orchestrate. Counting them as distinct skills ("solution + flow + human-in-the-loop") and emitting a plan is the most common mis-trigger. The planner is only for requests spanning **separate buildable projects** — distinct `.uipx` projects (a Flow consuming standalone RPA processes, an Agent using published processes as tools).
+**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.
 
 ## Critical Rules
 
-1. **Plan only — never execute the work yourself.** Do NOT write automation code (XAML, C#, Python, JSON) or create project files. Plan / tasks files and live `TaskCreate` calls are the only outputs you produce.
-2. **For PDDs, hard-block and redirect to `uipath-solution`.** A PDD (PDF, docx, or markdown describing process steps + applications + exceptions) does NOT belong in this skill. The dedicated PDD→SDD skill produces a much better deliverable. The only escape is the user explicitly saying "skip SDD".
-3. **Never exceed 5 `AskUserQuestion` calls in any planning session.** Each call is one user-facing prompt; batch related questions (e.g., the Step 4 UI elicitation in Lane B batches App type, Targeting approach, App state into one call). If you cannot fit the elicitation in 5 calls, plan with best available info and note the assumption. Lane A typically uses 0–2 calls.
-4. **Always include a mandatory Testing task per generation skill** in the plan. Testing is non-negotiable — happy path + edge cases + error scenarios + e2e for Master Projects. The Testing task routes to the specialist's testing references and does NOT describe the testing procedure inline.
-5. **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 authoring pipelines, **HITL field/outcome schema design**, auth flows, testing procedures). Each specialist's docs own those details. **For a HITL step, pass the business intent only** ("manager approves or rejects an expense; can add a reason if rejected") — never a field-level spec (do not prescribe field names, types like `approved: boolean`, `required` flags, or outcome lists). The HITL specialist chooses the schema shape (boolean decision field vs Approve/Reject outcomes) from the intent; a field-level prescription forces one shape and defeats that choice.
+1. **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.)
+2. **Run the Entry Guard first.** Inspect the input and route to Phase D / Lane A / Lane B before anything else.
+3. **Select scope before designing architecture (Phase D).** Single product (RPA Process/Library/Test Auto, Maestro Flow, Case, Agents, Coded Apps, API Workflows) vs multi-project Solution determines the template(s) and project structure. Use the [Product Selection Guide](references/product-selection-guide.md): Level 1 → 1.5 (RPA sub-type) → 1.75 (Solution composition) → 2.5 (project decomposition).
+4. **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.)
+5. **Write the `## Planner Handoff` header AND the `<!-- planner-handoff:v1 -->` marker into every SDD.** Load-bearing detection contract — the Entry Guard detects either signal (redundant on purpose). `Generated by: uipath-planner`. Fields: Execution autonomy, SDD scope, Project list section, Tasks file, Generated by, Generation date.
+6. **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 is an SDD defect, not an `[SME REVIEW]` item — regenerate it.
+7. **Testing is mandatory and thorough — never offer "happy path only".** Phase D writes a full §17 Testing Strategy (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.
+8. **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.
+9. **Per-phase prompt budget.** Phase D runs under its own checkpoint model (see [sdd-generation-guide.md](references/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.
+10. **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.
+11. **The terminal artefact of a Solution build is a packed `.uipx`.** The SDD's §18 Next Steps 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.
+12. **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.
 
 ## Entry Guard
 
-When the planner is invoked, run this guard before anything else.
+Run this guard before anything else.
 
-```
-1. Did the user reference a document path?
-   - No → Lane B (non-PDD elicitation)
+```text
+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.
+   - Otherwise → Lane B. Lane B is the default for document-less
+     multi-project requests.
 
-2. The path resolves to a file. Read its first ~50 lines.
-   - File contains the heading `## Planner Handoff` OR the HTML-comment marker `<!-- planner-handoff:v1 -->` → Lane A (read SDD, derive tasks). Either signal is sufficient — they are redundant on purpose so a renamed heading does not silently break detection.
+2. Document path → read its first ~50 lines.
+   - Contains `## Planner Handoff` OR `<!-- planner-handoff:v1 -->` → Lane A.
+     (Either signal alone is sufficient — redundant on purpose.)
+   - Reads as a PDD (process steps + application inventory + exceptions),
+     or is a binary .pdf/.docx the user calls a PDD → Phase D.
 
-3. Otherwise (no marker, or unparseable / binary file like .pdf / .docx):
-   ask via AskUserQuestion:
+3. Otherwise (no marker, ambiguous, or unparseable) — ask via AskUserQuestion:
 
    > What is the document at <path>?
-   > 1. Solution Design Document (SDD) — proceed with task generation (Lane A, hand-written SDD)
-   > 2. Process Design Document (PDD) — load uipath-solution first
-   > 3. Other context — note its existence; proceed with non-PDD elicitation (Lane B)
-
-4. Based on user's choice:
-   - SDD → Lane A. Try to find the Planner Handoff header; if missing, proceed with safe defaults
-     (interactive autonomy, single-product scope) and log a one-line warning.
-   - PDD → HARD BLOCK with this message:
-
-     > The document at <path> is a Process Design Document. UiPath has a dedicated skill
-     > for PDD→SDD generation that produces a much better deliverable: uipath-solution.
-     > Load it with this PDD path; it will produce an SDD that I can then use to generate
-     > the task list.
-     >
-     > If you've already considered the SDD path and want a lightweight plan from this PDD
-     > anyway, tell me "skip SDD" and I'll proceed with degraded inline reading (Lane B + PDD
-     > as context).
-
-   - Other context → Lane B, with the document path noted in plan header.
+   > 1. Process Design Document (PDD) — author the SDD (Phase D), then derive tasks
+   > 2. Solution Design Document (SDD) — proceed with task generation (Lane A)
+   > 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)
+
+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.
 ```
 
-The `## Planner Handoff` heading **and** the `<!-- planner-handoff:v1 -->` marker are the load-bearing detection contract — `uipath-solution` writes both deterministically, this skill detects either. Templates ship with both; either alone is enough to take Lane A. Do not pattern-match on filename or extension; those are unreliable.
+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.
+
+## Phase D — Design (summary)
+
+When triggered: input is a PDD, or an explicit design/architect request. Three phases; full detail in [sdd-generation-guide.md](references/sdd-generation-guide.md). All user questions use numbered-choice format.
+
+1. **Phase 1 — PDD Analysis & Scope Selection.** Ask execution mode (Autonomous or Interactive). Read the full PDD, extract structured information, run 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.
+2. **Phase 2 — Architecture Review.** Load the product-specific template. Generate the architectural core sections. Present for review in Interactive mode.
+3. **Phase 3 — Full SDD Generation.** Generate all remaining sections including the thorough §17 Testing Strategy. Resolve `[SME REVIEW]` items first. Write the `## Planner Handoff` header + marker. Write the SDD to disk. **Fall through into Lane A** to derive tasks.
 
 ## Lane A — PDD-driven (summary)
 
-When triggered: SDD detected at entry guard.
+When triggered: an SDD with the `Planner Handoff` marker is detected (or Phase D just wrote one).
 
-1. Read the SDD's `## Planner Handoff` header (6 fields: Execution autonomy, SDD scope, Project list section, Tasks file, Generated by, Generation date).
-2. If `<process>-tasks.md` already exists, ask `continue / regenerate` (1 prompt). Regenerate preserves completed work via task identity matching — see [plan-and-tasks-format.md → Regenerate logic](references/plan-and-tasks-format.md#regenerate-logic-pdd-driven-lane-only).
+1. Read the SDD's `## Planner Handoff` header (6 fields). Reuse the execution autonomy chosen in Phase D — do not re-ask.
+2. If `<process>-tasks.md` already exists, ask `continue / regenerate` (1 prompt). See [plan-and-tasks-format.md → Regenerate logic](references/plan-and-tasks-format.md#regenerate-logic-pdd-driven-lane-only).
 3. Parse the SDD project list section. Pick the multi-skill pattern.
-4. Ask the Step 4 UI batch (3 questions, 1 call) only if the SDD's Application Inventory section lists UI applications and the answers aren't already resolved from context.
+4. 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.
 5. Derive tasks. Write `<process>-tasks.md`.
 6. If `Execution autonomy: interactive` → `EnterPlanMode` for review. If `autonomous` → emit live tasks directly.
 7. Emit `TaskCreate` calls + `addBlockedBy` edges. Hand off.
@@ -87,12 +102,12 @@ Full procedure: [pdd-driven-lane-guide.md](references/pdd-driven-lane-guide.md).
 
 ## Lane B — Non-PDD (summary)
 
-When triggered: no SDD; user described a task or asked for help planning one.
+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).
 
-1. Step 1 — batched elicitation: bundle Q1 (generation approach) + Q2 (execution autonomy) + Q3 (project-type fallback, only when project type is vague) + Q5 (Solution scope, only when plan loads `uipath-maestro-flow`) into **one** `AskUserQuestion` call. Drop any question already resolved from context; if all resolve, skip the call entirely.
+1. Step 1 — batched elicitation: bundle generation approach + execution autonomy + project-type fallback (when vague) + Solution scope (when the plan loads `uipath-maestro-flow`) into **one** `AskUserQuestion` call. Drop any question already resolved from context.
 2. Step 2 — detect multi-skill patterns; emit multi-skill plan if applicable. See [multi-skill-patterns-guide.md](references/multi-skill-patterns-guide.md).
 3. Step 3 — filesystem detection for single-skill plans.
-4. Step 4 UI batch — only when plan includes UI automation in `uipath-rpa` (one batched `AskUserQuestion` for App type / Targeting approach / App state).
+4. Step 4 UI batch — only when the plan includes UI automation in `uipath-rpa`.
 5. Write `YYYY-MM-DD-<feature>.md` to `docs/plans/` (project) or `./plans/` (no project).
 6. If explore-first → `EnterPlanMode`. If simultaneous → emit plan as text + live tasks.
 
@@ -107,13 +122,40 @@ High-level view of what each specialist owns. **Do not describe internal flows o
 | `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-maestro-flow` | `.flow` files orchestrating RPA, agents, apps | Yes (`uip login`) | **Partial** — follows plan `Solution scope` (SW or local); `uipath-platform` for Orchestrator |
+| `uipath-maestro-flow` | `.flow` files orchestrating RPA, agents, apps | Yes (`uip login`) | **Partial** — follows plan `Solution scope` (SW or local); Orchestrator deploy of `.uipx`-wrapped solutions → `uipath-solution`; non-solution single package → `uipath-platform` |
+| `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 / Maestro / coded-agent projects | 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), traces, licensing | Yes (auth hub) | **Yes** — for non-solution single packages and Orchestrator-side post-deploy ops |
-| `uipath-mcp-servers` | UiPath AgentHub MCP server registration (6 types: `uipath`, `coded`, `command`, `remote`, `swagger`, `platform`) and tool authoring on `uipath`-type servers (3 kinds: `is-activity`, `resource`, `raw`). Wraps IS connector activities (Jira, Slack, Outlook, Salesforce, ...), Orchestrator resources (process / agent / api-workflow), external HTTP MCP endpoints, OpenAPI specs, published coded agents (as Orchestrator processes), local subprocess commands, or first-party UiPath services as MCP tools agents can consume. NOT for FastMCP / Python `mcp` SDK / `uipath-mcp-python` server-implementation work. | Yes (`uip login`) | **Yes** — registration is deployment (posts directly to AgentHub) |
-| `uipath-solution` | PDD→SDD architecture authoring AND `uip solution` lifecycle (init, pack, publish, deploy, activate). Runs in PDD-driven flows as the first skill (design) and again as the final skill (deploy of `.uipx` solutions). | Yes (`uip login` for ops half) | **Yes** — for multi-project Solution (`.uipx`) deploys |
+| `uipath-mcp-servers` | UiPath AgentHub MCP server registration (6 types: `uipath`, `coded`, `command`, `remote`, `swagger`, `platform`) and tool authoring on `uipath`-type servers (3 kinds: `is-activity`, `resource`, `raw`). Wraps IS connector activities, 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 |
 
 ## Reference Navigation
 
+### Phase D — Design
+
+| File | Purpose |
+|------|---------|
+| [SDD Generation Guide](references/sdd-generation-guide.md) | Phase orchestrator — Phase 1, 2, 3 step-by-step instructions |
+| [PDD Analysis Guide](references/pdd-analysis-guide.md) | How to extract structured data from PDDs in any format |
+| [Product Selection Guide](references/product-selection-guide.md) | **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 |
+| [RPA Product Guide](references/rpa-product-guide.md) | 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](references/package-selection-guide.md) | NuGet package selection; Integration Service vs NuGet rules; per-product dependency manager. Load when filling §14 Packages or equivalent. |
+| [Tenant Library Search Guide](references/tenant-library-search-guide.md) | Step 2.5 procedure for discovering deployed libraries via `uip or libraries list` + JMESPath filtering — auth preflight, ranking, zero-results branch, manual fallback. |
+
+### SDD templates
+
+| File | Purpose |
+|------|---------|
+| [RPA Template](assets/templates/rpa-sdd-template.md) | SDD template for RPA Process / Library / Test Automation |
+| [Flow Template](assets/templates/flow-sdd-template.md) | SDD template for Maestro Flow |
+| [Case Management Template](assets/templates/case-sdd-template.md) | SDD template for Case Management |
+| [Agent Template](assets/templates/agent-sdd-template.md) | SDD template for UiPath Agents |
+| [Coded App Template](assets/templates/coded-app-sdd-template.md) | SDD template for Coded Apps (web) |
+| [API Workflow Template](assets/templates/api-workflow-sdd-template.md) | SDD template for API Workflows |
+
+### Lanes A & B — Planning
+
 | File | Purpose |
 |------|---------|
 | [PDD-driven Lane Guide](references/pdd-driven-lane-guide.md) | Lane A end-to-end — read SDD header, parse project list, derive tasks, write tasks.md, emit live tasks |
@@ -123,20 +165,14 @@ High-level view of what each specialist owns. **Do not describe internal flows o
 
 ## Anti-patterns
 
-1. **Skipping the entry guard.** Always inspect the input first. A PDD silently treated as a generic doc produces a degraded plan and skips the dedicated SDD skill.
-2. **Writing automation code or modifying the project.** Plans only. In explore-first Lane B mode, non-mutating `uip` discovery is allowed; that's the upper limit.
-3. **Exceeding 5 `AskUserQuestion` calls.** If the elicitation can't fit, plan with best available info and note the assumption.
-4. **Recommending a skill that contradicts filesystem signals.** `.flow` files → `uipath-maestro-flow`, not `uipath-rpa`.
-5. **Asking the UI-targeting batch when the plan has no UI automation.** Pure data processing, API calls, agent-only, flow-only plans skip Step 4 entirely.
-6. **Describing specialist-internal flows in the plan.** Target-configuration procedures, OR registration, scaffolding pipelines, auth steps, pack/publish details, testing procedures — all owned by the specialist's own docs. Inlining creates drift.
-7. **Saving a plan with placeholders** (TBD, TODO, as needed, similar to Task N).
-8. **Asking the user to choose between XAML and C#.** Project type is inferred from the request; RPA workflows are XAML by default. Coded mode is set only when the user independently says "coded workflow", "C# workflow", or ".cs file".
-9. **Surfacing C# as recommended for routine UI automation.** Form-fill, Type Into, Click, dropdown selection, Excel / email / file work — all bread-and-butter XAML. C# coded fallback is an internal `uipath-rpa` decision for individual subtasks, never a top-level recommendation from the planner.
-10. **Adding a third option to the UI-targeting question.** Only two options exist: "I build it, you review it" (default) and "You indicate each element". Never invent a third "build it manually" option — a developer choosing manual authoring wouldn't be using a coding agent.
-11. **Leaking internal jargon or implementation details into user-facing questions.** Never mention "snapshot", "hand-wire", "AutomationId", "selector candidate", "autonomous capture", "target configuration". Speak in plain developer language: "the live app", "Studio", "elements", "selectors", "inspect", "discover".
-12. **Injecting domain or app names into question text.** Ask "What kind of application are we automating?" — not "What kind of HR application…". Domain lives in the plan header, not the questions.
-13. **Omitting the mandatory Testing task per generation skill.** Every generation skill in the plan gets a `Testing (MANDATORY)` task that routes to that skill's testing references. Never replace it with a `Validate:` sub-step. Never describe test-case authoring / data-driven testing / mock testing in the plan.
-14. **Asking about test coverage depth.** Testing is always thorough. The implementation specialist can scope down at execution time if the user wants a quick MVP; the planner does not offer the option.
-15. **Omitting `Execution autonomy` from the plan header, or leaving `Stop conditions` empty when autonomy is `autonomous`.** Downstream specialists rely on both to decide whether to interrupt. Populate `Stop conditions` with the hard blockers realistic for this specific plan (auth, app state, element-capture limits, missing resources) — do not leave a generic placeholder.
-16. **Generating an SDD or copying SDD content into the plan.** SDD is owned by `uipath-solution`. The plan references SDD section paths in skill prompts but does not duplicate architecture content.
-17. **Asking the user what the planner / library / filesystem can already answer.** Project type is resolved by explicit naming, keyword signals, and filesystem detection before any prompt fires. Skill capability is fixed in the capability map — never ask "which skill should I use". Existence of a `project.json`, `.flow`, `.uipath/`, or `pyproject.toml` is observable. Default first; ask only when no safe default applies. A user prompt is the most expensive resource the planner has — spend it on decisions only the user can make.
+1. **Skipping the entry guard.** Always inspect the input first. A PDD silently treated as a generic doc produces a degraded deliverable.
+2. **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.
+3. **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.
+4. **Copying the PDD structure into the SDD.** The SDD reorganizes content for implementation — it does not mirror the PDD's document flow.
+5. **Defaulting to RPA Process when the PDD describes something else.** Use the Product Selection Guide decision tree. AI-reasoning signals → Agents; stages/SLA/approval → Case Management. Forcing single-product scope when the PDD describes multiple coordinated projects is the same mistake — offer Solution.
+6. **Generating an Implementation Plan / task list inside the SDD.** Architecture only; the SDD ends with `## Next Steps`. Task derivation is Lane A's job.
+7. **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.
+8. **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.
+9. **Recommending a skill that contradicts filesystem signals.** `.flow` → `uipath-maestro-flow`, not `uipath-rpa`.
+10. **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.
+11. **Renaming the `## Planner Handoff` heading or stripping the `<!-- planner-handoff:v1 -->` marker.** Either signal alone is sufficient for detection, but both should remain — removing both breaks Lane A detection silently.

package/skills/{uipath-solution → uipath-planner}/assets/templates/agent-sdd-template.md

@@ -23,7 +23,7 @@
 | **SDD scope** | <single-product \| solution> |
 | **Project list section** | §9 Project Structure |
 | **Tasks file** | `<AGENT_NAME_KEBAB>-tasks.md` |
-| **Generated by** | uipath-solution v<VERSION> |
+| **Generated by** | uipath-planner |
 | **Generation date** | <YYYY-MM-DD> |
 
 ---
@@ -31,7 +31,7 @@
 <!--
 EMIT THIS BLOCK ONLY when Execution autonomy: autonomous.
 Skip entirely in interactive mode (decisions were checkpoint-reviewed).
-See sdd-generation-guide.md Phase 3 Step 3a for the format spec.
+See sdd-generation-guide.md Phase 3 Step 2 item 3 for the format spec.
 Non-RPA scope: rows collapse to scope + product-specific Level-1.5-equivalent.
 -->
 ## Decisions Made
@@ -48,7 +48,7 @@ Non-RPA scope: rows collapse to scope + product-specific Level-1.5-equivalent.
 <!--
 EMIT THIS BLOCK ONLY when at least one [SME REVIEW] item remains after Step 1.5 resolution.
 Skip entirely when no review items are open.
-See sdd-generation-guide.md Phase 3 Step 3 for the format spec.
+See sdd-generation-guide.md Phase 3 Step 2 item 4 for the format spec.
 -->
 ## Action Required — SME Review Items
 

package/skills/{uipath-solution → uipath-planner}/assets/templates/api-workflow-sdd-template.md

@@ -23,7 +23,7 @@
 | **SDD scope** | <single-product \| solution> |
 | **Project list section** | §10 Project Structure + §5 Connectors |
 | **Tasks file** | `<API_WORKFLOW_NAME_KEBAB>-tasks.md` |
-| **Generated by** | uipath-solution v<VERSION> |
+| **Generated by** | uipath-planner |
 | **Generation date** | <YYYY-MM-DD> |
 
 ---
@@ -31,7 +31,7 @@
 <!--
 EMIT THIS BLOCK ONLY when Execution autonomy: autonomous.
 Skip entirely in interactive mode (decisions were checkpoint-reviewed).
-See sdd-generation-guide.md Phase 3 Step 3a for the format spec.
+See sdd-generation-guide.md Phase 3 Step 2 item 3 for the format spec.
 Non-RPA scope: rows collapse to scope + product-specific Level-1.5-equivalent.
 -->
 ## Decisions Made
@@ -48,7 +48,7 @@ Non-RPA scope: rows collapse to scope + product-specific Level-1.5-equivalent.
 <!--
 EMIT THIS BLOCK ONLY when at least one [SME REVIEW] item remains after Step 1.5 resolution.
 Skip entirely when no review items are open.
-See sdd-generation-guide.md Phase 3 Step 3 for the format spec.
+See sdd-generation-guide.md Phase 3 Step 2 item 4 for the format spec.
 -->
 ## Action Required — SME Review Items
 
@@ -291,7 +291,7 @@ This SDD captures architecture and decisions. To generate the implementation tas
 
 > Load `uipath-planner`. SDD path: `<this-file>`.
 
-The planner detects the `## Planner Handoff` header, parses §10 Project Structure and §5 Connectors, derives the per-skill task list (routing each task to the API Workflow specialist, `uipath-platform`, etc.), writes `<API_WORKFLOW_NAME_KEBAB>-tasks.md` alongside this SDD, and emits live `TaskCreate` calls. If `Execution autonomy: interactive`, it enters plan mode for task review before execution.
+The planner detects the `## Planner Handoff` header, parses §10 Project Structure and §5 Connectors, derives the per-skill task list (routing each task to `uipath-api-workflow`, `uipath-platform`, etc.), writes `<API_WORKFLOW_NAME_KEBAB>-tasks.md` alongside this SDD, and emits live `TaskCreate` calls. If `Execution autonomy: interactive`, it enters plan mode for task review before execution.
 
 Implementation tasks **do not live in this SDD** — they live in the planner's output.
 

package/skills/{uipath-solution → uipath-planner}/assets/templates/case-sdd-template.md

@@ -23,7 +23,7 @@
 | **SDD scope** | <single-product \| solution> |
 | **Project list section** | §15 Project Structure + §14 Integrated Components |
 | **Tasks file** | `<CASE_NAME_KEBAB>-tasks.md` |
-| **Generated by** | uipath-solution v<VERSION> |
+| **Generated by** | uipath-planner |
 | **Generation date** | <YYYY-MM-DD> |
 
 ---
@@ -31,7 +31,7 @@
 <!--
 EMIT THIS BLOCK ONLY when Execution autonomy: autonomous.
 Skip entirely in interactive mode (decisions were checkpoint-reviewed).
-See sdd-generation-guide.md Phase 3 Step 3a for the format spec.
+See sdd-generation-guide.md Phase 3 Step 2 item 3 for the format spec.
 Non-RPA scope: rows collapse to scope + product-specific Level-1.5-equivalent.
 -->
 ## Decisions Made
@@ -48,7 +48,7 @@ Non-RPA scope: rows collapse to scope + product-specific Level-1.5-equivalent.
 <!--
 EMIT THIS BLOCK ONLY when at least one [SME REVIEW] item remains after Step 1.5 resolution.
 Skip entirely when no review items are open.
-See sdd-generation-guide.md Phase 3 Step 3 for the format spec.
+See sdd-generation-guide.md Phase 3 Step 2 item 4 for the format spec.
 -->
 ## Action Required — SME Review Items
 
@@ -352,7 +352,7 @@ flowchart LR
 ```text
 <CASE_PROJECT_NAME>/
 ├── caseplan.json
-├── sdd.md                   (this file — input to planning)
+├── sdd.md                   (this file — uipath-maestro-case reads the literal name `sdd.md`; copy the generated SDD here under this exact name)
 ├── tasks.md                 (generated during planning)
 ├── registry-resolved.json   (audit trail)
 └── content/

package/skills/{uipath-solution → uipath-planner}/assets/templates/coded-app-sdd-template.md

@@ -23,7 +23,7 @@
 | **SDD scope** | <single-product \| solution> |
 | **Project list section** | §10 Project Structure + §9 Integrated Components |
 | **Tasks file** | `<APP_NAME_KEBAB>-tasks.md` |
-| **Generated by** | uipath-solution v<VERSION> |
+| **Generated by** | uipath-planner |
 | **Generation date** | <YYYY-MM-DD> |
 
 ---
@@ -31,7 +31,7 @@
 <!--
 EMIT THIS BLOCK ONLY when Execution autonomy: autonomous.
 Skip entirely in interactive mode (decisions were checkpoint-reviewed).
-See sdd-generation-guide.md Phase 3 Step 3a for the format spec.
+See sdd-generation-guide.md Phase 3 Step 2 item 3 for the format spec.
 Non-RPA scope: rows collapse to scope + product-specific Level-1.5-equivalent.
 -->
 ## Decisions Made
@@ -48,7 +48,7 @@ Non-RPA scope: rows collapse to scope + product-specific Level-1.5-equivalent.
 <!--
 EMIT THIS BLOCK ONLY when at least one [SME REVIEW] item remains after Step 1.5 resolution.
 Skip entirely when no review items are open.
-See sdd-generation-guide.md Phase 3 Step 3 for the format spec.
+See sdd-generation-guide.md Phase 3 Step 2 item 4 for the format spec.
 -->
 ## Action Required — SME Review Items