uipath-feedback

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

UiPath Feedback

UiPath 反馈提交

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.

通过

uip feedback send

向UiPath提交结构化Bug报告或改进建议，同时自动捕获排查信息。

设计原则：最低摩擦成本。Agent已从对话中了解问题所在，无需重复询问已知信息。唯一必需的交互是发送前的确认环节。

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.

最小化用户交互。若对话已包含足够上下文（错误信息、用户操作、问题表现），直接进入确认发送环节。仅当确实无法判断问题时，才提出澄清问题。
未经用户明确确认绝不发送。始终展示预览内容，等待用户回复「yes」。
绝不包含密钥、令牌、凭证或客户数据。发送前需清理所有捕获内容。
绝不包含完整对话历史。将相关上下文总结为2-3句话。示例提示（步骤2e）最多精选5条，而非完整对话记录。
在
uip feedback send
中使用
--output json
，以程序化方式解析结果。
若
uip feedback send
执行失败，将报告保存至
```
./feedback-report.md
```
，避免用户丢失已收集的上下文信息。

Workflow

工作流程

Step 1 -- Check prerequisites

步骤1 -- 检查前置条件

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.

bash

uip --version 2>&1

结果	操作
输出版本信息	进入步骤2
`uip: command not found`	告知用户安装UiPath CLI，流程终止
其他错误	展示错误信息，流程终止

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

步骤2 -- 自动分析与捕获（静默执行，无需用户交互）

Gather all context automatically. Run these substeps silently.

自动收集所有上下文信息，静默执行以下子步骤。

2a. Detect the area

2a. 识别产品领域

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.

领域（对应产品）将作为标题标签和Jira筛选标签。从对话中用户最后执行的

uip <verb>

命令识别。若无法识别

uip

命令，则回退至工作目录，再依据对话上下文判断。命令/信号与领域映射如下：

最后执行的命令/信号	领域
`uip rpa …` ，或存在 `project.json` + `.cs` / `.xaml` 文件	`RPA`
`uip maestro flow …` ，或存在 `*.flow` 文件	`Flow`
`uip maestro bpmn …` ，或存在 `*.bpmn` 文件	`BPMN`
`uip maestro case …` ，或存在 `caseplan.json` 文件	`Case`
`uip <agent…>` ，或 `pyproject.toml` 包含 `uipath` / 存在 `agent.json`	`Agents`
`uip codedapp …` ，或存在 `app.config.json` / `action-schema.json`	`CodedApps`
`uip api-workflow …`	`ApiWorkflow`
`uip df …`	`DataFabric`
`uip solution …` ，或存在 `*.uipx` 文件	`Solution`
`uip tm …` （Test Manager）	`Test`
`uip tasks …`	`Tasks`
`uip admin …`	`Admin`
`uip gov …`	`Governance`
其他情况（ `uip login` 、通用Orchestrator/Integration Service/平台）	`Platform`

若存在歧义，从对话中推断，请勿询问用户，选择最匹配的领域。

可选CLI与Skill标记。仅当明确属于其中一类时，添加第二个标签以便处理人员分流：

```
CLI
```
--
```
uip
```
命令崩溃、返回错误输出或缺少动词/参数。
```
Skill
```
-- 遵循该Skill的指令后出现错误、误导或缺失内容。

若原因混合或不明确，请勿添加该标记，避免强行猜测。

2b. Capture environment

2b. 捕获环境信息

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.

bash

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

从登录状态中仅提取：

tenantName

、

organizationName

、

baseUrl

，移除其他所有内容。

从工具列表中提取每行的工具

name

和

version

。

2c. Capture skill-specific troubleshooting

2c. 捕获特定领域的排查信息

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

领域	需捕获内容	限制
Flow	`uip maestro flow validate <file> --output json` 、 `.flow` 文件内容、目录列表	`.flow` 文件：保留前150行；目录列表：最多30条
RPA（ `.cs` 或 `.xaml` ）	`project.json` 依赖项、 `uip rpa validate --output json` 、工作流文件列表（ `.cs` 和/或 `.xaml` ）	文件列表：最多20个； `project.json` ：仅保留依赖项部分；出错的工作流：保留前150行
Agents	`pyproject.toml` 、 `bindings.json` （脱敏连接值）、目录列表	`bindings.json` ：脱敏所有值；目录列表：最多30条
CodedApps	`package.json` （仅名称、版本、依赖项）、 `.uipath/` 目录列表	`package.json` ：仅保留名称+版本+依赖项
其他（Platform、Solution、Admin等）	仅 `uip login status --output json` 的输出	移除输出中的令牌

2d. Capture the failing command

2d. 捕获出错的命令

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.

回顾当前对话，找到最后执行失败的CLI命令。若可识别，捕获：

