uipath-feedback

# 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 ```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. 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: | 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](#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 ``` [<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 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 — the CLI converts this markdown to the tracker's native format (Jira wiki markup) on send, so it renders cleanly. 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 - 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`. 1. 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`. 2. 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 ```