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

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.
Never send without explicit user confirmation. Always show a preview and wait for "yes".
Never include secrets, tokens, credentials, or customer data. Sanitize all captured content before sending.
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.
Use
--output json
on
```
uip feedback send
```
to parse the result programmatically.
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

bash

uip --version 2>&1

Result	Action
Version output	Proceed to Step 2
`uip: command not found`	Tell user to install UiPath CLI. Stop.
Other error	Show the error. Stop.

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

Gather all context automatically. Run these substeps silently.

2a. Detect the area

The area (which product) becomes the title tag and a Jira label for filtering. Identify it from the last

uip <verb>

the user ran in this conversation. If no

uip

command is identifiable, fall back to the working directory, then to conversation context. Map command/signal → area:

Last command / signal	Area
`uip rpa …` , or `project.json` + `.cs` / `.xaml`	`RPA`
`uip maestro flow …` , or `*.flow` file	`Flow`
`uip maestro bpmn …` , or `*.bpmn` file	`BPMN`
`uip maestro case …` , or `caseplan.json`	`Case`
`uip <agent…>` , or `pyproject.toml` with `uipath` / `agent.json`	`Agents`
`uip codedapp …` , or `app.config.json` / `action-schema.json`	`CodedApps`
`uip api-workflow …`	`ApiWorkflow`
`uip df …`	`DataFabric`
`uip solution …` , or `*.uipx`	`Solution`
`uip tm …` (Test Manager)	`Test`
`uip tasks …`	`Tasks`
`uip admin …`	`Admin`
`uip gov …`	`Governance`
anything else ( `uip login` , generic Orchestrator / Integration Service / platform)	`Platform`

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

Optional CLI vs Skill marker. Only when it is clearly one or the other, add a second tag so triagers can route the report:

```
CLI
```
-- a
```
uip
```
command crashed, returned wrong output, or lacked a verb/flag.
```
Skill
```
-- you followed this skill's instructions and they were wrong, misleading, or missing.

Omit it when the cause is mixed or unclear -- don't force a guess.

2b. Capture environment

bash

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

Area	What to capture	Limits
Flow	`uip maestro flow validate <file> --output json` , `.flow` file content, directory listing	`.flow` : first 150 lines; directory: max 30 entries
RPA ( `.cs` or `.xaml` )	`project.json` dependencies, `uip rpa validate --output json` , list of workflow files ( `.cs` and/or `.xaml` )	File list: max 20 files; `project.json` : dependencies section only; failing workflow: first 150 lines
Agents	`pyproject.toml` , `bindings.json` (redact connection values), directory listing	`bindings.json` : redact all values; directory: max 30 entries
CodedApps	`package.json` (name, version, dependencies only), `.uipath/` listing	`package.json` : name + version + dependencies only
Other (Platform, Solution, Admin, …)	`uip login status --output json` output only	Strip tokens from output

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.

Intent: What was the user trying to build/edit/fix? Was the goal clear from the start?
Outcome: What was delivered vs. requested? Full / Partial / Failed.
Tool & Skill Gaps: Which tools or CLI commands were called but unhelpful? Which should have been called but weren't? Any failures or workarounds?
Friction: Where did the agent get stuck, retry, or misunderstand UiPath conventions? How many generate-validate-fix cycles?
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:

Type	Signals
`bug` (default)	Error messages, crashes, "doesn't work", "broken", runtime failures, unexpected behavior
`improvement`	"would be nice", "should support", "missing feature", "suggestion", "the skill told me wrong", "no command for X", feature requests

Default to

bug

when ambiguous.

Priority -- determine from conversation signals:

Priority	Signals
`critical`	Blocks user completely, data loss, security issue, CLI crashes with stack trace
`normal` (default)	Something is broken or missing but there is a workaround
`minor`	Cosmetic, nice-to-have, typos in output, low-impact

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:

What were you trying to do?

What happened?

Is this a bug or an improvement suggestion?

Otherwise, skip directly to Step 3.

Step 3 -- Build and confirm (only user interaction)

Title format

[<Area>] short description

<Area>

-- the area tag from Step 2a:

RPA

Flow

BPMN

Case

Agents

CodedApps

ApiWorkflow

DataFabric

Solution

Platform

Tasks

Test

Admin

Governance

Optionally add a
```
[CLI]
```
or
```
[Skill]
```
tag after the area only when it is clearly one or the other (Step 2a):
```
[<Area>] [CLI] …
```
or
```
[<Area>] [Skill] …
```
.
Do NOT put the type (Bug/Improvement) in the title -- that is the issuetype, set via
```
--type
```
.

Examples:

[RPA] uip rpa run fails when project.json has no dependencies

[Flow] [Skill] Flow skill should list IxP models before adding an extraction node

The CLI derives Jira labels from these leading

