uipath-maestro-case

name	uipath-maestro-case
description	Always invoke for UiPath Maestro Case Management build work: `caseplan.json`, `sdd.md`, or building/creating a case when no SDD exists yet (the case design is produced first, then confirmed in one review). Produces tasks.md and authors or edits caseplan.json directly with Write/Edit. For .xaml→uipath-rpa, .flow→uipath-maestro-flow, .bpmn→uipath-maestro-bpmn. For standalone case SDD design, case `sdd.draft.md` finalization, PDD→SDD, or cross-product planning→uipath-planner.
allowed-tools	Bash, Read, Write, Edit, Glob, Grep, AskUserQuestion, TodoWrite, Agent

UiPath Case Management Authoring Assistant

Build UiPath Case Management definitions from sdd.md. Generate tasks.md, then write caseplan.json directly using the applicable per-plugin JSON recipes.

Authoring invariant: Never use mutating uip maestro case commands (cases|stages|tasks|*-conditions ... add|update|remove, including tasks add-connector) or explore them with --help. Use the CLI only for scaffolding, metadata reads, validation/debug, runtime operations, and solution sync/upload. Consult case-commands.md only when exact syntax is needed. CLI availability or a final validate requirement never overrides this rule.

When sdd.md is absent, case design belongs exclusively to uipath-planner, which runs its Case Design Lane in this conversation. This skill never designs independently. The lane uses best-assumption design, Listen → Sketch → full design-time tenant resolution, a mandatory other-path sweep, and one decision-first eight-section Case Review. Its Build answer is consent; it writes template-conformant sdd.md, then this skill continues immediately with uip solution init, Phase 1, and later phases. The same handoff applies to sdd.draft.md finalization. Never overwrite an existing sdd.md.

Scope: greenfield builds from sdd.md and brownfield targeted edits to an existing caseplan.json; see references/brownfield.md. For Studio Web cases, pull current server state first with uip solution download or solution projects resync so publishing cannot clobber server changes.

When to Use This Skill

Use for:

• Building a Case Management project from sdd.md.
• Creating a case when no SDD exists; hand design to uipath-planner in this conversation.
• Generating implementation tasks from an SDD.
• Editing an existing caseplan.json by targeted intent: stage/task changes, conditions, or triggers.
• Questions about case JSON schema, nodes, transitions, tasks, rules, SLA, or runtime case instances.

Do not use for .xaml → uipath-rpa, .flow → uipath-maestro-flow, or standalone agents/APIs/processes outside case context.

Critical Rules

1. Design handoff and SDD authority. If sdd.md is absent, immediately invoke uipath-planner’s Case Design Lane in this conversation, before reading references or running tenant commands. Do not improvise interviews, design subagents, generic Build Plan approvals, or design-only behavior here. The lane’s single Case Review has exactly these sections: Case Snapshot; Primary Journey; Other Paths Considered; SLA and Escalations; Rules and Outcomes; Resources and Integrations with design-time resolutions; Decisions I Made; Review Flags. It names every stage/task, type, activation/grouping, required status, routing/outcome, and SLA context; sdd.md separately contains the complete data contract, variables, and task inputs/outputs. The Build options incorporate Rule 11, and the Build answer is the sole consent. Corrections re-show only changed review sections. Before approval, every selected-tasks-completed selector must resolve to a non-adhoc sibling in the same stage. The lane writes sdd.md early, then this skill runs uip solution init <SolutionName> and Phase 1 without another prompt unless explicitly requested. If the request asks only for sdd.md plus tasks/tasks.md, write compact tasks/tasks.md after Save/Build, do not read plugin references or run tenant discovery, and stop before caseplan.json. If sdd.draft.md is to be finalized, use the lane fast path with target basename sdd.md. Never overwrite sdd.md.

2. SDD is the sole post-design input, across sessions. Trust user-provided or previously written sdd.md; do not validate, gap-fill, or silently infer it. In the same conversation as design approval, use the in-memory model that wrote it without rereading. Use AskUserQuestion for build-phase ambiguity. Run a one-Grep receipt spot-check before reading an SDD not watched being written: it must contain ## Section 1: Case Definition through ## Section 4: Integrations and at least one ##### Task block. Freeform/summary SDDs go back through the planner template-conformance gate.

