uipath-feedback

UiPath へのフィードバック

uip feedback send を使って、自動収集されたトラブルシューティング情報とともに、構造化されたバグレポートや改善提案を UiPath に送信します。

設計原則：手間を最小限にする。 エージェントは会話からすでに問題の内容を把握しています。すでにわかっていることを再度尋ねないでください。必須のやり取りは送信前の確認だけです。

重要なルール

1. ユーザーとのやり取りは最小限にします。 会話に十分なコンテキスト（エラー、ユーザーが行っていた操作、発生した問題）が含まれている場合は、確認して送信する手順に進みます。何が起きたかを本当に判断できない場合にのみ、確認の質問をします。
2. ユーザーの明示的な確認なしに送信しないでください。 必ずプレビューを表示し、「yes」と返答するまで待ちます。
3. シークレット、トークン、認証情報、顧客データは決して含めないでください。 送信前に、収集したすべての内容をサニタイズします。
4. 会話履歴全体を含めないでください。 関連するコンテキストを2～3文にまとめます。サンプルプロンプト（ステップ2e）は厳選した最大5件であり、会話の記録ではありません。
5. uip feedback send では、結果をプログラムで解析できるように --output json を使用します。
6. uip feedback send が失敗した場合、収集したコンテキストが失われないよう、レポートを ./feedback-report.md に保存します。

ワークフロー

ステップ1 -- 前提条件を確認する

uip --version 2>&1

結果	対応
バージョンが出力された	ステップ2に進みます
uip: command not found	macOS/Linux では curl -fsSL https://download.uipath.com/uipath-cli/install.sh | bash、Windows PowerShell では irm https://download.uipath.com/uipath-cli/install.ps1 | iex を実行するようユーザーに伝えます。ここで終了します。
その他のエラー	エラーを表示します。ここで終了します。

ステップ2 -- 情報を調査して収集する（サイレント -- ユーザーとのやり取りなし）

すべてのコンテキストを自動的に収集します。以下のサブステップは、ユーザーに知らせずに実行します。

2a. 対象領域を特定する

対象領域（製品名）は、タイトルタグと 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.case／caseplan.json	Case
uip <agent…>、または uipath を含む pyproject.toml／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 または Skill のどちらかであることが明確な場合に限り、トリアージ担当者がレポートを振り分けられるよう、2つ目のタグを追加します。

• CLI -- uip コマンドがクラッシュした、誤った出力を返した、または動詞／フラグが不足していた。
• Skill -- このスキルの指示に従った結果、指示が誤っていた、誤解を招いた、または不足していた。

原因が複合的、または不明確な場合は省略します。無理に推測しないでください。

2b. 環境情報を収集する

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

ログイン状態から、tenantName、organizationName、baseUrl のみを抽出します。それ以外はすべて削除します。

ツール一覧から、各行のツール name と version を抽出します。

2c. スキル固有のトラブルシューティング情報を収集する

領域	収集する内容	制限
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（name、version、dependencies のみ）、.uipath/ の一覧	package.json：name、version、dependencies のみ
Other（Platform、Solution、Admin、…）	uip login status --output json の出力のみ	出力からトークンを削除

2d. 失敗したコマンドを収集する

現在の会話を確認し、最後に失敗した CLI コマンドを特定します。特定できる場合は、以下を収集します。

• コマンド全体
• stderr/stdout の出力（100行までに切り詰める）

特定できない場合は、このセクションを省略します。

2e. プロンプトの例を収集する

ユーザーが何をしようとしていたかが分かるプロンプトを、会話から3～5件選びます。これにより、ふりかえりだけでは得られないユーザー自身の言葉をトリアージ担当者に伝えられます。

選択ルール：

