/uipath-maestro-case

name: uipath-maestro-case
description: "Always invoke for UiPath Maestro Case Management build work: `caseplan.case` or `caseplan.json` (Studio Web also: `case.stage.json`, `default.stage.json`), `sdd.md`, or building/creating a case when no SDD exists yet (the case design is produced first, then confirmed in one review). Resolves tenant resources then authors or edits caseplan.case 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`. Resolve tenant resources into `tasks/registry-resolved.json`, then emit `caseplan.case` with `uip maestro case sdd convert` and fill what the document cannot determine, using the applicable per-plugin JSON recipes. The SDD is the plan — there is no intermediate plan file, and the converted `caseplan.case` is not one: it is the artifact itself, derived rather than restated.

> **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](references/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 <!--skill-flavor:design-handoff-next-step:start--> `uip solution init`, Phase 1, <!--skill-flavor:design-handoff-next-step:end--> 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.case`; see [references/brownfield.md](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.case` 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 12, 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 <!--skill-flavor:design-handoff-rule-next-step:start--> `uip solution init <SolutionName>` and Phase 1 <!--skill-flavor:design-handoff-rule-next-step:end--> without another prompt unless explicitly requested. A design-only request stops after `sdd.md` per Rule 3's design-only exception. 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 rather than rereading mid-phase — except at Rule 8's Phase 2 and Phase 3 entry checkpoints, which always re-read because context may have compacted. Use AskUserQuestion for build-phase ambiguity. Before reading an SDD not watched being written, Read its first 40 lines as the receipt: the `<!-- planner-handoff:v1 -->` marker and a `Template validation` header value of `passed` must both be present. Anything else goes back through the planner's template conformance checklist. 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, unless the user selects `Force pull and re-resolve` at Rule 18's empty-lookup gate, or `sdd resolve` reports a stale cache (below). 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 `tasks/registry-resolved.