完整命令
其stderr/stdout输出（截断至100行）

若无法识别，跳过此部分。

2e. Capture sample prompts

2e. 捕获示例提示

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.

从对话中选取3-5条用户提示，展示用户的操作意图。这些内容能为处理人员提供手动Bug报告无法涵盖的上下文：用户的真实表述。

选择规则：

优先选择表述意图（如「构建一个流程以…」「我需要…」「帮我…」）或描述问题（如「这个功能坏了」「结果错误」）的提示。
保留原文措辞，转述会丢失关键信息。需遵循脱敏规则。
跳过无意义内容（如「ok」「谢谢」「再试一次」）。
若实质性提示不足3条，保留现有内容，无需补充。
最多保留5条提示，总长度不超过1000字符。单条提示超过200字符时，截断为
```
... [已截断]
```
，保留最具信息量的部分。
若无实质性提示，在步骤3中完全省略
```
## 示例提示
```
部分。

2f. Session retrospective

2f. 会话回顾

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?

回顾完整对话，生成结构化自我评估。这是反馈中最有价值的部分，能为处理人员提供手动Bug报告无法提供的上下文。

简洁回答以下问题（每个问题1-3句话），需引用本次会话中的实际工具名称、错误信息、命令和文件。

意图：用户试图构建/编辑/修复什么？目标从一开始就明确吗？
结果：交付内容与需求对比如何？完成/部分完成/失败。
工具与Skill缺口：哪些工具或CLI命令调用后无帮助？哪些应该调用但未调用？是否存在故障或临时解决方案？
摩擦点：Agent在哪些环节受阻、重试或误解UiPath规范？经历了多少次生成-验证-修复循环？
Top 3改进点：哪些Skill/工具的变更对本次会话影响最大？

2g. Auto-detect type and priority

2g. 自动检测类型与优先级

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.

类型 -- 根据对话信号判断：

类型	信号
`bug` （默认）	错误信息、崩溃、「无法工作」「已损坏」、运行时故障、意外行为
`improvement`	「如果有就好了」「应该支持」「缺少功能」「建议」「Skill给出错误指引」「没有针对X的命令」、功能请求

若存在歧义，默认设为

bug

。

优先级 -- 根据对话信号判断：

优先级	信号
`critical`	完全阻塞用户、数据丢失、安全问题、CLI崩溃并抛出堆栈跟踪
`normal` （默认）	功能损坏或缺失，但存在临时解决方案
`minor`	外观问题、锦上添花的功能、输出中的拼写错误、低影响问题

若存在歧义，默认设为

normal

。

2h. Sanitize everything

2h. 全面脱敏

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

在继续下一步前，对所有捕获内容应用下文脱敏规则中的所有条款。

2i. Only if context is insufficient

2i. 仅当上下文不足时

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.

若Agent确实无法判断问题（如用户仅输入

/uipath-feedback

，对话无前置上下文），提出一个结构化问题：

我将向UiPath发送反馈，请告知：

你试图完成什么操作？

发生了什么问题？

这是Bug报告还是改进建议？

否则，直接进入步骤3。

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

步骤3 -- 构建报告并确认（仅此环节需用户交互）

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.

[<领域>] 简短描述

<领域>

-- 步骤2a中确定的领域标签：

RPA

、

Flow

、

BPMN

、

Case

、

Agents

、

CodedApps

、

ApiWorkflow

、

DataFabric

、

Solution

、

Platform

、

Tasks

、

Test

、

Admin

、

Governance

。

仅当明确属于其中一类时，可在领域后添加
```
[CLI]
```
或
```
[Skill]
```
标记（步骤2a）：
```
[<领域>] [CLI] …
```
或
```
[<领域>] [Skill] …
```
。
请勿在标题中包含类型（Bug/Improvement），类型通过
```
--type
```
参数设置。

示例：

[RPA] uip rpa run在project.json无依赖项时执行失败

[Flow] [Skill] Flow Skill应在添加提取节点前列出IxP模型

CLI会从标题开头的

[标签]

段生成Jira标签，因此这些标签既会显示在标题中，也可作为筛选标签使用，无需额外参数。

Description body

描述正文

Build the

--description

content:

undefined

构建

--description

内容：

undefined

What happened

问题描述

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

{用户的问题 -- 使用用户原话或从对话中总结}

Sample prompts

示例提示

"{prompt 1 -- verbatim, sanitized}"
"{prompt 2 -- verbatim, sanitized}"
"{prompt 3 -- verbatim, sanitized}"

"{提示1 -- 原文，已脱敏}"
"{提示2 -- 原文，已脱敏}"
"{提示3 -- 原文，已脱敏}"

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})

领域：{领域}
uip版本：{版本}
CLI工具：{名称版本, 名称版本, ...}
操作系统：{系统信息}
租户：{租户} ({组织})

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}