[Tag]

segments of the title, so the same tags are both visible in the title and filterable as labels -- no extra flags.

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
- Area: {area}
- 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

Use
```
## 
```
(two hashes + space) for EVERY section header. NEVER use numbered lists, letters, or bold text as section separators.
Use the EXACT section names from the template above. Do not rename, reword, or add sections.
Each
```
## 
```
header MUST be preceded by a blank line and followed by a blank line.
Use
```
-
```
for unordered bullet points.
For numbered items within a section body, use
```
1.
```
,
```
2.
```
, etc. on their own lines. Do not escape the dots.
Do NOT escape markdown characters. No
```
\*
```
,
```
\#
```
,
```
\-
```
,
```
\.
```
. Write
```
**bold**
```
, not
```
\*\*bold\*\*
```
.
The description MUST be plain markdown. No Jira wiki markup, no HTML, no ADF — the CLI converts this markdown to the tracker's native format (Jira wiki markup) on send, so it renders cleanly.
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
- Area: 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:

bash

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

Copy and sanitize files based on the detected area:

Flow: the
```
.flow
```
file
RPA:
```
project.json
```
, the failing workflow file (
```
.cs
```
or
```
.xaml
```
)
Agents:
```
pyproject.toml
```
,
```
bindings.json
```
(redacted)
CodedApps:
```
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] [CLI] 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 (the title carries the area / optional CLI-or-Skill tag) before confirming. Never send without explicit "yes".

Step 4 -- Send feedback

Never inline the multi-line description as a
--description "…"
argument. On Windows PowerShell the native-command argument serializer mangles multi-line values (lines starting with

reach the CLI as options →

ValidationError

). Always pass the body through

--description-file

Write the sanitized description body to a temp file using the Write tool (not a shell heredoc — heredocs are bash-only and fail on PowerShell). Use an absolute path in the OS temp dir, e.g.
```
<temp>/uip-feedback/description.md
```
.
Invoke the CLI with
```
--description-file
```
pointing at that file:

bash

uip feedback send \
  --type "<bug|improvement>" \
  --title "<TITLE>" \
  --description-file "<TEMP>/uip-feedback/description.md" \
  --priority "<critical|normal|minor>" \
  --attachment <FILE1> <FILE2> \
  --output json

--description-file

reads the body from disk, so it is immune to shell quoting and works identically on PowerShell, cmd, and bash. (If the CLI predates this flag, pipe the body via stdin instead; do not inline it.)

The title (

--title

) is short and single-line, so passing it inline is safe. Its leading

[Tag]

segments (the area, plus an optional

[CLI]

[Skill]

marker) become Jira labels automatically -- no extra flags.

If an email is available from

uip login status

, include

--email "<EMAIL>"

. The CLI places it in the issue's Environment field, never in the description body.

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

Diagnose failures correctly. A

ValidationError

that names an option you did not pass (e.g. it complains about

or a bullet line) is a shell-quoting failure, not a CLI bug — you inlined a multi-line value. Fix it by using

--description-file

; do not report the CLI as broken and do not retry the same inline invocation.

Fallback: Only after

--description-file

genuinely fails (network, auth, real 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:

bash

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:

Strip secrets. Remove lines matching (case-insensitive):

token

secret

password

apiKey

credentials

authorization

Bearer

client_secret

connection_string

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>
```
Redact GUIDs in connection/binding fields: replace values with
```
<REDACTED>
```
Truncate long content. Files over 150 lines: keep first 100 +
```
... [truncated N lines] ...
```
+ last 30. Full description: max 4000 characters
Never include:
```
~/.uipath/.auth
```
,
```
.env
```
,
```
.git/config
```
, environment variables containing secrets, full conversation history
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
```
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

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.
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.
Do not send without confirmation. Always preview first.
Do not include secrets, credentials, or PII. When in doubt, redact.
Do not attach unsanitized files. Always strip sensitive content before attaching.
Do not retry after user says "no". Respect the decision. Ask if they want to adjust something or cancel entirely.
Do not modify the user's description without showing them. The preview is the contract.
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.
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.
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.

uipath-feedback

NPX Install

Tags

SKILL.md Content

UiPath Feedback

Critical Rules

Workflow

Step 1 -- Check prerequisites

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

2a. Detect the area

2b. Capture environment

2c. Capture skill-specific troubleshooting

2d. Capture the failing command

2e. Capture sample prompts

2f. Session retrospective

2g. Auto-detect type and priority

2h. Sanitize everything

2i. Only if context is insufficient

Step 3 -- Build and confirm (only user interaction)

Title format

Description body

Formatting rules

Example of a well-formatted description

Prepare attachments

Show preview and confirm

Step 4 -- Send feedback

Step 5 -- Report result

Sanitization Rules

What NOT to Do