UiPath Feedback

Send structured bug reports or improvement suggestions to UiPath with auto-captured troubleshooting via uip feedback send.

Design principle: minimum friction. The agent already knows what went wrong from the conversation. Don’t re-ask what you already know. The only mandatory interaction is confirmation before sending.

Critical Rules

1. Minimum user interaction. If the conversation already contains enough context (error, what the user was doing, what went wrong), go straight to confirm and send. Only ask clarifying questions when you genuinely cannot determine what happened.
2. Never send without explicit user confirmation. Always show a preview and wait for “yes”.
3. Never include secrets, tokens, credentials, or customer data. Sanitize all captured content before sending.
4. Never include full conversation history. Summarize relevant context in 2-3 sentences. Sample prompts (Step 2e) are a curated max-5 selection — not a transcript.
5. Use --output json on uip feedback send to parse the result programmatically.
6. If uip feedback send fails, save the report to ./feedback-report.md so the user does not lose the gathered context.

Workflow

Step 1 – Check prerequisites

uip --version 2>&1

Step 2 – Introspect and capture (silent – no user interaction)

Gather all context automatically. Run these substeps silently.

2a. Detect skill context

Check the current working directory. Stop at first match:

If ambiguous, infer from the conversation. Do NOT ask the user – pick the best match.

2b. Capture environment

uip --version 2>&1
uip login status --output json 2>&1
uip tools list 2>&1

From login status, extract only: tenantName, organizationName, baseUrl. Strip everything else.

From tools list, extract tool name and version from each row.

2c. Capture skill-specific troubleshooting

2d. Capture the failing command

Review the current conversation for the last CLI command that failed. If identifiable, capture:

• The full command
• Its stderr/stdout output (truncated to 100 lines)

If not identifiable, skip this section.

2e. Capture sample prompts

Pick 3-5 user prompts from the conversation that show what the user was trying to do. These give triagers what the retrospective cannot: the user’s actual words.

Selection rules:

• Prefer prompts stating intent (“build a flow that…”, “I need to…”, “help me…”) or describing failure (“this is broken”, “wrong result”).
• Keep wording verbatim. Paraphrasing loses signal. Sanitization Rules apply.
• Skip filler (“ok”, “thanks”, “try again”).
• If fewer than 3 substantive prompts exist, include what you have. Do not pad.
• Maximum 5 prompts. Total length under 1000 characters across all prompts. Truncate any single prompt over 200 chars with ... [truncated]; keep the most informative portion.
• If no substantive prompts are available, omit the ## Sample prompts section in Step 3 entirely.

2f. Session retrospective

Review the full conversation and produce a structured self-assessment. This is the most valuable part of the feedback – it gives triagers context no manual bug report can provide.

Answer each question concisely (1-3 sentences each). Reference actual tool names, errors, commands, and files from this session.

1. Intent: What was the user trying to build/edit/fix? Was the goal clear from the start?
2. Outcome: What was delivered vs. requested? Full / Partial / Failed.
3. Tool & Skill Gaps: Which tools or CLI commands were called but unhelpful? Which should have been called but weren’t? Any failures or workarounds?
4. Friction: Where did the agent get stuck, retry, or misunderstand UiPath conventions? How many generate-validate-fix cycles?
5. Top 3 Improvements: What skill/tool changes would have had the biggest impact on this session?

2g. Auto-detect type and priority

Type – determine from conversation signals:

Default to bug when ambiguous.

Priority – determine from conversation signals:

Default to normal when ambiguous.

2h. Sanitize everything

Apply all rules from the Sanitization Rules section below to every piece of captured content before proceeding.

2i. Only if context is insufficient

If the agent genuinely cannot determine what happened (e.g., user typed /uipath-feedback with no prior context in the conversation), ask one structured question:

I’ll send feedback to UiPath. Please tell me:

1. What were you trying to do?
2. What happened?
3. Is this a bug or an improvement suggestion?

Otherwise, skip directly to Step 3.