undefined

意图：{用户试图完成的操作}
结果：{完成 | 部分完成 | 失败 -- 交付内容与需求对比}
工具与Skill缺口：{故障、缺失或需临时解决方案的工具/命令}
摩擦点：{Agent受阻、重试或误解规范的环节}
Top 3改进点：{对本次会话帮助最大的具体Skill/工具变更}

undefined

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.

所有章节标题使用
```
## 
```
（两个井号+空格）。绝不使用编号列表、字母或粗体作为章节分隔符。
使用上述模板中的精确章节名称，不得重命名、改写或添加章节。
每个
```
## 
```
标题前必须有空白行，后也必须有空白行。
使用
```
-
```
作为无序列表标记。
章节内的编号项使用
```
1.
```
、
```
2.
```
等单独成行，无需转义点号。
无需转义Markdown字符，无需使用
```
\*
```
、
```
\#
```
、
```
\-
```
、
```
\.
```
，直接写
```
**粗体**
```
即可。
描述必须为纯Markdown格式，不得使用Jira wiki标记、HTML或ADF -- CLI会在发送时将此Markdown转换为跟踪系统的原生格式（Jira wiki标记），确保显示正常。
请勿在描述正文中包含用户邮箱，仅通过
```
--email
```
参数传递。

Example of a well-formatted description

格式规范的描述示例

undefined

undefined

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.

在包含嵌套循环的流程上运行

uip maestro flow validate

时，CLI返回通用的「表达式错误」，无行号或变量名，导致无法定位问题。

Sample prompts

示例提示

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

"构建一个流程，遍历发票行项目并标记重复项。"
"现在添加嵌套循环，将每个项目与上月列表对比。"
"我一直收到'currentItem未定义'的错误 -- 嵌套循环内应使用哪个变量？"
"再次执行验证，直接告诉我哪一行出错了。"

Error

错误信息

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

ExpressionError: 未知位置存在无效表达式 — currentItem未定义

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)

领域：Flow
uip版本：0.1.20
CLI工具：docsai-tool 0.1.12
操作系统：Windows 11 Enterprise 10.0.26100
租户：demo (aro)

Troubleshooting

排查信息

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

项目类型：Flow (.flow)
关键文件：MyProcess.flow
最后执行失败的命令：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.


<!--skill-flavor:feedback-description-budget:start-->
Truncate the full description to 4000 characters max. Note if content was truncated.
<!--skill-flavor:feedback-description-budget:end-->

<!--skill-flavor:feedback-prepare-attachments:start-->

意图：构建一个遍历发票行项目并标记重复项的流程
结果：部分完成 — 流程可运行，但嵌套循环的变量引用在运行时失败
工具与Skill缺口：(1) uip maestro flow validate未提供表达式错误的位置信息。(2) 无法查看循环范围内的可用变量。
摩擦点：Agent尝试了8次生成-验证-修复循环，猜测正确的变量名。错误消息从未指出哪个表达式出错。
Top 3改进点：(1) 在验证错误中包含表达式位置（行/节点）。(2) 添加CLI命令以查看指定位置的范围内变量。(3) 在Flow Skill中记录循环变量命名规范。


<!--skill-flavor:feedback-description-budget:start-->
将完整描述截断至最多4000字符，若内容被截断需注明。
<!--skill-flavor:feedback-description-budget:end-->

<!--skill-flavor:feedback-prepare-attachments:start-->

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.

将相关项目文件的脱敏副本写入临时目录：

bash

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

根据检测到的领域复制并脱敏文件：

Flow：
```
.flow
```
文件
RPA：
```
project.json
```
、出错的工作流文件（
```
.cs
```
或
```
.xaml
```
）
Agents：
```
pyproject.toml
```
、
```
bindings.json
```
（已脱敏）
CodedApps：
```
package.json
```

最多10个文件，单个文件最大10MB。超过限制的文件跳过。

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".

向用户展示：

**类型:** bug
**优先级:** normal
**标题:** [Flow] [CLI] 嵌套循环currentItem表达式错误
**描述:**（前3行...）
**附件:** MyFlow.flow, project.json

是否发送至UiPath？(yes/no)

用户可在确认前调整类型、优先级或标题（标题包含领域/可选CLI或Skill标记）。未经用户明确回复「yes」绝不发送。

Step 4 -- Send feedback

步骤4 -- 发送反馈

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"

绝不要将多行描述作为
--description "…"
参数直接传入。在Windows PowerShell中，原生命令参数序列化会破坏多行值（以

开头的行被CLI视为选项 →

ValidationError

）。始终通过

--description-file

传递正文。

