uipath-planner

name: uipath-planner 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 Planner — Design & Task Derivation

Two jobs, one entry point:

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.

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, then fall through into Lane A. See 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.
• 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.

When to Use This Skill

• 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 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 & 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: 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) — 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

Run this guard before anything else.

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. 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, ambiguous, or unparseable) — ask via AskUserQuestion:

   > What is the document at <path>?
   > 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.

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. 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: 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). 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.
3. Parse the SDD project list section. Pick the multi-skill pattern.
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.

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

Lane B — Non-PDD (summary)

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 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.
3. Step 3 — filesystem detection for single-skill plans.
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.

Full procedure: 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.

Reference Navigation

Phase D — Design

SDD templates

Lanes A & B — Planning

Anti-patterns

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.