Step 3 – Build and confirm (only user interaction)

Title format

[Product] short description

Product names:

Description body

Build the --description content:

## What happened
{User's problem -- in their own words or summarized from conversation}

## Sample prompts
1. "{prompt 1 -- verbatim, sanitized}"
2. "{prompt 2 -- verbatim, sanitized}"
3. "{prompt 3 -- verbatim, sanitized}"

## Error
{The actual error message or validation output -- if available, otherwise omit this section}

## Environment
- Skill context: {detected skill name}
- uip version: {version}
- CLI tools: {name version, name version, ...}
- OS: {os info}
- Tenant: {tenant} ({org})

## Troubleshooting
- Project type: {detected type}
- Key files: {list of relevant project files found}
- Last failed command: {command + truncated output}

## Session retrospective
- **Intent**: {what the user was trying to do}
- **Outcome**: {Full | Partial | Failed -- what was delivered vs requested}
- **Tool & Skill Gaps**: {tools/commands that failed, were missing, or needed workarounds}
- **Friction**: {where the agent got stuck, retried, or misunderstood conventions}
- **Top 3 Improvements**: {specific skill/tool changes that would have helped most}

Formatting rules

1. Use ## (two hashes + space) for EVERY section header. NEVER use numbered lists, letters, or bold text as section separators.
2. Use the EXACT section names from the template above. Do not rename, reword, or add sections.
3. Each ## header MUST be preceded by a blank line and followed by a blank line.
4. Use - for unordered bullet points.
5. For numbered items within a section body, use 1., 2., etc. on their own lines. Do not escape the dots.
6. Do NOT escape markdown characters. No \*, \#, \-, \.. Write **bold**, not \*\*bold\*\*.
7. The description MUST be plain markdown. No Jira wiki markup, no HTML, no ADF.
8. Do NOT include the user’s email in the description body. Pass it only via the --email flag.

Example of a well-formatted description

## What happened
When running `uip maestro flow validate` on a flow with nested loops, the CLI returned a generic "expression error" with no line number or variable name, making it impossible to locate the issue.

## Sample prompts
1. "Build a flow that iterates over invoice line items and flags duplicates."
2. "Now add a nested loop to compare each item against the prior month's list."
3. "I keep getting 'currentItem is not defined' — which variable should I use inside the nested loop?"
4. "Run validate again and just tell me which line is broken."

## Error
ExpressionError: Invalid expression at unknown location — currentItem is not defined

## Environment
- Skill context: Flow
- uip version: 0.1.20
- CLI tools: docsai-tool 0.1.12
- OS: Windows 11 Enterprise 10.0.26100
- Tenant: demo (aro)

## Troubleshooting
- Project type: Flow (.flow)
- Key files: MyProcess.flow
- Last failed command: uip maestro flow validate MyProcess.flow --output json

## Session retrospective
- **Intent**: Build a flow that iterates over invoice line items and flags duplicates
- **Outcome**: Partial — flow runs but the nested loop variable reference fails at runtime
- **Tool & Skill Gaps**: (1) uip maestro flow validate gave no location info for expression errors. (2) No way to inspect available variables inside a loop scope.
- **Friction**: Agent tried 8 generate-validate-fix cycles guessing the correct variable name. The error message never identified which expression failed.
- **Top 3 Improvements**: (1) Include expression location (line/node) in validation errors. (2) Add a CLI command to list variables in scope at a given point. (3) Document loop variable naming conventions in the Flow skill.

Truncate the full description to 4000 characters max. Note if content was truncated.

Prepare attachments

Write sanitized copies of relevant project files to a temp directory:

mkdir -p "${TMPDIR:-${TMP:-/tmp}}/uip-feedback-attachments"

Copy and sanitize files based on skill context:

• Flow: the .flow file
• RPA: project.json, the failing workflow file (.cs or .xaml)
• Agents: pyproject.toml, bindings.json (redacted)
• Apps: package.json

Max 10 files, max 10MB each. Skip files that exceed limits.

Show preview and confirm

Display to the user:

**Type:** bug
**Priority:** normal
**Title:** [Flow] Expression error in nested loop currentItem
**Description:** (first 3 lines...)
**Attachments:** MyFlow.flow, project.json

Send this to UiPath? (yes/no)

The user can adjust type, priority, or title before confirming. Never send without explicit “yes”.

Step 4 – Send feedback

uip feedback send \
  --type "<bug|improvement>" \
  --title "<TITLE>" \
  --description "$(cat <<'FEEDBACK_EOF'
<DESCRIPTION_BODY>
FEEDBACK_EOF
)" \
  --priority "<critical|normal|minor>" \
  --attachment <FILE1> <FILE2> \
  --output json