• 意図を述べているもの（「…するフローを作って」「…する必要がある」「…を手伝って」など）や、失敗を説明しているもの（「動かない」「結果が違う」など）を優先します。
• 表現は一字一句そのままにします。言い換えると重要な情報が失われます。サニタイズルールを適用してください。
• つなぎの言葉（「わかった」「ありがとう」「もう一度試して」など）は省略します。
• 内容のあるプロンプトが3件未満の場合は、あるものだけを含めます。数合わせはしないでください。
• 最大5件です。全プロンプトの合計文字数は1000文字未満にします。1件が200文字を超える場合は、最も有用な部分を残して ... [truncated] を付けて切り詰めます。
• 内容のあるプロンプトがない場合は、ステップ3の ## Sample prompts セクションを省略します。

2f. セッションのふりかえり

会話全体を確認し、構成に沿って自己評価を作成します。これはフィードバックの中で最も重要な部分です。手動のバグ報告では得られない背景情報を、トリアージ担当者に伝えます。

各質問に簡潔に回答します（各1～3文）。このセッションで実際に使用されたツール名、エラー、コマンド、ファイルに言及してください。

1. 意図：ユーザーは何を作成、編集、修正しようとしていましたか？最初から目的は明確でしたか？
2. 結果：依頼された内容に対して、何が提供されましたか？完全／部分的／失敗。
3. ツールとスキルの不足：呼び出されたものの役に立たなかったツールや CLI コマンドはどれですか？呼び出すべきだったのに呼び出されなかったものはありますか？失敗や回避策はありましたか？
4. つまずき：エージェントがつまずいたり、再試行したり、UiPath の慣例を誤解したりした箇所はどこですか？生成、検証、修正のサイクルは何回ありましたか？
5. 改善点トップ3：このセッションで最も効果があったと思われるスキルやツールの変更は何ですか？

2g. 種別と優先度を自動判定する

種別 -- 会話内の兆候から判断します。

種別	兆候
bug（デフォルト）	エラーメッセージ、クラッシュ、「動かない」「壊れている」、実行時の失敗、予期しない動作
improvement	「あると便利」「サポートしてほしい」「機能がない」「提案」「スキルの説明が間違っていた」「X を行うコマンドがない」、機能リクエスト

判断が曖昧な場合は、bug をデフォルトにします。

優先度 -- 会話内の兆候から判断します。

優先度	兆候
critical	ユーザーが完全に作業できない、データ損失、セキュリティ問題、CLI がスタックトレースを出してクラッシュする
normal（デフォルト）	問題や不足があるものの、回避策がある
minor	見た目の問題、あると便利な機能、出力の誤字、影響が小さい問題

判断が曖昧な場合は、normal をデフォルトにします。

2h. すべての情報をサニタイズする

続行する前に、収集した内容すべてに、下記のサニタイズルールを適用します。

2i. コンテキストが不十分な場合のみ

エージェントが実際に何が起きたのか判断できない場合（例：会話に先行するコンテキストがない状態で、ユーザーが /uipath-feedback と入力した場合）は、構造化された質問を1つ尋ねます。

UiPath にフィードバックを送信します。以下をお知らせください。

1. 何をしようとしていましたか？
2. 何が起きましたか？
3. これはバグですか、それとも改善の提案ですか？

それ以外の場合は、Step 3 に進みます。

Step 3 -- 作成して確認する（ユーザーとのやり取りのみ）

タイトルの形式

[<Area>] short description

• <Area> -- Step 2a のエリアタグ：RPA、Flow、BPMN、Case、Agents、CodedApps、ApiWorkflow、DataFabric、Solution、Platform、Tasks、Test、Admin、Governance。
• エリアの後に [CLI] または [Skill] タグを追加できるのは、Step 2a でどちらかだと明確に判断できる場合のみです：[<Area>] [CLI] … または [<Area>] [Skill] …。
• タイトルに種類（Bug/Improvement）を含めないでください。種類は --type で設定する issuetype です。

例：[RPA] uip rpa run fails when project.json has no dependencies · [Flow] [Skill] Flow skill should list IxP models before adding an extraction node