3. Phase 1 registry gate. Run uip login status --output json, then uip maestro case registry pull, before cache inspection, carryover, resolution, or Phase 1 writes. Pull at most once per session. If the planner lane ran in this session, its pull succeeded, and it wrote the SDD, reuse the cache. With the lane’s in-context resolution outcomes, use verify-only planning: persist them verbatim to , spot-check cache entries, execute gate decisions, and re-resolve only stale/missing entries. Otherwise run the full gate. Login/pull failure stops Phase 1. Read directly; has known gaps, especially action-apps. Before a successful pull, missing cache files are failed refresh preconditions, never zero matches; only after success may empty exact-name matches or absent indexes enter empty-lookup handling. Trust the SDD; the pull refreshes discovery only. The planner lane owns design-time resolution, lazily starting login/pull when tenant-bound work first appears, resolving identities with one batched Case Review gate, and recording SDD cells plus its resolution ledger. No schema discovery occurs there.

Routing

Condition	Journey
New case, SDD provided, no caseplan, or rebuild from spec	Greenfield: handoff if needed, then Phases 1–7
Existing caseplan and targeted edit intent	Brownfield: skip handoff and Phases 1–7; use brownfield.md

Brownfield still requires latest-state pull, debug consent, and Orchestrator-publish consent, and reuses Phase 5–7 contracts.

User-Facing Roadmap

Print once, after routing and before detailed work, in five lines or fewer. Do not expose phases, modes, filenames, or implementation mechanics.

• New case without SDD: 1. I read your request and make the design calls, checking your UiPath tenant along the way. 2. One review packet: case snapshot, primary journey, other paths, SLA responses, business rules, resources, and every decision I made — you confirm or correct. 3. Build and validate without interruptions; the full technical design doc is saved alongside for reference. 4. Pause for your call before any run or publish.
• New case with SDD: 1. Read the design and verify available UiPath resources. 2. One question: build straight through, or pause at a mid-build preview. 3. Plan, build, and validate without further interruptions. 4. Pause for your call before any run or publish.
• Targeted edit: 1. Pull the latest case. 2. Apply the requested change. 3. Validate the updated case. 4. Ask before running or publishing anything.

Workflow

Front-load decisions, then run unattended to consent gates:

Design handoff when required → Phase 1 Planning → Phase 2 Prototyping → Phase 3 Implementation → Phase 4 Validate → Phase 5 Publish → Phase 6 Debug → Phase 7 Publish to Orchestrator.

At invocation start, present once the matching kickoff block below, at handoff start or Phase 1 start. Status text must follow the Anti-patterns limits.

Greenfield kickoff:

Here's how I'll build this case, and where I'll stop for your call:

• Planning — I draft a task plan from the spec and continue; ask up front if you want to review it first.
• Prototyping — I build the reviewable case flow (stages, tasks, triggers, rules, SLA/escalation; connector rules use stubs). Whether I pause here for a Studio Web preview is your up-front call — asked once at the start, never mid-build.
• Implementation — I wire task inputs/outputs, connector schemas, and resolved connector-rule details.
• Validate — I run validation and fix errors.
• Publish (optional) — you choose whether to upload to Studio Web.
• Debug (optional) — you choose whether to run the case for real (live emails / API calls).
• Publish to Orchestrator (optional) — you choose whether to publish the case to Orchestrator.

For handoff, prefix: First I'll design the case from what you've given me — checking your UiPath tenant along the way — and show one decision-first review packet with the case snapshot, primary journey, other paths, SLA responses, business rules, resources, and every decision made — one confirmation, then I build; the full technical design doc (sdd.md) is saved alongside for reference.

For brownfield, use the short entry flow in references/brownfield.md.

Design handoff

The trigger is binary: if no .md whose basename contains sdd exists at the resolved path, hand off. If the prompt names another SDD basename, copy it to ./sdd.md using Read + Write; do not invoke the lane. If no .md is named, use ./sdd.md. Do not read planning/plugin references or run tenant commands before the Case Review. For an explicit no-build design+plan request, write sdd.md and compact tasks/tasks.md after approval, without plugin references, schema, registry, connection, or user discovery, then stop. Planner-owned drafts and sdd-viewer.html stay with the planner. If unavailable, request an SDD and stop.