使用Write工具将脱敏后的描述正文写入临时文件（不要使用shell heredoc，因为heredoc仅适用于bash，在PowerShell中会失败）。使用系统临时目录的绝对路径，例如
```
<temp>/uip-feedback/description.md
```
。
调用CLI，指定
```
--description-file
```
指向该文件：

bash

uip feedback send \
  --type "<bug|improvement>" \
  --title "<标题>" \
  --description-file "<临时目录>/uip-feedback/description.md" \
  --priority "<critical|normal|minor>" \
  --attachment <文件1> <文件2> \
  --output json

--description-file

从磁盘读取正文，不受shell引号限制，在PowerShell、cmd和bash中表现一致。（若CLI不支持此参数，可通过stdin传递正文，不要直接传入。）

标题（

--title

）简短且为单行，直接传入是安全的。其开头的

[标签]

段（领域+可选

[CLI]

[Skill]

标记）会自动成为Jira标签，无需额外参数。

若

uip login status

返回邮箱信息，添加

--email "<邮箱>"

参数。CLI会将其放入问题的环境字段，绝不会出现在描述正文中。

解析JSON输出。成功时，向用户展示确认信息及返回的参考ID（若有）。

正确诊断失败原因。若出现

ValidationError

且提及未使用的选项（如抱怨

或项目符号行），这是shell引号问题，而非CLI Bug — 你直接传入了多行值。需通过

--description-file

修复，不要将CLI报告为故障，也不要重试相同的直接传入调用。

备选方案：仅当

--description-file

确实执行失败（网络、认证、真实CLI错误）时，将完整反馈保存至

./feedback-report.md

，并告知用户："无法自动发送报告。报告已保存至
feedback-report.md
。"

清理临时附件：

bash

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

Step 5 -- Report result

步骤5 -- 报告结果

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.

成功时：

反馈发送成功。
- 参考ID：{JSON响应中的参考ID，若存在}
- 类型：{bug|improvement}
- 标题：{标题}

保存至文件时：

无法自动发送反馈。
- 报告已保存至：./feedback-report.md
- 你可手动提交或稍后使用`/uipath-feedback`重试。

无论成功或失败，始终清理临时附件。

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.

在将内容纳入描述或附件前，对所有内容应用以下规则：

移除密钥。删除匹配（不区分大小写）的行：

token

、

secret

、

password

、

apiKey

、

credentials

、

authorization

、

Bearer

、

client_secret

、

connection_string

脱敏路径中的个人身份信息（PII）。将主目录前缀替换为
```
~
```
（例如
```
C:\Users\john.doe\projects\
```
→
```
~/projects/
```
）。将URL或路径中的用户名替换为
```
<USER>
```
脱敏连接/绑定字段中的GUID：将值替换为
```
<已脱敏>
```
截断长内容。超过150行的文件：保留前100行 +
```
... [已截断N行] ...
```
+ 最后30行。完整描述：最多4000字符
绝不包含：
```
~/.uipath/.auth
```
、
```
.env
```
、
```
.git/config
```
、包含密钥的环境变量、完整对话历史
绝不包含客户数据。从项目文件中移除客户名称、邮箱地址和组织特定标识符，除非是
```
uip login status
```
返回的租户/组织信息
脱敏示例提示。对每条捕获的提示应用规则1-3和6后，再纳入
```
## 示例提示
```
部分。将客户名称、邮箱地址、项目代号、账户ID、工单ID、内部URL和暴露用户名的文件路径替换为
```
<已脱敏>
```
。若提示无法在不丢失关键信息的前提下脱敏（提示主要包含客户特定数据），则丢弃该提示并从步骤2e中选择另一条。若提示包含密钥，即使用户输入了原文，也绝不要引用。

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.

不要询问已知答案的问题。若对话已包含错误信息、上下文和用户操作，直接确认发送即可。
不要包含原始对话转储。
```
## 问题描述
```
是2-3句话的总结。
```
## 示例提示
```
是步骤2e中精选的最多5条内容，而非完整对话记录。
不要未经确认就发送。始终先展示预览。
不要包含密钥、凭证或PII。如有疑问，一律脱敏。
不要附加未脱敏的文件。附加前始终移除敏感内容。
用户回复「no」后不要重试。尊重用户决定，询问用户是否需要调整内容或完全取消。
不要在未展示给用户的情况下修改用户描述。预览内容即为最终约定。
不要发送重复反馈。若用户已在本次会话中针对同一问题发送过反馈，需先确认用户是否再次发送。
不要使用编号列表作为章节标题。章节必须使用
```
## 标题
```
格式。若写成
```
1. 问题描述  2. 错误信息  3. 环境信息
```
，会导致Jira问题难以阅读。
不要在描述正文中包含用户邮箱。仅通过
```
--email
```
参数传递。将邮箱放入描述正文违反脱敏规则第6条。