CLI はタイトルの先頭にある [Tag] セグメントから Jira ラベルを導出します。そのため、同じタグがタイトルに表示され、ラベルとしてもフィルタリング可能です。追加のフラグは不要です。

説明本文

--description の内容を作成します。

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

書式ルール

1. すべてのセクション見出しに ## （シャープ2つとスペース）を使用します。セクションの区切りとして番号付きリスト、文字、太字テキストを使用しないでください。
2. 上記のテンプレートにあるセクション名を正確に使用します。名前の変更、言い換え、セクションの追加はしないでください。
3. 各 ## 見出しの前後には空行を入れてください。
4. 順序なしリストには - を使用します。
5. セクション本文内の番号付き項目には、1.、2. などをそれぞれ独立した行に使用します。ピリオドをエスケープしないでください。
6. Markdown 文字をエスケープしないでください。\*、\#、\-、\. は使用しないでください。\*\*bold\*\* ではなく、**bold** と記述します。
7. 説明はプレーンな Markdown で記述する必要があります。Jira wiki 記法、HTML、ADF は使用しないでください。CLI は送信時にこの Markdown をトラッカーのネイティブ形式（Jira wiki 記法）に変換するため、正しく表示されます。
8. 説明本文にユーザーのメールアドレスを含めないでください。メールアドレスは --email フラグでのみ渡します。

書式が適切な説明の例

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

説明全体を最大4000文字に切り詰めます。内容を切り詰めた場合は、その旨を記載してください。

添付ファイルを準備する

関連するプロジェクトファイルのサニタイズ済みコピーを、一時ディレクトリに書き込みます。

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です。上限を超えるファイルはスキップします。

プレビューを表示して確認する

ユーザーに次の内容を表示します。

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

ユーザーは確認前に、種類、優先度、タイトル（タイトルにはエリアタグと任意の CLI または Skill タグが含まれます）を調整できます。明示的な「はい」の確認なしに、送信することは絶対にしないでください。

ステップ 4 — フィードバックを送信する

複数行の説明を --description "…" 引数に直接記述しないでください。 Windows PowerShell では、ネイティブコマンドの引数シリアライザーが複数行の値を壊します（- で始まる行がオプションとして CLI に渡され、ValidationError が発生します）。本文は必ず --description-file で渡してください。

1. Write ツール（シェルのヒアドキュメントではありません。ヒアドキュメントは Bash 専用で、PowerShell では失敗します）を使って、サニタイズ済みの説明本文を一時ファイルに書き込みます。OS の一時ディレクトリ内の絶対パスを使用します。例：<temp>/uip-feedback/description.md。
2. --description-file にそのファイルを指定して CLI を実行します。

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 はディスク上のファイルから本文を読み込むため、シェルの引用符による影響を受けず、PowerShell、cmd、Bash で同じように動作します。（CLI がこのフラグに対応する前のバージョンの場合は、本文を標準入力経由で渡してください。本文を直接記述してはいけません。）

タイトル（--title）は短い1行のテキストなので、直接指定しても安全です。先頭の [Tag] セグメント（領域と、任意の [CLI]／[Skill] マーカー）は Jira ラベルに自動的に変換されます。追加のフラグは不要です。

uip login status でメールアドレスを取得できた場合は、--email "<EMAIL>" を含めます。CLI はその値を課題の Environment フィールドに設定し、説明本文には含めません。

JSON の出力を解析します。成功した場合は、返された参照 ID があればそれを含めて、ユーザーに確認メッセージを表示します。

失敗を正しく診断してください。 指定していないオプション（例：- や箇条書きの行）について指摘する ValidationError は、CLI のバグではなくシェルの引用符によるエラーです。複数行の値を直接記述しています。--description-file を使って修正してください。CLI が壊れていると報告したり、同じ直接記述の呼び出しを再試行したりしてはいけません。

