@uipath/skills 1.195.0

package/skills/uipath-data-fabric/references/records-query.md

@@ -0,0 +1,246 @@
+# Records Query Reference
+
+## Basic List (All Records)
+
+```bash
+# First page
+uip df records list <entity-id> --limit 50 --output json
+
+# Next page — pass NextCursor value from previous response
+uip df records list <entity-id> --limit 50 --cursor <NextCursor> --output json
+```
+
+Response: `{ TotalCount, Records, HasNextPage, NextCursor?, CurrentPage?, TotalPages? }`
+
+- Use `HasNextPage` to check if more records exist
+- Pass the `NextCursor` string value to `--cursor` to fetch the next page
+
+## Pagination
+
+Offset-based under the hood. Available on both `records list` and `records query`:
+
+- `-l, --limit <number>` — page size, default `50`, min `1`. Keep constant across a sweep (changing it re-slices the offset and can skip/duplicate records).
+- `--cursor <NextCursor>` — opaque string from previous response. Pass verbatim; never hand-craft.
+- `-o, --offset <number>` — non-negative record index. Rounded down to the nearest page boundary (`jumpToPage = floor(offset / limit) + 1`). **Mutually exclusive with `--cursor`** — passing both errors with *"--offset and --cursor are mutually exclusive"*.
+- Stop when `HasNextPage: false`. `CurrentPage` / `TotalPages` are informational.
+
+```bash
+# Sequential sweep
+uip df records list <entity-id> --limit 100 --output json
+uip df records list <entity-id> --limit 100 --cursor "<NextCursor>" --output json
+
+# Jump directly to the page containing record #250 (with --limit 100 → page 3)
+uip df records list <entity-id> --limit 100 --offset 250 --output json
+```
+
+## Always Query the Server for Answers
+
+Issue a fresh `records query` (or `records list`) — don't filter cached transcript data. Records mutate between turns, and the CLI call is the audit trail. Patterns: [filtered query](#filtered-query), [choice-set](#filtering-on-choice-set-fields), [relationship](#filtering-on-relationship-fields), [aggregates](#aggregates-server-side).
+
+## Filtered Query
+
+```bash
+uip df records query <entity-id> \
+  --body '{"filterGroup":{"logicalOperator":0,"queryFilters":[{"fieldName":"Status","operator":"=","value":"active"}]}}' \
+  --output json
+```
+
+Pagination uses the same `--limit` / `--cursor` / `--offset` flags as `records list` — never body keys.
+
+The `filterGroup` shape, operators, response, and per-type support are in [`filter-platform-contract.md`](filter-platform-contract.md). Beyond the filter, the query body accepts:
+
+- `"selectedFields": ["F1","F2"]` — projection. Default is all fields (SKILL.md Rule 16).
+- `"sortOptions": [{ "fieldName": "Score", "isDescending": true }]` — server-side sort.
+
+### Verifying a filter applied
+
+Compare the response's `TotalCount` against an unfiltered baseline. If they match, the filter didn't narrow the result set — re-check the body against the contract.
+
+### Nested Filter Groups
+
+```json
+{
+  "filterGroup": {
+    "logicalOperator": 1,
+    "filterGroups": [
+      {
+        "logicalOperator": 0,
+        "queryFilters": [
+          { "fieldName": "Status", "operator": "=", "value": "active" },
+          { "fieldName": "Score", "operator": ">", "value": "50" }
+        ]
+      },
+      {
+        "logicalOperator": 0,
+        "queryFilters": [
+          { "fieldName": "Priority", "operator": "=", "value": "high" }
+        ]
+      }
+    ]
+  }
+}
+```
+
+### Filtering on Choice-Set Fields
+
+Filter on the integer `NumberId` (as a string in `value` / `valueList`), never the display label. Resolve via `choice-sets list-values <choice-set-id>` first.
+
+```bash
+# CHOICE_SET_SINGLE — category == "travel" (NumberId 1)
+uip df records query <entity-id> --body \
+  '{"filterGroup":{"logicalOperator":0,"queryFilters":[{"fieldName":"category","operator":"=","value":"1"}]}}' \
+  --output json
+```
+
+**`CHOICE_SET_MULTIPLE`** has special `=` vs `contains` semantics — see the [filter contract](filter-platform-contract.md#operator-support-by-field-type) Complex-field values line. Practical examples:
+
+```bash
+# Membership — records tagged with NumberId 1
+uip df records query <entity-id> --body \
+  '{"filterGroup":{"logicalOperator":0,"queryFilters":[{"fieldName":"tags","operator":"contains","value":"1"}]}}' \
+  --output json
+
+# Set equality — tags == exactly {1,3}
+uip df records query <entity-id> --body \
+  '{"filterGroup":{"logicalOperator":0,"queryFilters":[{"fieldName":"tags","operator":"=","value":"[1,3]"}]}}' \
+  --output json
+```
+
+Failure modes: `=` with a bare value (`"1"`) → HTTP 400. `contains` with brackets (`"[1]"`) → HTTP 400. For per-value reporting, run `contains` per `NumberId`; for distribution of exact combinations, use `groupBy: ["tags"]` with `COUNT`.
+
+### Filtering on Relationship Fields
+
+Filter on the target record's UUID `Id`, regardless of which field was bound as `referenceFieldId` (that controls the join, not the stored value). If the user describes the parent by another field (email, name, etc.), resolve the UUID first on the parent entity, then filter the child.
+
+```bash
+# Direct
+uip df records query <child-entity-id> --body \
+  '{"filterGroup":{"logicalOperator":0,"queryFilters":[{"fieldName":"customerId","operator":"=","value":"<parent-uuid>"}]}}' \
+  --output json
+
+# Resolve-first: email → Id on parent, then filter child
+uip df records query <parent-entity-id> --body \
+  '{"filterGroup":{"logicalOperator":0,"queryFilters":[{"fieldName":"Email","operator":"=","value":"alice@example.com"}]},"selectedFields":["Id"]}' \
+  --output json
+```
+
+## Aggregates (server-side)
+
+Add `aggregates` and optional `groupBy` to the query body to return aggregated rows instead of records. Each entry in `aggregates` produces one column on each result row, keyed by `alias`.
+
+> **Field names are case-sensitive.** Examples below use `Status` as a placeholder — substitute the exact casing from the target entity's schema (`uip df entities get <entity-id>` lists the real names).
+
+```bash
+# Total count of records (no grouping → single result row)
+uip df records query <entity-id> \
+  --body '{"aggregates":[{"function":"COUNT","field":"Id","alias":"total"}]}' \
+  --output json
+```
+
+Response: `Data.Records` is a single row — `[{ "total": 250 }]`.
+
+```bash
+# Count per group (one result row per distinct value)
+uip df records query <entity-id> \
+  --body '{"selectedFields":["Status"],"groupBy":["Status"],"aggregates":[{"function":"COUNT","field":"Id","alias":"total"}]}' \
+  --output json
+```
+
+Response: one row per group, each with the group fields + every aggregate alias — `[{ "Status": "Open", "total": 12 }, { "Status": "Closed", "total": 5 }]`.
+
+### Functions
+
+| `function` | Applies to | Notes |
+|------------|-----------|-------|
+| `COUNT` | Any field | Counts non-null values. For total row count use `field: "Id"` |
+| `SUM`   | Numeric only | |
+| `AVG`   | Numeric only | |
+| `MIN`   | Numeric / date | |
+| `MAX`   | Numeric / date | |
+
+Values are the **uppercase strings** above — `"COUNT"` not `"Count"`.
+
+### Aggregate Body Schema
+
+```json
+{
+  "selectedFields": ["Status"],
+  "groupBy": ["Status"],
+  "aggregates": [
+    { "function": "COUNT", "field": "Id",     "alias": "total" },
+    { "function": "AVG",   "field": "amount", "alias": "avgAmount" }
+  ]
+}
+```
+
+- `aggregates[].alias` is optional. When omitted, the server returns the column keyed as `{FUNCTION}_{field}` (for example `COUNT_Id`, `AVG_amount`). Provide an `alias` for stable, readable keys in your downstream code.
+- When `selectedFields` is present alongside `aggregates`, every entry in `selectedFields` must also appear in `groupBy` — otherwise the API rejects the request. The shortcut: use the same array for both, as in the examples above.
+- `groupBy` and `selectedFields` may reference root-entity fields only — expansions are not supported in aggregate mode.
+- The same `filterGroup`, `sortOptions`, and pagination flags (`--limit`, `--cursor`) work alongside aggregates. Filters are applied **before** grouping (SQL `WHERE`).
+- Choice-set fields in `groupBy` / filters require the numeric `numberId`, not the display label. Discover via the choice-set lookup if you need to filter / group by a choice value.
+
+> Needs `@uipath/data-fabric-tool` `1.0.1+`; older versions silently drop `aggregates`/`groupBy` and return a plain record list — `uip tools install @uipath/data-fabric-tool@latest`.
+
+## Insert Records
+
+The CLI routes by body shape: a JSON object (or 1-element array) calls the single-record endpoint; a JSON array with 2+ elements calls the batch endpoint.
+
+```bash
+# Single record — JSON object
+uip df records insert <entity-id> --body '{"Name":"Alice","Score":95}' --output json
+
+# Batch insert — JSON array with 2+ records
+uip df records insert <entity-id> \
+  --body '[{"Name":"Alice","Score":95},{"Name":"Bob","Score":82}]' \
+  --output json
+
+# From JSON file
+uip df records insert <entity-id> --file records.json --output json
+```
+
+Single insert response: `{ Code: "RecordInserted", Data: { ...record with Id } }`
+
+Batch insert response: `{ Code: "RecordsBatchInserted", Data: { SuccessCount, FailureCount, SuccessRecords, FailureRecords } }`
+
+### Writing Choice-Set and Relationship Values
+
+| Field type | Value | Resolve via |
+|------------|-------|-------------|
+| `CHOICE_SET_SINGLE` | Integer `NumberId` | `choice-sets list-values <choice-set-id>` |
+| `CHOICE_SET_MULTIPLE` | Integer `NumberId` array | `choice-sets list-values <choice-set-id>` |
+| `RELATIONSHIP` | Target record's UUID `Id` (always — the binding `referenceFieldId` controls the join, not the stored value) | `records query <target-entity-id>` on the unique field |
+
+```bash
+uip df records insert <entity-id> \
+  --body '{"amount":250,"category":1,"tags":[1,3],"customerId":"<target-uuid>"}' --output json
+```
+
+Display labels, choice-value UUIDs, and non-UUID relationship values are rejected — resolve first. Reads echo the same shape.
+
+## Update Records
+
+The CLI routes by body shape: a JSON object (or 1-element array) calls the single-record endpoint; a JSON array with 2+ elements calls the batch endpoint. Both require `Id` in the body.
+
+```bash
+# Single record — JSON object with Id
+uip df records update <entity-id> --body '{"Id":"<record-id>","Score":100}' --output json
+
+# Batch update — JSON array, each element must include Id
+uip df records update <entity-id> \
+  --body '[{"Id":"<id1>","Score":100},{"Id":"<id2>","Score":90}]' \
+  --output json
+```
+
+Choice / relationship fields use the same value form as insert — see [Writing Choice-Set and Relationship Values](#writing-choice-set-and-relationship-values).
+
+Single update response: `{ Code: "RecordUpdated", Data: { ...updated record } }`
+
+Batch update response: `{ Code: "RecordsBatchUpdated", Data: { SuccessCount, FailureCount, SuccessRecords, FailureRecords } }`
+
+## Delete Records
+
+```bash
+uip df records delete <entity-id> <id1> <id2> <id3> --output json
+```
+
+Response: `{ Code: "RecordsDeleted", Data: { SuccessCount, FailureCount, SuccessRecords, FailureRecords } }`

package/skills/uipath-feedback/SKILL.md

@@ -0,0 +1,350 @@
+---
+name: uipath-feedback
+description: "UiPath bug reports and improvement suggestions via `uip feedback send`. Use for 'report issue', 'send feedback', 'file a bug', or the /uipath-feedback command. For investigating an error rather than reporting one→uipath-troubleshoot."
+when_to_use: "User says 'this is broken', 'this isn't working', 'report a bug', 'send feedback', 'something is wrong', 'file an issue', 'this crashed', 'wrong result' about a UiPath product, CLI, or skill. Also fires on the /uipath-feedback slash command."
+allowed-tools: Bash, Read, Write, Glob, Grep, AskUserQuestion
+user-invocable: true
+---
+
+# 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 skill context
+
+Check the current working directory. Stop at first match:
+
+| Check | Skill context |
+|---|---|
+| `*.flow` file exists | **Flow** |
+| `pyproject.toml` with `uipath` dependency | **Agents** |
+| `project.json` + `*.cs` and/or `*.xaml` files | **RPA** |
+| `package.json` + `.uipath/` directory | **Apps** |
+| None of the above | **Platform** |
+
+If ambiguous, infer from the conversation. Do NOT ask the user -- pick the best match.
+
+#### 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
+
+| Skill context | 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 --use-studio`, 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 |
+| **Apps** | `package.json` (name, version, dependencies only), `.uipath/` listing | `package.json`: name + version + dependencies only |
+| **Platform** | `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
+
+```
+[Product] short description
+```
+
+Product names:
+
+| Skill context | Title prefix |
+|---|---|
+| Flow | `[Flow]` |
+| RPA | `[RPA]` |
+| Agents | `[Agents]` |
+| Apps | `[Apps]` |
+| Platform | `[Platform]` |
+| Interact | `[Interact]` |
+
+#### 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:
+
+```bash
+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
+
+```bash
+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:
+
+```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:
+
+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.