uipath-ixp

name: uipath-ixp description: "UiPath IXP (Document Understanding) — review IXP predictions with Claude, confirm valid fields, improve prompts, publish models."

UiPath IXP Document Extraction Assistant

Skill for working with UiPath IXP (Intelligent eXtraction Platform) projects — creating projects, uploading documents, reviewing predictions, and improving extraction quality.

When to Use This Skill

• User asks to create an IXP project, upload documents, or train a document extraction model
• User asks to label, review, or confirm document predictions
• User asks to improve extraction scores, prompts, or field instructions
• User asks to publish or manage IXP model versions
• User provides a taxonomy file to import into a project
• User asks for the project taxonomy at a specific trained model version — what the schema looked like when version N was published (use deployments get-taxonomy <project-name> --version <N>)

When NOT to Use This Skill — defer to uipath-maestro-flow

This skill covers standalone IXP-project work. STOP and invoke the uipath-maestro-flow skill instead when any of these hold:

• The user asks which IxP / document-extraction models, extractors, or nodes are available to a .flow or Maestro flow (a registry-listing question, not IXP-project management).
• The request is about adding, wiring, or referencing an IxP node inside a flow.
• The working context is a .flow file or a Maestro flow rather than a standalone IXP project.

Do not answer these from this skill. Re-activate uipath-maestro-flow and follow the commands it documents. This overrides Critical Rule 1.

Critical Rules

1. ONLY use uip ixp CLI commands as documented in this skill — do NOT use curl, do NOT call REST APIs directly, do NOT grep/read source code, do NOT explore the codebase. (Exception: defer flow/Maestro registry questions to uipath-maestro-flow — see When NOT to Use This Skill above.)
2. Run workflows end-to-end automatically — do NOT ask the user to do individual steps.
3. Always use --output json when parsing CLI output programmatically.
4. Use /tmp/ixp/<project-name>/ as the working directory with this structure:

   /tmp/ixp/<project-name>/
   ├── docs/         # Document files (<document-id>.pdf, .png, …) — downloaded once, reused across sessions
   ├── taxonomies/   # Taxonomy snapshots (v1.json, v2.json, …) — new version after each update-prompts
   └── prompts/      # Instruction update payloads (field_updates.json, group_updates.json, …)
   

   At the start of any workflow: mkdir -p /tmp/ixp/<project-name>/{docs,taxonomies,prompts}. If the directory already exists from a previous session, reuse existing files — do not re-download documents that are already present. Do NOT use the Write tool for /tmp/ixp/ paths — on Windows it resolves to a different location than bash.
5. Use heredocs for --updates — for fields update-prompts --updates and groups update-prompts --updates, use heredocs (cat > /tmp/ixp/<project-name>/prompts/field_updates.json << 'EOF' ... EOF) then "$(cat /tmp/ixp/<project-name>/prompts/field_updates.json)".
6. Never use UID as a variable name — it is a readonly shell variable. Use DOC_ID, DOCUMENT_ID, etc.
7. Always use the project Name, never the Title — the project list output has both Name (e.g., my_invoices-f1afa9ef-ixp) and Title (e.g., My_Invoices). All CLI commands require the Name (the lowercase slug with UUID and -ixp suffix), NOT the Title.
8. Confirm at field level, not document level — review each predicted field individually. Confirm only the fields that are correct using labelling confirm --fields. Fields with wrong predictions are left unannotated. --corrections is ONLY for OCR-mangled values — the prediction found the right field in the right location and the bytes-on-page are right, but the text was garbled (e.g., MSIÓÓÓ601020/ → MSI0601020). Do NOT use --corrections to flip a wrong boolean, fix a wrong inferred/computed value, or change any value where the prediction itself was the wrong answer — those are NOT CONFIRMED. Overriding a non-OCR prediction is manual extraction (forbidden by rule 11).
9. Do NOT manually extract values — all labelling goes through labelling confirm with predictions from IXP.
10. Max 8 documents for taxonomy suggestion — the suggest-taxonomy endpoint accepts at most 8 attachment references.
11. Claude is the reviewer, not the extractor — IXP generates predictions, Claude validates them. For each document, review predicted field values against the document file (Read tool handles PDF, PNG, JPG, etc.). Confirm correct fields (labelling confirm --fields), correct OCR-mangled values (--corrections), and skip wrong fields. Do NOT manually extract values. If a field's F1 is low, improve the prompt so IXP predicts better values.
12. Confirm a field as missing by listing it in confirm --fields, only when IXP also predicted nothing — labellings confirm --fields f1,f2,f3 treats every listed field uniformly: if IXP predicted a value, it's confirmed; if IXP predicted nothing for a listed field, a missing marker is written. The explicit listing IS the confirmation that the empty state is intentional. Only include a field in --fields for the missing case when IXP itself predicted no value (or an empty value) AND the field is genuinely absent from the document. If IXP predicted a wrong value, leave the field NOT CONFIRMED (omit it from --fields) — choosing "missing" yourself is the same kind of extractor decision rule 11 forbids. Use labellings mark-missing only as a fallback when confirm --fields is a no-op for a field you expected it to handle — this happens when the field has a prior annotation but doesn't appear in the current get-predictions output for that document (e.g., model behavior or the taxonomy changed between iterations). In that case, mark-missing reaches the stale annotation and overwrites it with a missing marker; confirm can't.

Quick Start

1. Run uip ixp projects list --output json to see existing projects
2. To create a new project: follow Project Setup Guide
3. To improve an existing project: follow Improve Prompts Guide
4. To label documents on an existing project: follow Label Documents Guide

If the user provides a taxonomy file, use --skip-taxonomy and import-taxonomy (Option B in the Project Setup guide).

Task Navigation

Common Pitfalls

Unsupported Capabilities

These requests fall outside the skill. Recognise the request, reply with the standard response, route the user. Do NOT enter discovery (uip --help, grep, source reading) — see Critical Rule #1.

Reference Navigation

• CLI Commands Reference — all uip ixp commands with options and output formats
• Project Setup Guide — create a new project, review and label documents
• Improve Prompts Guide — iterative optimization loop with regression detection
• Label Documents Guide — reusable workflow for reviewing and confirming predictions