フォールバック： --description-file が実際に失敗した場合（ネットワーク、認証、実際の CLI エラー）に限り、説明本文を使ってフィードバック全体を ./feedback-report.md に保存し、ユーザーに次のように伝えます。 "自動送信できませんでした。レポートは feedback-report.md に保存されています。"

一時添付ファイルをクリーンアップします。

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

ステップ 5 — 結果を報告する

成功した場合：

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

ファイルへのフォールバック時：

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

成功した場合も失敗した場合も、必ず一時添付ファイルをクリーンアップしてください。

サニタイズのルール

説明または添付ファイルに含める前に、すべてのコンテンツに次のルールを適用してください。

1. シークレットを除去します。 次の文字列に一致する行を（大文字と小文字を区別せずに）削除します：token、secret、password、apiKey、credentials、authorization、Bearer、client_secret、connection_string
2. パス内の個人識別情報（PII）を秘匿します。 ホームディレクトリのプレフィックスを ~ に置き換えます（例：C:\Users\john.doe\projects\ -> ~/projects/）。URL またはパス内のユーザー名は <USER> に置き換えます。
3. 接続フィールド／バインディングフィールド内の GUID を秘匿します。値を <REDACTED> に置き換えます。
4. 長いコンテンツを切り詰めます。 150行を超えるファイルは、先頭100行、... [truncated N lines] ...、末尾30行を残します。説明全体は最大4000文字とします。
5. 次のものは絶対に含めないでください：~/.uipath/.auth、.env、.git/config、シークレットを含む環境変数、会話履歴全体
6. 顧客データは絶対に含めないでください。 uip login status で取得したテナント／組織に該当するものを除き、プロジェクトファイルから顧客名、メールアドレス、組織固有の識別子を削除します。
7. サンプルプロンプトをサニタイズします。 ## Sample prompts の下に含めるすべての取得済みプロンプトに、ルール1～3および6を適用します。顧客名、メールアドレス、プロジェクトのコードネーム、アカウント ID、チケット ID、内部 URL、ユーザー名が明らかになるファイルパスは <REDACTED> に置き換えます。プロンプトの要点が失われることなくサニタイズできない場合（大半が顧客固有のデータである場合）は、そのプロンプトを除外し、ステップ2eから別のプロンプトを選びます。ユーザーが入力したものであっても、シークレットを含むプロンプトをそのまま引用してはいけません。

してはいけないこと

1. 答えがすでに分かっている質問をしないでください。 会話にエラー、状況、ユーザーが行っていた操作が含まれている場合は、確認して送信してください。
2. 会話の生データをそのまま含めないでください。 ## What happened は2～3文の要約にしてください。## Sample prompts は、Step 2e に従って厳選した最大5件にしてください。会話の書き起こしではありません。
3. 確認を得ずに送信しないでください。 必ず最初にプレビューを表示してください。
4. 秘密情報、認証情報、個人を特定できる情報（PII）を含めないでください。 判断に迷った場合は、伏せてください。
5. サニタイズされていないファイルを添付しないでください。 添付する前に、必ず機密情報を削除してください。
6. ユーザーが「いいえ」と言った後に再試行しないでください。 その判断を尊重してください。内容を調整するか、完全にキャンセルするかを尋ねてください。
7. ユーザーに見せずに説明を変更しないでください。 プレビュー内容が確定内容です。
8. フィードバックを重複して送信しないでください。 このセッションで同じ問題についてユーザーがすでにフィードバックを送信している場合は、続行する前に、もう一度送信する意思があるか確認してください。
9. セクション見出しに番号付きリストを使わないでください。 セクションには必ず ## Header 形式を使ってください。1. What happened 2. Error 3. Environment のように書くと、Jira の課題が読みづらくなります。
10. 説明本文にユーザーのメールアドレスを記載しないでください。 --email フラグでのみ渡してください。説明に含めると、サニタイズルール #6 に違反します。