{ "skill_name": "case-management", "evals": [ { "id": 1, "prompt": "I have an sdd.md and spec.json for a loan approval case. Generate the implementation tasks from these spec files so I can build it.", "expected_output": "Skill triggers, resolves resources into tasks/registry-resolved.json covering the SDD's stages, tasks, and conditions, then stops before Phase 2 because the request is plan-only", "expectations": [ "The case-management skill was triggered", "References uip maestro case registry pull for upfront caching", "Produces a tasks/registry-resolved.json ledger with one entry per resolvable SDD resource", "Includes registry lookups to resolve taskTypeIds", "Generates a registry-resolved.json for audit", "Stops after resolution without creating a solution or caseplan because the request asks only for implementation tasks" ] }, { "id": 2, "prompt": "Break down my case spec into implementation tasks. The spec files are at ./specs/sdd.md and ./specs/spec.json", "expected_output": "Skill triggers, reads both spec files, resolves registry lookups into tasks/registry-resolved.json, and stops before Phase 2 because the request is plan-only", "expectations": [ "The case-management skill was triggered", "Reads both sdd.md and spec.json from the provided paths", "Uses the component_type mapping to determine registry search types", "Produces a tasks/ folder with registry-resolved.json", "Stops after resolution without creating a solution or caseplan because the request asks only for an implementation-task breakdown" ] }, { "id": 3, "prompt": "Convert this case specification into a step-by-step plan and build the case", "expected_output": "Skill triggers, resolves resources, then auto-proceeds to write caseplan.json directly from the SDD via the matching plugins without a Phase 1 approval prompt", "expectations": [ "The case-management skill was triggered", "Produces tasks/registry-resolved.json with one entry per resolved resource", "Cross-references use human-readable format like Stage.Task.field", "Auto-proceeds from resolution into the build without asking for Phase 1 approval", "Writes caseplan.json directly via plugin impl-json.md recipes" ] }, { "id": 4, "prompt": "I want to create a case management project", "expected_output": "Skill triggers, shows the new-case roadmap, and hands the design to the uipath-planner Case Design Lane in the same conversation — no entry menu, no interview run by this skill", "expectations": [ "The case-management skill was triggered", "Shows the journey-specific roadmap with the design prefix line before design work begins — user-facing language never mentions the handoff or skill mechanics", "Does not offer an entry menu or ask for an sdd.md path before the user names one", "Does not run a per-dimension interview of its own; the design comes back as one decision-first Case Review for the single confirmation" ] }, { "id": 5, "prompt": "Add a stage called 'Document Review' to my case.stage.json file", "expected_output": "Should NOT trigger case-management planning workflow -- this is a direct stage edit on an existing case file", "expectations": [ "The case-management skill may be triggered for direct editing", "Does NOT go through the sdd.md planning workflow" ] }, { "id": 6, "prompt": "Build my case from ./sdd.md", "expected_output": "Skill triggers, emits caseplan.json with the top-level shape (id: case-<10>, version: 27.0.0, metadata, top-level bindings/variables, layout: {}), runs Phase 4 validate authoritatively", "expectations": [ "The case-management skill was triggered", "caseplan.json top-level keys are: id, version, name, metadata, bindings, variables, nodes, edges, layout", "caseplan.json.version === '27.0.0'", "caseplan.json.id matches /^case-[A-Za-z0-9]{10}$/", "No 'root' wrapper key in caseplan.json", "metadata.caseExitRules is used once case-exit conditions are written", "metadata.slaRules is used for root-target SLA", "Top-level bindings and variables (not nested under any wrapper)", "Stage and Trigger nodes have NO position, style, measured, width, height, zIndex (Rule 18)", "Top-level layout: {} present and empty", "Phase 4 validate runs authoritatively — 3-retry cap and hard stop on 3rd failure" ] }, { "id": 7, "prompt": "I want to create a new case but I do not have an sdd.md yet", "expected_output": "Skill hands the design to the planner lane (planner-authored, best assumption) and confirms it in ONE decision-first Case Review that is complete enough to approve without opening sdd.md", "expectations": [ "The case-management skill was triggered", "Shows the high-level journey first: designs the case from the request with tenant checks along the way, one review packet with every decision for confirmation, then build and validate without interruptions, pausing only before any run or publish", "Does not expose internal Phase 0 through Phase 7 labels, the handoff, or skill mechanics in user-facing output", "Asks the Listen opener once (bare request only), then fills every open field by best assumption — no per-dimension question walk about trigger, task types, exits, or SLAs; open fields are disclosed as decisions", "Presents ONE Case Review with the required sections: Case Snapshot, Primary Journey, Other Paths Considered, SLA and Escalations, Rules and Outcomes, Resources and Integrations, Decisions I Made, Review Flags, and Caller obligation when relevant", "The Case Review names every stage and every task in the Primary Journey or Other Paths tables, with task type, activation mode, required/optional status, routing/exit behavior, and SLA context", "The approval surface omits the data contract, variables, task inputs, task outputs, and duplicated stage/task detail cards; those technical details remain in sdd.md", "SLA and Escalations has one row per meaningful scope, SLA, and status combination, including the target or condition, response, response target, interrupting behavior, and rationale", "The confirmation includes a complete Decisions I Made table with a plain-language provenance per assumption", "A manually triggered task is presented as optional adhoc worker-launched work without exposing schema mechanics", "The confirmation carries the build continuation choice (build straight through vs pause at the build preview) so it is never asked mid-build", "On a Build answer the lane writes sdd.md, then the build starts (solution init + planning); the design doc is mentioned in one line as a reference artifact — never presented for review, and never written before the Build answer" ] }, { "id": 8, "prompt": "Create a vendor onboarding case. I attached two process documents. It uses VendorRiskAgent, Salesforce Prod, and a Slack notification connector.", "expected_output": "Design-time grounding runs inside the planner lane — the login and registry chain fires in the background at lane entry on a build handoff, identities resolve at design time — and the build's planning pass runs verify-only from the in-context resolution ledger", "expectations": [ "Never blocks on the tenant — on a build handoff the login and registry chain fires in the background at lane entry (batched with the document reads) and resolution lands before the Case Review", "Reads all supplied documents in parallel while the chain resolves", "Runs registry pull only after login succeeds and does not treat a failed pull as zero matches", "Identity resolution completes at design time: one batched cache-lookup pass, no tasks describe, no case spec, no schema discovery before the build phases", "If the pull has not finished when the review is ready, presents anyway with resolve-at-build on tenant-bound items — the confirmation is never delayed by the tenant", "A single confident match is adopted silently and shown as a decision; multiple matches, cross-folder names, missing connections, and empty lookups surface in the review as gate items — user-answered gate decisions are never re-asked at build, while defaulted resolve-at-build items (no session, pending pull) stay open for the build's gate", "Does not let tenant inventory add or rename business stages or tasks", "On the Build answer, Phase 1 reuses this session's successful pull instead of re-pulling and runs verify-only from the in-context resolution ledger; user-answered gate decisions execute without re-asking (Rule 17 short-circuit), defaulted deferrals go through the Rule 17 gate" ] }, { "id": 9, "prompt": "Interview me, confirm your understanding, and generate the SDD only after I approve it", "expected_output": "A design-only request with explicit sign-off belongs to the planner end-to-end — the skill says so and routes the user to uipath-planner instead of improvising an interview", "expectations": [ "Recognizes a design-only request (the deliverable is an approved SDD, not a build)", "Suggests invoking uipath-planner for the interview and SDD authoring in text — this skill builds only", "Does not improvise its own interview and does not fabricate an SDD", "If the user later provides the approved sdd.md, this skill consumes it trust-as-written and builds" ] }, { "id": 10, "prompt": "Build me a complete employee-offboarding case end to end. I trust the design process — I don't need to review anything until it's ready to run.", "expected_output": "Skill delegates the design, confirms once (capturing the straight-through choice), then builds Phase 1 through Phase 4 automatically, pausing next at the debug gate", "expectations": [ "The single Case Review carries the build continuation choice: build straight through vs pause at the build preview", "The Case Review is complete enough to approve without opening sdd.md: it includes Case Snapshot, Primary Journey, Other Paths Considered, SLA and Escalations, Rules and Outcomes, Resources and Integrations, Decisions I Made, and Review Flags while keeping data and variable details in sdd.md", "The confirmation's Decisions I Made table discloses every assumption with plain-language provenance", "sdd.md is already written by the delegated design; on the Build answer the transition line is announced and the build starts with solution init and planning — the design doc path is reported in one line as a reference artifact", "No blocking prompt between the confirmation and Phase 4 validation on the straight-through path — the Phase 2 boundary prints the skeleton counts line and continues", "Phase 1 reads the delegated sdd.md once, reuses this session's successful registry pull instead of re-pulling, and runs verify-only from the returned resolution ledger", "Posts an expectation-setting line before long silent work and one-line business-language milestones during the build — no internal phase or mode names", "Still stops at the debug-consent gate and the publish gate — those are never bypassed", "If any high review item exists, the Build option is relabeled build-despite with the count" ] }, { "id": 11, "prompt": "Create a claims-intake case for me. (Tenant login is currently broken in this environment.)", "expected_output": "Skill tells the user immediately, in one plain line, that tenant resources are unreachable, continues the design with intended names, and leaves identities unresolved for the build to wire later", "expectations": [ "Says tenant resources are unreachable in one business-language line as soon as the login or refresh fails — not first revealed by resolve-at-build rows in the Case Review", "The design continues without blocking on tenant discovery", "Keeps concrete intended resource names and marks only identity/folder fields unresolved with paired review items", "Does not surface internal filenames, cache paths, or CLI mechanics in the notice" ] }, { "id": 12, "prompt": "Build a case from this requirements document: ./claim-settlement-requirements.md (a complete spec: 5 phases with per-phase SLA targets, 3 wrap-up outcomes, a 4-way adjuster decision, amount-tiered sign-off, anytime actions).", "expected_output": "Skill digests the doc through the delegated design, presents ONE decision-first Case Review with tables and a decisions block, and on the Build answer moves straight into the build", "expectations": [ "Skips the entry menu — the request already describes the case, and the document path travels verbatim into the design", "Everything the doc covers is decided by assumption, not re-confirmed; genuine contradictions surface as flagged decisions in the review", "The Case Review includes Case Snapshot, Primary Journey, Other Paths Considered, SLA and Escalations, Rules and Outcomes, Resources and Integrations, Review Flags, and a complete Decisions I Made table with plain-language provenance", "The five phase SLA targets and their at-risk or breach responses appear as separate rows in SLA and Escalations, not mixed into task cards or variable details", "The confirmation options carry the build continuation choice", "On the Build answer: no re-summary — transition line, then solution init and planning start; sdd.md is already on disk from the delegated design, reported in one artifact line", "The confirmation question anchors to the Case Review tables" ] }, { "id": 13, "prompt": "Design a claims intake case with me — I want to see the case take shape as we go", "expected_output": "A standalone conversational design request belongs to the planner — the skill routes the user to uipath-planner, which owns interactive case design; the build returns here once an sdd.md exists", "expectations": [ "Recognizes a standalone conversational design request and suggests uipath-planner in text — it does not improvise its own interview", "Does not write design artifacts before an sdd.md exists", "If the user proceeds to a build with the resulting sdd.md, this skill consumes it trust-as-written" ] }, { "id": 14, "prompt": "Design a supplier application case. Withdrawal can arrive from the supplier portal at any point. Each phase warns handlers at 70% of its SLA and, on breach, interrupts into an escalation lane that creates an operations-lead task and sends the supplier a delay note. The case has a 15-day SLA whose breach interrupts into a director-review lane before closure. In Supplier Setup, verify identity, then set the supplier record, then invite the supplier. Preserve why every stage kind, task type, activation/sequence, SLA, and routing choice was made in the SDD and implementation plan.", "expected_output": "Skill models global withdrawal/SLA events as interrupting secondary-stage entries, preserves explicit sequential work with runs-sequentially, and carries durable design rationale into caseplan.json", "expectations": [ "Withdrawal is one interrupting secondary stage entered by the supplier-portal wait-for-connector event; the skill does not repeat withdrawal tasks or exits on every primary stage", "The 70% at-risk warning is an SLA escalation notification; phase/case breach work uses sla-status-change entry rules on interrupting secondary stages that reference the intended SLA rules (a breach references the SLA alone; only an at-risk rule also names an escalation)", "The explicitly ordered Supplier Setup tasks each use runs-sequentially, are not emitted as parallel current-stage-entered tasks, and are laid out as consecutive single-task data.tasks sets rather than one parallel inner array", "The SDD stores design rationale for stage kind/routing, task type/activation/sequencing, and SLA behavior instead of leaving the reasons only in chat", "caseplan.json preserves the SDD rationale on the matching stage, task, condition, and SLA elements" ] } ] }