If an email is available from uip login status, include --email "<EMAIL>".

Parse the JSON output. On success, show the user a confirmation with any reference ID returned.

Fallback: If uip feedback send fails (network, auth, CLI error), save the full feedback to ./feedback-report.md using the description body and tell the user: “Could not send automatically. The report is saved to feedback-report.md.”

Clean up temp attachments:

rm -rf "${TMPDIR:-${TMP:-/tmp}}/uip-feedback-attachments"

Step 5 – Report result

On success:

Feedback sent successfully.
- Reference: {reference ID from JSON response, if available}
- Type: {bug|improvement}
- Title: {title}

On fallback to file:

Could not send feedback automatically.
- Report saved to: ./feedback-report.md
- You can submit it manually or retry with `/uipath-feedback` later.

Always clean up temp attachments regardless of success or failure.

Sanitization Rules

Apply these rules to ALL content before it is included in the description or attachments:

1. Strip secrets. Remove lines matching (case-insensitive): token, secret, password, apiKey, credentials, authorization, Bearer, client_secret, connection_string
2. Redact PII in paths. Replace home directory prefixes with ~ (e.g., C:\Users\john.doe\projects\ -> ~/projects/). Replace usernames in URLs or paths with <USER>
3. Redact GUIDs in connection/binding fields: replace values with <REDACTED>
4. Truncate long content. Files over 150 lines: keep first 100 + ... [truncated N lines] ... + last 30. Full description: max 4000 characters
5. Never include: ~/.uipath/.auth, .env, .git/config, environment variables containing secrets, full conversation history
6. Never include customer data. Strip customer names, email addresses, and organization-specific identifiers from project files unless they are the tenant/org from uip login status
7. Sanitize sample prompts. Apply rules 1-3 and 6 to every captured prompt before including it under ## Sample prompts. Replace customer names, email addresses, project codenames, account IDs, ticket IDs, internal URLs, and file paths revealing usernames with <REDACTED>. If a prompt cannot be sanitized without losing its signal (the prompt is mostly customer-specific data), drop that prompt and pick another from Step 2e. Never quote a prompt verbatim if it contains a secret, even if the user typed it.

What NOT to Do

1. Do not ask questions you already know the answer to. If the conversation contains the error, the context, and what the user was doing – just confirm and send.
2. Do not include raw conversation dumps. ## What happened is a 2-3 sentence summary. ## Sample prompts is a curated max-5 selection per Step 2e — not a transcript.
3. Do not send without confirmation. Always preview first.
4. Do not include secrets, credentials, or PII. When in doubt, redact.
5. Do not attach unsanitized files. Always strip sensitive content before attaching.
6. Do not retry after user says “no”. Respect the decision. Ask if they want to adjust something or cancel entirely.
7. Do not modify the user’s description without showing them. The preview is the contract.
8. Do not send duplicate feedback. If the user already sent feedback for the same issue in this session, confirm they want to send again before proceeding.
9. Do not use numbered lists as section headers. Sections MUST use ## Header format. Writing 1. What happened 2. Error 3. Environment produces unreadable Jira issues.
10. Do not put the user email in the description body. Pass it only via the --email flag. Including it in the description violates sanitization rule #6.