Phase 1 — Planning

Read references/planning.md to produce:

• tasks/tasks.md: T-numbered stages, tasks, conditions, SLA, variables, and arguments.
• tasks/registry-resolved.json: complete resolution audit.
• If Create is selected at Rule 17: build selected agents/API workflows as in-solution siblings through the permitted sub-agent paths, ensure a solution exists, register them, refresh resources, rediscover, and bind them. See registry-discovery.md § Create-on-Missing.

tasks/ is adjacent to sdd.md, never inside the solution/project. Auto-proceed to Phase 2 unless the request explicitly asks to stop for plan review. Re-read tasks.md first.

Phase 2 — Prototyping

Read references/implementation.md and references/phased-execution.md. Follow Steps 6–11.9:

1. Step 6: uip solution init, project, and root case (T01 direct-JSON recipe in plugins/case/impl-json.md); never case init.
2. Step 6.1: manual, timer, and event triggers, including Rule 8 placeholders; capture trigger IDs.
3. Step 6.2: global variables and arguments; In-argument elementId references the trigger named by sourceTriggers, or the primary trigger when blank.
4. Step 6.3: synchronize entry-points.json from declared In/Out arguments per entry-points-sync.md. Emit the job-attachment definitions block byte-for-byte from that reference — reproduce its MimeType.description inner quotes exactly (single-\" escaping); never re-escape (\\") or rebalance them, or the JSON breaks.
5. Step 7: stages.
6. Step 9: task shapes; non-connectors get complete data.inputs[] with empty values, connectors only typeId/connectionId, unresolved resources use placeholders.
7. Step 11: SLA/escalation objects with stable IDs.
8. Step 10: all four condition scopes; connector waits use canonical stubs regardless of resolution.
9. Step 11.9: informational skeleton validation with Rule 11 fallback behavior.
10. Apply the Phase 2→3 preference. Preview branch uses resource refresh, filtered solution upload, printed DesignerUrl, and the prescribed continuation gate; Abort writes build-issues.md and exits.

Phase 3 — Implementation

Re-read tasks.md and caseplan.json (Step 9.6), then follow Steps 9.7, 9.8, 10.5, and 11.5:

1. Resolve connector schemas/defaults with uip maestro case spec.
2. Bind I/O for all task classes using io-binding/impl-json.md.
3. Upgrade resolved connector-bound condition stubs in place; unresolved connectors retain stubs and are reported.
4. Resolve in-expression vars.$xref markers.
5. Perform resolved-resource emission, preservation, resourceKey, and connector completeness checks.

Proceed directly to Phase 4 after the Phase 3 checks pass.

Phase 4 — Validate

Run Step 12 once at the Phase 3 boundary. It performs Checks 1–15, including Check 7 sidecar parity, Check 8 global output-ID uniqueness, Check 9 resource emission/preservation, Check 10 formal-arg IDs, Check 11 resourceKey consistency, Check 12 connector completeness, and Check 15 every task carrying a non-empty entry rule (validate only warns on a missing one). Then run full uip maestro case validate. Retry at most three times, with an edit before every retry; on the third failure, hard-stop with AskUserQuestion: Retry with fix / Pause for manual edit / Abort. Summarize build-issues.md using Step 12.1.

Phase 5 — Publish

Provide the completion report, then hard-stop AskUserQuestion: Publish to Studio Web / Skip to Debug (Step 13). On publish, refresh resources and upload with the mandatory output filter, print DesignerUrl, and continue to Phase 6 either way.

Phase 6 — Debug

Hard-stop AskUserQuestion (Step 15): Run debug session / Continue to publish. On Run, refresh resources, run uip maestro case debug, and loop after completion until Continue to publish. Never run debug automatically.

Phase 7 — Publish to Orchestrator

Hard-stop AskUserQuestion (Step 16): Publish to Orchestrator / Done. On publish, run in order:

1. uip solution resources refresh
2. uip maestro case pack <SolutionDir>/<ProjectName> <SolutionDir>/dist --output json
3. uip solution pack <SolutionDir> <SolutionDir>/dist --output json
4. uip solution publish <packagePath> --wait --output json

case pack is mandatory because it creates caseplan.json.bpmn; validate does not. Publish the solution pack .zip, not the case .nupkg; read <packagePath> from Data.Packages, never guess. Done exits.

Reference Navigation

Need	Reference
Design without SDD	uipath-planner Case Design Lane; Rule 15
Plan from SDD	references/planning.md
Execute plan	references/implementation.md
Brownfield edit	references/brownfield.md
Phase contracts	references/phased-execution.md
Edit mechanics	references/case-editing-operations.md
Schema	references/case-schema.md
Allowed CLI	references/case-commands.md
Troubleshooting	references/troubleshooting-guide.md
Registry resolution	references/registry-discovery.md
Bindings/expressions	references/bindings-and-expressions.md
Connector integration	references/connector-integration.md
Case spec input details	references/case-spec-input-details.md
Placeholders	references/placeholder-tasks.md

Plugin Index

Structural: case/planning.md, stages/planning.md, sla/planning.md, global-vars/planning.md, io-binding/planning.md, and logging/impl-json.md.

Tasks:

Schema type / SDD value	Plugin planning reference	CLI describe type
process	process	process
agent	agent	agent
rpa	rpa	rpa
action	action	action
api-workflow	api-workflow	api-workflow
case-management	case-management	case-management
execute-connector-activity	connector-activity	connector-activity
wait-for-connector	connector-trigger	connector-trigger
wait-for-timer	wait-for-timer	wait-for-timer

Schema-kebab is the only JSON value; plugin and CLI names are not interchangeable. Unsupported types include external-agent, external-workflow, document-extraction, flow-process, and wait-for-event.

Triggers: manual, timer, and event.

Conditions: stage-entry-conditions, stage-exit-conditions, task-entry-conditions, and case-exit-conditions.

Connector-bound rules in any condition scope require rule.uipath built from case spec --type trigger; bare connector rules are invalid in Studio Web even when CLI validate passes. See connector-trigger-impl.md.

Anti-patterns

• Do not leave a regular stage without an entry condition. The first stage uses case-entered; every other regular stage needs a reachable predecessor. Edges are retired.
• Do not design here, start Phase 1 before Case Review approval, or build from a summary SDD. The planner owns design, other-path analysis, and template conformance.
• Do not validate after each T-entry or validate twice without an intervening edit. Phase 2 validation is informational; Phase 4 validation is authoritative.
• Write tasks.md with a seeded header and per-section batched Edit-appends: §4.2.1 variables, §4.3 triggers, §4.4 stages, §4.6 tasks, §4.7 conditions, and §4.8 SLA. Never write per T-entry, use a mega-Write, or exceed a 30KB single Edit payload. Recovery re-reads and resumes at the next unapplied entry. See planning.md §4.0a.
• Write caseplan.json by section, preserving untouched siblings — never one Write for the whole file. Read once at section entry; use per-entry Edits for fewer than 10 entries, or one Write covering only that section's container (the stages array, or one stage's task array) for 10 or more; gather CLI-gated sections before writing. Cap any single Write at ~15K output tokens / ~40KB; split a case with ≥40 tasks or ≥8 stages across the Phase 2 and Phase 3 writes rather than emitting the fully populated file at once. Re-read both files after interruption. See case-editing-operations.md § Per-section batch write contract.
• Do not emit standalone narration between tool calls. Bundle status with the next tool call; keep ordinary text under 200 tokens and allow-listed kickoff, hard-stop preambles, completion reports, DesignerUrl prints, and validation summaries under 500. Do not announce imminent actions with verbs such as Building, Composing, Writing, Drafting, Generating, Now I'll, Next, Approach, Strategy, Plan, Let me, or equivalent.
• Preserve ordered task semantics. Sequential mode uses ordered data.tasks sets and one runs-sequentially rule per task; do not add current-stage-entered alongside it. Use parallel current-stage-entered only for independent work and selected-tasks-completed only for required fan-in. Event-triggered tasks use event/condition rules; manually triggered/adhoc tasks use one rule, , and no additional entry event. is an activation mode, not a task type.

Trouble? Use /uipath-feedback to send a report.