uipath-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

UiPath Solution & Artifact Reviewer

UiPath解决方案与工件评审工具

Review UiPath solutions and individual artifacts for structural validity, quality, best practices, optimization, and correctness. Produces a structured review report with findings and recommendations.

评审UiPath解决方案及单个工件的结构有效性、质量、最佳实践、优化效果和正确性。生成包含问题发现与建议的结构化评审报告。

When to Use This Skill

何时使用此技能

User asks to "review", "audit", "check quality of", or "evaluate" a UiPath project or solution
User asks "is this solution good?" or "what can be improved?"
User wants a pre-deployment quality gate check
User wants to understand the business value and architecture of an existing solution
User asks about best practices for a specific artifact type
User has inherited a UiPath project and wants to understand its quality

用户要求“评审”“审计”“检查质量”或“评估”UiPath项目/解决方案
用户询问“这个解决方案好不好？”或“有哪些可以改进的地方？”
用户需要部署前的质量关卡检查
用户希望了解现有解决方案的业务价值与架构
用户询问特定工件类型的最佳实践
用户接手了一个UiPath项目，希望了解其质量

Critical Rules

核心规则

NEVER manually modify any files. This skill is read-only. Exception: The command
```
uip agent refresh
```
is allowed and mandatory for low code agents, because it is not a manual modification, even when the command updates derived files -- do not restore or clean up those CLI-managed changes. If fixes are needed, identify them in the report and tell the user which skill to use (uipath-rpa, uipath-agents, uipath-maestro-flow, uipath-maestro-bpmn, uipath-api-workflow, uipath-coded-apps, uipath-platform, uipath-solution).
ALWAYS run validation and Workflow Analyzer before manual review. For RPA projects, run both
```
uip rpa validate
```
on every entry point AND
```
uip rpa build "<PROJECT_DIR>"
```
—
```
validate
```
catches structural / analyzer issues,
```
build
```
catches compile-time issues
```
validate
```
misses (unknown member names, invalid enum values, JIT failures). For low-code agents, run
```
uip agent refresh
```
and
```
uip agent validate
```
. Run
```
uip maestro flow validate
```
on flows,
```
uip maestro bpmn validate
```
on BPMN processes,
```
uip api-workflow validate
```
on API workflows. Report every command's Error / Warning / Info counts in the validation table, and a detail line for each Error and Warning — never a detail line for a clean result (Step 2d). A review without both
```
validate
```
AND
```
build
```
(for RPA) is incomplete and may ship broken member references.
ALWAYS discover and classify before reviewing. For solutions: classify every project before reviewing any individual one. For single projects: identify the project type and find the enclosing project directory before reviewing individual files.
Report severity for every finding. Use: Critical (blocks deployment), Warning (should fix), Info (improvement opportunity).
Understand business context first. Before evaluating optimization, ask or infer what the solution is trying to accomplish. A queue-based architecture is not "better" if the use case processes 5 items/day.
Use
--output json
on all CLI validation commands for programmatic parsing.
Do not duplicate what validation commands catch. Reference the validation output by rule ID and message — do not manually re-describe the same issue, and do not restate what a command checks or that it passed. Every validation result is accounted for by its count in the validation table; Errors and Warnings additionally get a detail line.
Cap the review at 30 minutes of analysis. For very large solutions (10+ projects), provide a summary review with deep dives on the 3 highest-risk projects. Offer to review remaining projects if the user wants.
Run the review CLI first, then apply the judgment catalog, for every agent encountered. First run
```
uip agent review
```
(low-code) or
```
uip codedagent review
```
(coded) with
```
--output json
```
— it returns the deterministic findings (Step 2.5a). Then load the format-specific judgment catalog (
```
agents-lowcode-rules.md
```
or
```
agents-coded-rules.md
```
). Future phases add catalogs for RPA, flows, coded apps. This holds even when the skill loads mid-task: if review work already started before this skill loaded (e.g., a generic code-review pass produced findings), Step 2.5a and the guardrail Step 0 catalog fetch are still mandatory — run them, then merge the earlier findings into this skill's report format. Prior review output is never a substitute for the review CLI or the live catalog.
Rule findings are authoritative as emitted. Carry review-CLI
```
RuleId
```
,
```
Severity
```
,
```
Description
```
,
```
File
```
, and
```
SuggestedFix
```
into the report verbatim. Format the
```
Recommendation
```
as
```
<File>: <Description>. <SuggestedFix>
```
. Write judgment-catalog findings in the same format, with concise wording. Map severity to the report's bands:
```
error
```
→ Critical,
```
warning
```
→ Warning,
```
info
```
→ Info.
```
judgment
```
severity rows default to Warning; the agent may escalate or de-escalate with reasoning logged in the finding's
```
description
```
. Do not re-rank otherwise.
Report rules that could not be applied (missing tooling, missing file, review CLI unavailable,
```
status: deferred
```
) in a dedicated "Rules Skipped" subsection of the report — never silently skip. Only report when the rule was intended, but could not be applied for some reason. Non-applicable rules are not skipped.
Never invent
rule_id
values. Every
```
rule_id
```
cited in the report MUST appear verbatim in EITHER a loaded judgment-catalog file (
```
references/agents/agents-*-rules.md
```
) OR the
```
uip agent review
```
/
```
uip codedagent review
```
JSON output.
```
rule_id
```
is a stable contract identifier — consumers grep for it, dashboards aggregate by it, audits trace it. An invented identifier looks authoritative but cannot be looked up, doesn't aggregate, and produces a different name for the same observation on the next run. If you observe a real, critical issue covered by neither source, the finding is still valid — surface it under Critical Findings without a
```
rule_id
```
(no
```
`RULE_ID`
```
backtick token in the line). Only critical issues qualify — drop an unrule'd Warning or Info. Both sources are agent-only, so this governs agent findings. Before emitting the report, scan every cited
rule_id
and confirm it appears verbatim in a loaded catalog file or the review-CLI output; demote any that don't to
rule_id
-less findings.
Grade every agent project by the rubric — derived, never asserted. For agent projects (phase 1), produce a letter grade (
```
A
```
/
```
B
```
/
```
C
```
/
```
D
```
/
```
F
```
, no
```
+
```
/
```
-
```
) per agent and overall, computed in Step 4.5 as
```
min(G_det, G_jud)
```
. G_det is read from the review CLI's
Data.Grade
(Step 2.5a) — do not recompute it from finding counts. G_jud you compute from the judgment findings (Step 2.5b + Step 3) by severity count. CLI findings already shaped
```
Data.Grade
```
; only judgment findings feed G_jud, so each finding lands in exactly one sub-grade. Show the binding constraint for every grade; a grade with no shown derivation is invalid (low-code reports omit the printed derivation). A security or data-integrity judgment Critical forces F regardless of design quality (hard gate, not a blend). The skill grade is always ≤
```
Data.Grade
```
(min only lowers) — report both, never overwrite the CLI grade. Do not grade non-agent projects (RPA, flows, coded apps) — that rubric is a future phase. See references/agents/agent-grading-rubric.md.
These paths are CLI-managed —
uip agent refresh
owns them:
```
.agent-builder/
```
,
```
.local/build/
```
, and (low-code only) the root
```
entry-points.json
```
, regenerated from
```
agent.json
```
. Do not open their contents. Exclude them from classification, source-file selection, structural metrics, and manual checks. Raise a finding only when
```
refresh
```
fails to fix them — a pre-refresh mismatch is stale by construction, not a defect. Read low-code schemas from
```
agent.json
```
(
```
.inputSchema
```
/
```
.outputSchema
```
).

绝不手动修改任何文件。此技能为只读模式。例外情况：允许且必须对低代码Agent执行
```
uip agent refresh
```
命令，因为该命令不属于手动修改，即使它会更新派生文件——不要恢复或清理这些由CLI管理的变更。如需修复问题，请在报告中指明，并告知用户应使用的技能（uipath-rpa、uipath-agents、uipath-maestro-flow、uipath-maestro-bpmn、uipath-api-workflow、uipath-coded-apps、uipath-platform、uipath-solution）。
手动评审前必须运行验证与Workflow Analyzer。对于RPA项目，需对每个入口点运行
```
uip rpa validate
```
，同时运行
```
uip rpa build "<PROJECT_DIR>"
```
——
```
validate
```
用于捕获结构/分析器问题，
```
build
```
用于捕获
```
validate
```
遗漏的编译时问题（未知成员名称、无效枚举值、JIT失败）。对于低代码Agent，运行
```
uip agent refresh
```
和
```
uip agent validate
```
。对流程运行
```
uip maestro flow validate
```
，对BPMN流程运行
```
uip maestro bpmn validate
```
，对API工作流运行
```
uip api-workflow validate
```
。在验证表格中报告每个命令的错误/警告/信息数量，并为每个错误和警告添加详细说明——请勿为无问题的结果添加详细说明（步骤2d）。未同时运行
```
validate
```
和
```
build
```
（针对RPA）的评审是不完整的，可能会遗漏成员引用错误。
评审前必须先发现并分类。对于解决方案：在评审单个项目前，先对所有项目进行分类。对于单个项目：先确定项目类型，找到包含该项目的目录，再评审单个文件。
为每个发现标注严重程度。使用：Critical（严重）（阻碍部署）、Warning（警告）（应修复）、Info（信息）（改进机会）。
先理解业务上下文。在评估优化方案前，询问或推断解决方案的目标。如果用例每天仅处理5个条目，那么基于队列的架构并不一定“更优”。
所有CLI验证命令使用
--output json
参数，以便程序化解析。
不要重复验证命令已捕获的问题。通过规则ID和消息引用验证输出——不要手动重新描述同一问题，也不要重复说明命令检查的内容或其已通过。所有验证结果均通过验证表格中的数量体现；错误和警告需额外添加详细说明。
评审分析时间上限为30分钟。对于大型解决方案（10个以上项目），提供摘要评审，并对3个最高风险项目进行深度分析。若用户需要，可提出评审剩余项目。
遇到每个Agent时，先运行评审CLI，再应用判断规则集。首先运行
```
uip agent review
```
（低代码）或
```
uip codedagent review
```
（编码）并添加
```
--output json
```
参数——返回确定性发现（步骤2.5a）。然后加载特定格式的判断规则集（
```
agents-lowcode-rules.md
```
或
```
agents-coded-rules.md
```
）。后续阶段会添加针对RPA、流程、编码应用的规则集。即使技能在任务中途加载，此步骤仍需执行：如果在技能加载前已开始评审工作（例如，通用代码评审已产生发现），仍必须运行步骤2.5a和步骤0的规则集获取操作，然后将之前的发现合并到此技能的报告格式中。之前的评审输出不能替代评审CLI或实时规则集。
规则发现的内容需原样保留。将评审CLI的
```
RuleId
```
、
```
Severity
```
、
```
Description
```
、
```
File
```
和
```
SuggestedFix
```
直接带入报告。将
```
Recommendation
```
格式化为
```
<File>: <Description>. <SuggestedFix>
```
。判断规则集的发现也使用相同格式，措辞简洁。将严重程度映射到报告的等级：
```
error
```
→Critical，
```
warning
```
→Warning，
```
info
```
→Info。
```
judgment
```
严重程度默认对应Warning；Agent可根据发现描述中的理由升级或降级严重程度，否则不得重新评级。
报告无法应用的规则（缺少工具、缺少文件、评审CLI不可用、
```
status: deferred
```
），放在报告的“跳过的规则”小节中——绝不静默跳过。仅报告原本计划应用但因某些原因无法执行的规则。不适用的规则不属于跳过范畴。
不得自行创建
rule_id
值。报告中引用的每个
```
rule_id
```
必须与加载的判断规则集文件（
```
references/agents/agents-*-rules.md
```
）或
```
uip agent review
```
/
```
uip codedagent review
```
的JSON输出中的内容完全一致。
```
rule_id
```
是稳定的契约标识符——用户会通过它搜索，仪表盘会按它聚合，审计会追踪它。自行创建的标识符看似权威，但无法被检索，无法被聚合，且在下次运行时可能对同一观察使用不同名称。如果发现一个真实的、严重的问题，且未被上述两个来源覆盖，该发现仍然有效——将其放在“严重发现”下，不添加
rule_id
（行中不包含
```
`RULE_ID`
```
反引号标记）。仅严重问题符合此情况——未被规则覆盖的警告或信息类问题可忽略。上述两个来源仅针对Agent，因此此规则适用于Agent相关发现。在生成报告前，扫描所有引用的
rule_id
，确认其与加载的规则集文件或评审CLI输出完全一致；若不一致，则将其降级为无
rule_id
的发现。
根据规则为每个Agent项目评分——评分需推导得出，不得主观断言。对于Agent项目（第一阶段），为每个Agent及整体生成字母等级（
```
A
```
/
```
B
```
/
```
C
```
/
```
D
```
/
```
F
```
，无
```
+
```
/
```
-
```
），在步骤4.5中通过
```
min(G_det, G_jud)
```
计算得出。G_det从评审CLI的
Data.Grade
读取（步骤2.5a）——不得根据发现数量重新计算。G_jud由判断发现（步骤2.5b + 步骤3）根据严重程度数量计算得出。CLI发现已决定
```
Data.Grade
```
；仅判断发现会影响G_jud，因此每个发现仅属于一个子评分。显示每个评分的约束条件；未显示推导过程的评分无效（低代码报告可省略推导过程的打印）。安全或数据完整性相关的严重判断问题会直接导致F等级，无论设计质量如何（硬性关卡，而非综合评分）。技能评分始终≤
```
Data.Grade
```
（取最小值只会降低评分）——需同时报告两个评分，不得覆盖CLI评分。请勿为非Agent项目（RPA、流程、编码应用）评分——相关评分规则属于后续阶段。详见references/agents/agent-grading-rubric.md。
以下路径由CLI管理——
uip agent refresh
负责维护：
```
.agent-builder/
```
、
```
.local/build/
```
，以及（仅低代码）根目录下的
```
entry-points.json
```
（由
```
agent.json
```
生成）。请勿查看这些路径的内容。将它们排除在分类、源文件选择、结构指标和手动检查之外。仅当
```
refresh
```
无法修复这些路径的问题时，才提出发现——刷新前的不匹配是固有状态，不属于缺陷。从
```
agent.json
```
（
```
.inputSchema
```
/
```
.outputSchema
```
）读取低代码模式。

Review Workflow

评审流程

Step 0 — Discover, Scope, and Locate the PDD

步骤0 — 发现、确定范围并定位PDD

0a. Probe the Filesystem

0a. 探查文件系统

Run this from the directory the user specified (or the current working directory):

bash

undefined

从用户指定的目录（或当前工作目录）运行以下命令：

bash

undefined

Discover solution files, project markers, and documentation

发现解决方案文件、项目标记和文档

find . -maxdepth 3 ( -type d ( -name ".agent-builder" -o -path "/.local/build" ) ) -prune -o ( -name ".uipx" -o -name "project.json" -o -name "project.uiproj" -o -name "agent.json" -o -name ".flow" -o -name ".bpmn" -o -name "app.config.json" -o -name ".uipath" -o -name "pyproject.toml" -o -name "langgraph.json" -o -name "llama_index.json" -o -name "openai_agents.json" -o -name "uipath.json" -o -name "main.py" ) -print 2>/dev/null

Search for PDD or design documents

搜索PDD或设计文档

find . -maxdepth 3 ( -type d ( -name ".agent-builder" -o -path "*/.local/build" ) ) -prune -o ( -name "PDD" -o -name "pdd" -o -name "Process_Design" -o -name "process_design" -o -name "Process-Design" -o -name "ProcessDesign" -o -name "SDD" -o -name "Solution_Design" -o -name "design_document" -o -name "DesignDocument" -o -name "requirements" -o -name "specification" ) -print 2>/dev/null

undefined

undefined

0b. Locate the PDD (Process Design Document)

0b. 定位PDD（流程设计文档）

The PDD is the source of truth for the review. It defines what the automation should do, its business context, expected inputs/outputs, exception handling requirements, and success criteria. The review evaluates whether the implementation matches the PDD.

Search for PDD in this order:

Check common locations:
```
./docs/
```
,
```
./documentation/
```
,
```
./Design/
```
, project root

Check common names:

PDD.docx

PDD.pdf

PDD.md

Process_Design_Document.*

SDD.*

Solution_Design_Document.*

Requirements.*

Check AGENTS.md or README.md at project root — may contain or reference the PDD
Check project.json
```
description
```
field or any metadata pointing to documentation

If PDD is found:

Read it (supports .md, .pdf, .docx via appropriate tools)
Extract the key review criteria: business process description, expected inputs/outputs, exception handling requirements, SLAs, transaction definitions, queue specifications, application list, credential requirements
Use it as the primary benchmark for all subsequent review steps

If PDD is NOT found:

Use the

AskUserQuestion

tool to ask interactively:

Question: "I could not find a Process Design Document (PDD) in this project. Do you have one I can use as the source of truth for this review?"
Header: "PDD"
Options:
  1. Label: "Yes, I have a file"
     Description: "I'll provide a file path, URL, or Confluence/SharePoint link to the PDD, SDD, or requirements document"
  2. Label: "I'll paste the content"
     Description: "I'll copy/paste the PDD content (or key sections) directly into the chat"
  3. Label: "No, proceed without"
     Description: "Skip PDD alignment — review will cover technical quality and best practices only, not business logic verification"

If user selects "Yes, I have a file": they will provide the path in their response. Read the document and proceed with PDD-informed review.
If user selects "I'll paste the content": they will paste the PDD text (or relevant sections) in their next message. Use that content as the PDD for the review.
If user selects "No, proceed without": proceed without it — the review will focus on technical quality, best practices, and structural correctness, but cannot verify business logic alignment. Note this limitation in the report.

PDD是评审的唯一依据。它定义了自动化应实现的功能、业务上下文、预期输入/输出、异常处理要求和成功标准。评审需评估实现是否符合PDD。

按以下顺序搜索PDD：

检查常见位置：
```
./docs/
```
、
```
./documentation/
```
、
```
./Design/
```
、项目根目录

检查常见名称：

PDD.docx

、

PDD.pdf

、

PDD.md

、

Process_Design_Document.*

、

SDD.*

、

Solution_Design_Document.*

、

Requirements.*

检查项目根目录下的AGENTS.md或README.md——可能包含或引用PDD
检查project.json的
```
description
```
字段或任何指向文档的元数据

如果找到PDD：

读取文档（支持通过相应工具读取.md、.pdf、.docx格式）
提取关键评审标准：业务流程描述、预期输入/输出、异常处理要求、SLA、事务定义、队列规范、应用列表、凭证要求
将其作为所有后续评审步骤的主要基准

如果未找到PDD：

使用

AskUserQuestion

工具交互式询问：

问题："我在此项目中未找到流程设计文档（PDD）。是否可以提供一份作为评审的唯一依据？"
标题："PDD"
选项：
  1. 标签："是，我有文件"
     描述："我将提供PDD、SDD或需求文档的文件路径、URL或Confluence/SharePoint链接"
  2. 标签："我将粘贴内容"
     描述："我会直接将PDD内容（或关键部分）复制粘贴到聊天中"
  3. 标签："否，继续评审"
     描述："跳过PDD对齐检查——评审仅涵盖技术质量和最佳实践，不验证业务逻辑"

如果用户选择“是，我有文件”：用户会在回复中提供路径。读取文档并基于PDD进行评审。
如果用户选择“我将粘贴内容”：用户会在下一条消息中粘贴PDD文本（或相关部分）。将该内容作为PDD进行评审。
如果用户选择“否，继续评审”：继续评审，但评审将聚焦于技术质量、最佳实践和结构正确性，无法验证业务逻辑一致性。需在报告中注明此限制。

0c. Determine Review Scope

0c. 确定评审范围

Workflow labels like "Path A / Path B / Step 3a" are internal to this skill. NEVER use them in the final review report. The report must use user-facing language — see Step 5 for the required Review Scope vocabulary.

Classify the scope internally using these rules:

Scope: Solution or Multi-project —

.uipx

exists at root, OR 2+ executable project markers exist in different subdirectories.

Executable project =
```
project.json
```
with
```
outputType
```
of
```
Process
```
/
```
Tests
```
/unspecified, OR a low-code
```
agent.json
```
, OR a coded-agent Python project (
```
pyproject.toml
```
+ framework/
```
uipath.json
```
configuration), OR
```
.flow
```
, OR
```
project.uiproj
```
with
```
ProjectType
```
```
Flow
```
/
```
ProcessOrchestration
```
/
```
Api
```
Library projects (
```
outputType: "Library"
```
) co-located with consumers do NOT trigger this scope — that is the normal library+consumer pattern
Windows-Legacy executables do NOT trigger this scope for
.uipx
purposes:
```
.uipx
```
solutions are not supported for Legacy projects. If any detected executable is Legacy, do not flag missing
```
.uipx
```
— recommend migration to Modern compatibility if solution bundling is desired. Review each Legacy project independently.

Steps for Solution / Multi-project scope:

Read the
```
.uipx
```
file (if present) to enumerate all projects
Scan subdirectories for project markers not listed in
```
.uipx
```
(orphan executables)
Classify each project using the detection table in Step 1
Run solution-level checks: missing config.json, version mismatches, cross-project dependencies, circular dependencies
Build a solution map: every project with its type, path, and relationship to others
Cross-reference with PDD (if available)
Read references/solution-review-guide.md for the full procedure
Proceed to Step 1 for each project individually

Scope: Single Project — one

project.json

agent.json

.flow

/ coded-app marker, or one Python coded-agent project, at root; no

.uipx

, no executable siblings.

Classify the project using the detection table in Step 1
Cross-reference with PDD (if available)
Skip solution-level checks; go directly to Step 1

If the user pointed to a specific file (e.g.,

Main.xaml

), walk up to the enclosing project directory and review the full project.

“Path A / Path B / Step 3a”等流程标签仅为技能内部使用。绝不要在最终评审报告中使用这些标签。报告必须使用面向用户的语言——详见步骤5中要求的评审范围术语。

使用以下规则对范围进行内部分类：

范围：解决方案或多项目——根目录存在

.uipx

，或不同子目录中存在2个以上可执行项目标记。

可执行项目 =

project.json

的

outputType

为

Process

Tests

/未指定，或低代码

agent.json

，或编码Agent Python项目（

pyproject.toml

+ 框架/

uipath.json

配置），或

.flow

，或

project.uiproj

的

ProjectType

为

Flow

ProcessOrchestration

Api

与消费者共存的库项目（
```
outputType: "Library"
```
）不会触发此范围——这是正常的库+消费者模式
Windows-Legacy可执行文件不会触发
.uipx
相关的此范围：
```
.uipx
```
解决方案不支持Legacy项目。如果检测到任何可执行文件为Legacy类型，请勿标记缺少
```
.uipx
```
——如果需要解决方案打包，建议迁移到Modern兼容版本。独立评审每个Legacy项目。

解决方案/多项目范围的步骤：

读取
```
.uipx
```
文件（如果存在）以枚举所有项目
扫描子目录，查找未在
```
.uipx
```
中列出的项目标记（孤立可执行项目）
使用步骤1中的检测表对每个项目进行分类
运行解决方案级检查：缺少config.json、版本不匹配、跨项目依赖、循环依赖
构建解决方案映射：每个项目的类型、路径及与其他项目的关系
与PDD交叉验证（如果可用）
阅读references/solution-review-guide.md获取完整流程
对每个项目执行步骤1

范围：单个项目——根目录存在一个

project.json

agent.json

.flow

/编码应用标记，或一个Python编码Agent项目；无

.uipx

，无同级可执行项目。

使用步骤1中的检测表对项目进行分类
与PDD交叉验证（如果可用）
跳过解决方案级检查，直接进入步骤1

如果用户指向特定文件（例如

Main.xaml

），向上遍历到包含该文件的项目目录，评审整个项目。

Step 1 — Classify the Project Type and Capture Language

步骤1 — 分类项目类型并记录语言

For each project discovered (one for single-project scope, multiple for solution/multi-project scope), determine its type AND capture its expression language.

Step 1a — Read
expressionLanguage
from
project.json
for every RPA project. This is mandatory. The value (

VisualBasic

CSharp

) affects everything downstream: expression syntax in If/Switch conditions, null checks, type checks (

TypeOf x Is T

in VB vs

x is T

in C#), string operations, LINQ syntax, and naming conventions. All subsequent inspection steps (especially Step 3a Unit of Work grep and expression-dependent checks) MUST adapt patterns to the project's language. Do not assume VB.

Record the language per project alongside the type (see solution table below).

Step 1b — Determine project type using the detection table:

Filesystem Signal	Project Type	Review Checklist
`project.json` + `.cs` files with `[Workflow]` attributes	RPA (Coded)	rpa-review-checklist.md
`project.json` + `.xaml` workflow files	RPA (XAML)	rpa-review-checklist.md
`project.json` with no `targetFramework` or `targetFramework: "Legacy"` (any expression language — Legacy C# exists)	RPA (Windows-Legacy)	rpa-review-checklist.md §10. Also recommend the user invoke `uipath-rpa` (Legacy mode) for Legacy-specific deep validation. Legacy is supported indefinitely in Studio LTS — do NOT flag as Critical.
`project.json` + both `.cs` and `.xaml`	RPA (Hybrid)	rpa-review-checklist.md
`project.json` + `.xaml` + DU packages in dependencies ( `UiPath.IntelligentOCR.Activities` , `UiPath.DocumentUnderstanding.ML.Activities` )	RPA + Document Understanding	rpa-review-checklist.md + du-review-checklist.md
`agent.json` with `"type": "lowCode"`	Agent (Low-Code)	Rule catalog (Step 2.5): agents-lowcode-rules.md
Python coded-agent project, including `agent.json` with `"type": "coded"` when present	Agent (Coded)	Rule catalog (Step 2.5): agents-coded-rules.md
`*.flow` + `project.uiproj` with `"ProjectType": "Flow"`	Flow	flow-review-checklist.md
`*.bpmn` + `project.uiproj` with `"ProjectType": "ProcessOrchestration"`	Maestro BPMN	bpmn-review-checklist.md
`Workflow.json` ( `document.dsl` + `do[]` ) + `project.uiproj` with `"ProjectType": "Api"`	API Workflow	api-workflow-review-checklist.md
`.uipath/` directory or `app.config.json`	Coded App	coded-app-review-checklist.md

For Solution / Multi-project scope, record all projects in a table:

markdown

| # | Project Path | Type | Language | Entry Points |
|---|---|---|---|---|
| 1 | ./InvoiceProcessor/ | RPA (XAML) | VisualBasic | Main.xaml, Helper.xaml |
| 2 | ./Dispatcher/ | RPA (Coded) | CSharp | Main.cs |
| 3 | ./ClassifierAgent/ | Agent (Coded) | Python | main.py |
| 4 | ./Orchestration.flow | Flow | — | — |

Step 1c — Inventory the authored files for every project you will review. Run this instead of writing your own

find

, to avoid listing runtime artifacts:

bash

find "<PROJECT_DIR>" \( -type d \( -name ".agent-builder" -o -path "*/.local/build" -o -name "node_modules" -o -name ".venv" -o -name "obj" -o -name "bin" \) \) -prune -o -type f -print 2>/dev/null | sort

The result is the authored-file set for Steps 2.5 and 3. Any path absent from it is out of scope: do not read it, cite it, or name it anywhere in your output.

对于每个发现的项目（单个项目范围为1个，解决方案/多项目范围为多个），确定其类型并记录其表达式语言。

步骤1a — 读取每个RPA项目的
project.json
中的
expressionLanguage
。此步骤为必填项。该值（

VisualBasic

或

CSharp

）会影响后续所有操作：If/Switch条件中的表达式语法、空值检查、类型检查（VB中为

TypeOf x Is T

，C#中为

x is T

）、字符串操作、LINQ语法和命名约定。所有后续检查步骤（尤其是步骤3a的工作单元搜索和依赖表达式的检查）必须适配项目的语言。请勿默认使用VB。

记录每个项目的语言和类型（见下方解决方案表格）。

步骤1b — 使用检测表确定项目类型：

文件系统信号	项目类型	评审清单
`project.json` + 带有 `[Workflow]` 属性的 `.cs` 文件	RPA（编码）	rpa-review-checklist.md
`project.json` + `.xaml` 工作流文件	RPA（XAML）	rpa-review-checklist.md
`project.json` 无 `targetFramework` 或 `targetFramework: "Legacy"` （任何表达式语言——存在Legacy C#）	RPA（Windows-Legacy）	rpa-review-checklist.md §10。同时建议用户调用 `uipath-rpa` （Legacy模式）进行Legacy专属深度验证。Legacy在Studio LTS中永久支持——请勿标记为严重问题。
`project.json` + 同时存在 `.cs` 和 `.xaml`	RPA（混合）	rpa-review-checklist.md
`project.json` + `.xaml` + 依赖项中包含DU包（ `UiPath.IntelligentOCR.Activities` 、 `UiPath.DocumentUnderstanding.ML.Activities` ）	RPA + 文档理解	rpa-review-checklist.md + du-review-checklist.md
`agent.json` 的 `"type": "lowCode"`	Agent（低代码）	规则集（步骤2.5）：agents-lowcode-rules.md
Python编码Agent项目，包括存在 `"type": "coded"` 的 `agent.json`	Agent（编码）	规则集（步骤2.5）：agents-coded-rules.md
`*.flow` + `project.uiproj` 的 `"ProjectType": "Flow"`	流程	flow-review-checklist.md
`*.bpmn` + `project.uiproj` 的 `"ProjectType": "ProcessOrchestration"`	Maestro BPMN	bpmn-review-checklist.md
`Workflow.json` （ `document.dsl` + `do[]` ） + `project.uiproj` 的 `"ProjectType": "Api"`	API工作流	api-workflow-review-checklist.md
`.uipath/` 目录或 `app.config.json`	编码应用	coded-app-review-checklist.md

对于解决方案/多项目范围，将所有项目记录在表格中：

markdown

| # | 项目路径 | 类型 | 语言 | 入口点 |
|---|---|---|---|---|
| 1 | ./InvoiceProcessor/ | RPA（XAML） | VisualBasic | Main.xaml, Helper.xaml |
| 2 | ./Dispatcher/ | RPA（编码） | CSharp | Main.cs |
| 3 | ./ClassifierAgent/ | Agent（编码） | Python | main.py |
| 4 | ./Orchestration.flow | 流程 | — | — |

步骤1c — 盘点每个待评审项目的手写文件。运行以下命令，避免列出运行时工件：

bash

find "<PROJECT_DIR>" \( -type d \( -name ".agent-builder" -o -path "*/.local/build" -o -name "node_modules" -o -name ".venv" -o -name "obj" -o -name "bin" \) \) -prune -o -type f -print 2>/dev/null | sort

结果为步骤2.5和步骤3的手写文件集。不在此集合中的路径超出范围：请勿读取、引用或在输出中提及。

Step 2 — Run Automated Validation and Workflow Analyzer

步骤2 — 运行自动化验证与Workflow Analyzer

This step is mandatory and non-negotiable. You MUST run validation commands yourself (via Bash) before doing any manual review.

Solution / Multi-project scope: Run validation on every project in the solution. For each RPA project, validate every entry point file.
Single Project scope: Run validation on the single project. For RPA projects, validate every entry point file.

Account for all results in the final review report: Error / Warning / Info counts in the validation table, plus a detail line per Error and Warning (Step 2d).

此步骤必须执行，且不可协商。在进行任何手动评审前，必须自行（通过Bash）运行验证命令。

解决方案/多项目范围：对解决方案中的每个项目运行验证。对于每个RPA项目，验证每个入口点文件。
单个项目范围：对单个项目运行验证。对于RPA项目，验证每个入口点文件。

在最终评审报告中记录所有结果：验证表格中的错误/警告/信息数量，以及每个错误和警告的详细说明（步骤2d）。

2a. RPA Projects — Validate Every Entry Point

2a. RPA项目 — 验证每个入口点

Read
```
project.json
```
→ extract the
```
entryPoints
```
array
For each entry point file, run validation yourself:

bash

uip rpa validate --file-path "<ENTRY_FILE>" --project-dir "<PROJECT_DIR>" --output json

Then run a project-level build to catch what
```
validate
```
misses (unknown member names like
```
NGetText.Value
```
, invalid enum values like
```
Operator="StartsWith"
```
, member resolution / CacheMetadata failures, attribute-form C# expression JIT failures):

bash

uip rpa build "<PROJECT_DIR>" --log-level Warn --output json

Collect all results from both commands — Errors, Warnings, and Info-level messages (Info feeds the table's count; it gets no detail line)
If any entry point has
```
validate
```
errors or the project fails to
```
build
```
, the project is not deployable

Do NOT validate only Main.xaml — validate every file listed in
entryPoints
. A project can have multiple entry points and errors in any of them block deployment.

Do NOT report a clean review based on
validate
alone.
validate
is static analysis; it does not catch unknown member names or invalid enum values. A "0 errors"
validate
result with a failing
build
is a real bug that ships if the reviewer skips
build
.

读取
```
project.json
```
→ 提取
```
entryPoints
```
数组
对每个入口点文件自行运行验证：

bash

uip rpa validate --file-path "<ENTRY_FILE>" --project-dir "<PROJECT_DIR>" --output json

然后运行项目级构建，捕获
```
validate
```
遗漏的问题（未知成员名称如
```
NGetText.Value
```
、无效枚举值如
```
Operator="StartsWith"
```
、成员解析/CacheMetadata失败、属性形式的C#表达式JIT失败）：

bash

uip rpa build "<PROJECT_DIR>" --log-level Warn --output json

收集两个命令的所有结果——错误、警告和信息级消息（信息用于表格计数；无需详细说明）
如果任何入口点存在
```
validate
```
错误或项目构建失败，则该项目不可部署

请勿仅验证Main.xaml——需验证
entryPoints
中列出的所有文件。一个项目可能有多个入口点，任何一个入口点的错误都会阻碍部署。

请勿仅基于
validate
结果报告评审无问题。
validate
是静态分析，无法捕获未知成员名称或无效枚举值。
validate
显示“0错误”但构建失败的情况是真实存在的bug，如果评审者跳过
build
，该bug会被部署到生产环境。

2b. RPA Projects — Run Workflow Analyzer

2b. RPA项目 — 运行Workflow Analyzer

The Workflow Analyzer checks code quality rules (ST-NMG naming, ST-DBP design, ST-MRD maintainability, ST-USG usage, ST-SEC security, ST-REL reliability). Run it explicitly:

bash

uip rpa analyze --project-dir "<PROJECT_DIR>" --output json

uip rpa analyze

is not available,

uip rpa validate

includes Workflow Analyzer results. Check the output for all rule violations:

Error-level violations → report as Critical findings (e.g., ST-SEC-007 SecureString, ST-ANA-005 missing project.json)
Warning-level violations → report as Warning findings (e.g., ST-DBP-003 empty Catch, ST-MRD-011 Write Line usage, ST-NMG-001 naming)
Info-level violations → report as Info findings (e.g., ST-ANA-003 workflow count, ST-ANA-009 file activity stats)

Every Workflow Analyzer violation must appear in the review report with its rule ID, affected file, and description. Do not silently skip any severity level.

Workflow Analyzer检查代码质量规则（ST-NMG命名、ST-DBP设计、ST-MRD可维护性、ST-USG使用、ST-SEC安全、ST-REL可靠性）。显式运行：

bash

uip rpa analyze --project-dir "<PROJECT_DIR>" --output json

如果

uip rpa analyze

不可用，

uip rpa validate

会包含Workflow Analyzer结果。检查输出中的所有规则违规：

错误级违规 → 报告为严重发现（例如ST-SEC-007 SecureString、ST-ANA-005缺少project.json）
警告级违规 → 报告为警告发现（例如ST-DBP-003空Catch块、ST-MRD-011使用Write Line、ST-NMG-001命名问题）
信息级违规 → 报告为信息发现（例如ST-ANA-003工作流数量、ST-ANA-009文件活动统计）

每个Workflow Analyzer违规必须出现在评审报告中，包含规则ID、受影响文件和描述。请勿静默跳过任何严重程度的违规。

2c. Other Project Types

2c. 其他项目类型

Project Type	Validation Command	Report All Severities
Agent (Low-Code)	`uip agent refresh "<PROJECT_DIR>" --output json` , then `uip agent validate "<PROJECT_DIR>" --output json`	Yes — errors, warnings, info
Flow	`uip maestro flow validate "<PROJECT_NAME>.flow" --output json`	Yes — schema errors, reference errors, warnings
Maestro BPMN	`uip maestro bpmn validate "<FILE>.bpmn" --output json`	Yes — model errors, warnings
API Workflow	`uip api-workflow validate "<WORKFLOW_JSON>" --output json`	Yes — schema + semantic errors, warnings
Coded App	`uip codedapp pack dist --dry-run --output json`	Yes — build errors, pack warnings
Solution	`uip solution pack "<SOLUTION_DIR>" "<OUTPUT_DIR>" --output json`	Yes — per-project pack results

uip api-workflow validate
is offline (no auth, no network, no side effects). Do NOT run
uip api-workflow run
— it executes vendor calls with real side effects. If the CLI reports an unknown command for
maestro bpmn validate
or
api-workflow validate
(older CLI), record it under "Rules Skipped" and fall back to the manual structural checks in the type's checklist.

项目类型	验证命令	报告所有严重程度
Agent（低代码）	`uip agent refresh "<PROJECT_DIR>" --output json` ，然后 `uip agent validate "<PROJECT_DIR>" --output json`	是——错误、警告、信息
流程	`uip maestro flow validate "<PROJECT_NAME>.flow" --output json`	是——模式错误、引用错误、警告
Maestro BPMN	`uip maestro bpmn validate "<FILE>.bpmn" --output json`	是——模型错误、警告
API工作流	`uip api-workflow validate "<WORKFLOW_JSON>" --output json`	是——模式+语义错误、警告
编码应用	`uip codedapp pack dist --dry-run --output json`	是——构建错误、打包警告
解决方案	`uip solution pack "<SOLUTION_DIR>" "<OUTPUT_DIR>" --output json`	是——每个项目的打包结果

uip api-workflow validate
为离线操作（无需认证、无网络、无副作用）。请勿运行
uip api-workflow run
——它会执行带有真实副作用的供应商调用。如果CLI报告
maestro bpmn validate
或
api-workflow validate
为未知命令（旧版CLI），将其记录在“跳过的规则”下，并回退到该类型清单中的手动结构检查。

2d. Record All Results

2d. 记录所有结果

For the review report, create a validation summary:

markdown

undefined

为评审报告创建验证摘要：

markdown

undefined

Validation Results

验证结果

Project	Command	Errors	Warnings	Info
InvoiceProcessor	uip rpa validate (Main.xaml)	0	3	1
InvoiceProcessor	uip rpa validate (Helper.cs)	1	0	0
InvoiceDispatcher	uip maestro flow validate	0	0	0
ClassifierAgent	uip agent validate	0	1	0

项目	命令	错误	警告	信息
InvoiceProcessor	uip rpa validate (Main.xaml)	0	3	1
InvoiceProcessor	uip rpa validate (Helper.cs)	1	0	0
InvoiceDispatcher	uip maestro flow validate	0	0	0
ClassifierAgent	uip agent validate	0	1	0

Validation Details

验证详情

[E-001] InvoiceProcessor/Helper.cs: ST-SEC-007 — Password argument uses String instead of SecureString
[W-001] InvoiceProcessor/Main.xaml: ST-MRD-011 — Write Line activity used (use Log Message instead)
[W-002] InvoiceProcessor/Main.xaml: ST-DBP-003 — Empty Catch block in TryCatch_1
[W-003] InvoiceProcessor/Main.xaml: ST-NMG-001 — Variable 'temp_val' does not match naming convention
[W-004] ClassifierAgent: Missing tool description for 'lookup_customer'


> The validation results section is **required** in every review report. A review without automated validation is incomplete.

**Counts in the table; detail lines for Errors and Warnings only.** Every command's Error / Warning / Info counts go in the table — that is where Info is reported. Write a detail line only for an Error or a Warning. Never write a detail line that narrates a clean or successful result (`Status: Valid`, `Verdict: PASS`, `Score: 100`, "no drift", "0 issues", "N files regenerated", "already at schema X") — the `0` in the table already says it, and the Info column already carries the count.

[E-001] InvoiceProcessor/Helper.cs: ST-SEC-007 — Password参数使用String而非SecureString
[W-001] InvoiceProcessor/Main.xaml: ST-MRD-011 — 使用了Write Line活动（建议使用Log Message）
[W-002] InvoiceProcessor/Main.xaml: ST-DBP-003 — TryCatch_1中存在空Catch块
[W-003] InvoiceProcessor/Main.xaml: ST-NMG-001 — 变量'temp_val'不符合命名规范
[W-004] ClassifierAgent: 'lookup_customer'工具缺少描述


> 验证结果部分**必须**出现在每个评审报告中。未进行自动化验证的评审是不完整的。

**表格中记录数量；仅为错误和警告添加详细说明**。每个命令的错误/警告/信息数量都要放入表格——信息在此处报告。仅为错误或警告添加详细说明。请勿为无问题或成功的结果添加详细说明（如`Status: Valid`、`Verdict: PASS`、`Score: 100`、“无偏差”、“0问题”、“N个文件已重新生成”、“已符合模式X”）——表格中的`0`已说明情况，信息列已包含计数。

Step 2.5 — Run the Review CLI, then Apply the Judgment Catalog

步骤2.5 — 运行评审CLI，然后应用判断规则集

After Step 2 validation and before manual checklist review, produce rule-ID-level findings in two passes: first the

uip agent review

uip codedagent review

CLI for the deterministic static checks, then the skill's judgment-only catalog for what code cannot decide reliably.

Late invocation: if a review was already performed or started before this skill loaded, do NOT skip 2.5a/2.5b as "already covered" — no other review flow runs the review CLI or fetches the live guardrail catalog. Run both passes, then fold prior findings into Step 5's report.

完成步骤2的验证后，在手动清单评审前，通过两个步骤生成规则ID级发现：首先运行

uip agent review

uip codedagent review

CLI进行确定性静态检查，然后使用技能的判断规则集处理代码无法可靠判断的问题。

延迟调用：如果在技能加载前已执行或开始评审，请勿以“已覆盖”为由跳过2.5a/2.5b——其他评审流程不会运行评审CLI或获取实时规则集。运行两个步骤，然后将之前的发现合并到步骤5的报告中。

2.5a — Run the review CLI first (deterministic findings)

2.5a — 先运行评审CLI（确定性发现）

Run the review command for the agent type, once, capturing JSON:

Agent type	Command
Low-code	`uip agent review "<PROJECT_DIR>" --output json`
Coded	`uip codedagent review "<PROJECT_DIR>" --output json`

The CLI runs the deterministic static checks its registry ships — structural/schema gates, placeholder cross-refs, eval-set structure and schema cross-refs, guardrail configuration validity, tool count, prompt length/platform — and returns them in rule format. Parse

Data.Issues[]

; each issue is

{RuleId, Category, Severity, Description, File, SuggestedFix}

. Carry each into the report verbatim — do not re-derive, rename, or re-rank. These rule IDs are authoritative as emitted by the CLI; they are not listed in the skill catalog.

Guardrail configuration is CLI-only — never eyeball it. Whether a guardrail is well-formed (real validator, allowed scope, required/typed/legal parameters, valid custom-rule shape) is decided only by
uip agent review
— the
GUARDRAIL_*
and
GUARDRAIL_CUSTOM_*
rule IDs come from this command, never from reading
agent.json
by eye and never from the judgment catalog. So whenever the task involves checking / validating / diagnosing / fixing a guardrail, running the review CLI in this step is mandatory (use
--checks guardrails
if you only need the guardrail pass), and every
GUARDRAIL_*
finding it returns must appear verbatim in the report's findings tables — do not replace it with a hand-written description of the problem. (The judgment catalog's
LC_GUARDRAIL_*
rules are the complement: they audit only guardrails the CLI found format-valid and recommend missing ones at Info — see Step 2.5b and
references/agents/guardrails/guardrails-review.md
.)

针对Agent类型运行评审命令一次，捕获JSON结果：

Agent类型	命令
低代码	`uip agent review "<PROJECT_DIR>" --output json`
编码	`uip codedagent review "<PROJECT_DIR>" --output json`

CLI运行其注册的确定性静态检查——结构/模式关卡、占位符交叉引用、评估集结构和模式交叉引用、防护配置有效性、工具数量、提示长度/平台——并以规则格式返回结果。解析

Data.Issues[]

；每个问题为

{RuleId, Category, Severity, Description, File, SuggestedFix}

。将每个问题原样带入报告——请勿重新推导、重命名或重新评级。这些规则ID由CLI生成，具有权威性；不会出现在技能规则集中。

防护配置仅由CLI检查——绝不手动检查。防护配置是否格式正确（真实验证器、允许的范围、必填/类型化/合法参数、有效的自定义规则格式）仅由
uip agent review
决定——
GUARDRAIL_*
和
GUARDRAIL_CUSTOM_*
规则ID来自此命令，绝不来自手动读取
agent.json
或判断规则集。因此，每当任务涉及检查/验证/诊断/修复防护配置时，此步骤中运行评审CLI是必须的（如果仅需检查防护配置，可使用
--checks guardrails
参数），且其返回的每个
GUARDRAIL_*
发现必须原样出现在报告的发现表格中——请勿用手写的问题描述替代。（判断规则集的
LC_GUARDRAIL_*
规则是补充：仅审计CLI判定格式有效的防护配置，并建议添加缺失的防护配置，级别为信息——详见步骤2.5b和
references/agents/guardrails/guardrails-review.md
。）

2.5b — Apply the judgment catalog (reasoning the CLI cannot do)

2.5b — 应用判断规则集（CLI无法完成的推理）

Identify which catalog files apply for the current project type:

Signals present	Project type	Catalog files
`agent.json.type == "lowCode"`	Agent (low-code)	`references/agents/agents-lowcode-rules.md`
Python coded-agent signals or `agent.json.type == "coded"`	Agent (coded)	`references/agents/agents-coded-rules.md`
`pyproject.toml` + `main.py` + `uipath.json[functions]` only (no framework config)	Agent (coded — Simple Function)	same as Agent (coded)
`project.json` + `.xaml` / `.cs`	RPA	(phase 2)
`*.flow`	Flow	(phase 2)
`.uipath/` or `app.config.json`	Coded App	(phase 2)

Read each catalog file in full. Every rule is judgment-form.
Guardrails — apply the structured guardrail workflow (project-type specific; Step 0 fetches the authored
```
uip agent guardrails catalog
```
— 30-min cache — plus the never-cached tenant-availability
```
uip agent guardrails list
```
→ Audit Mode for existing guardrails + Recommend Mode for missing ones):
- Low-code (
```
agent.json
```
  ): when
```
guardrails[]
```
  is non-empty or the agent matches a guardrail use case, apply
```
references/agents/guardrails/guardrails-review.md
```
  . Emits
```
LC_GUARDRAIL_ACTION_INEFFECTIVE
```
  /
```
LC_GUARDRAIL_MISAPPLIED
```
  (defects,
```
judgment
```
  band) and
```
LC_GUARDRAIL_RECOMMENDED
```
  (Info, one per missing guardrail).
- Coded (SDK middleware /
```
@guardrail
```
  decorators wired in the entry
```
.py
```
  ): when the entry source wires guardrails or the agent matches a use case, apply
```
references/agents/guardrails/coded-guardrails-review.md
```
  (its Step 0 fetches the public Python SDK docs only when a finding must name Python classes not already visible in the agent source). Emits
```
CODED_GUARDRAIL_ACTION_INEFFECTIVE
```
  /
```
CODED_GUARDRAIL_MISAPPLIED
```
  (defects,
```
judgment
```
  band) and
```
CODED_GUARDRAIL_RECOMMENDED
```
  (Info). The CLI's deterministic
```
CODED_GUARDRAIL_WRONG_IMPORT
```
  /
```
CODED_GUARDRAIL_TOOL_SCOPE_NO_TOOLS
```
  /
```
CODED_GUARDRAIL_INVALID_CONTRACT
```
  (Step 2.5a) are carried verbatim and not re-flagged here.
- Either way, if the guardrail catalog is unavailable, record the Audit-Mode rules under "Rules Skipped" and keep Recommend Mode's source-only detection.
Apply each rule's
detection_method
: read the named source material (system prompt, tool descriptions, eval datapoints, schemas) and reason about it. Emit a finding when the criteria hold; log the reasoning in the finding's
```
description
```
.
Track skipped rules with their reason (
```
status: deferred
```
, missing optional file, review CLI unavailable). Never silently skip.
Verify rule_id provenance. Before merging, confirm each cited
```
rule_id
```
appears verbatim in EITHER a loaded catalog file OR the
```
uip agent review
```
/
```
uip codedagent review
```
JSON output. Any finding whose
```
rule_id
```
matches neither is demoted to a
```
rule_id
```
-less Critical (the observation stays; the false citation goes) — or dropped when it is a Warning or Info. This enforces Critical Rule 12.
Merge findings into the Step 5 report — into the Critical / Warning / Info findings tables, one row per finding:
```
| <id> | `<rule_id>` | `<file>`: <issue>. <fix>. |
```
where prefix is
```
C-D-
```
(Critical),
```
W-D-
```
(Warning), or
```
I-D-
```
(Info) per the severity mapping in
```
references/rule-format.md
```
.

See

references/rule-catalog-workflow.md

for the full procedure including the CLI contract and determinism rules.

确定适用的规则集文件：

存在的信号	项目类型	规则集文件
`agent.json.type == "lowCode"`	Agent（低代码）	`references/agents/agents-lowcode-rules.md`
存在Python编码Agent信号或 `agent.json.type == "coded"`	Agent（编码）	`references/agents/agents-coded-rules.md`
仅存在 `pyproject.toml` + `main.py` + `uipath.json[functions]` （无框架配置）	Agent（编码——简单函数）	与Agent（编码）相同
`project.json` + `.xaml` / `.cs`	RPA	(第二阶段)
`*.flow`	流程	(第二阶段)
`.uipath/` 或 `app.config.json`	编码应用	(第二阶段)

完整读取每个规则集文件。每个规则均为判断形式。
防护配置——应用结构化防护流程（针对特定项目类型；步骤0获取手写的
```
uip agent guardrails catalog
```
——缓存30分钟——以及永不缓存的租户可用
```
uip agent guardrails list
```
→ 审计模式用于现有防护配置 + 推荐模式用于缺失的防护配置）：
- 低代码（
```
agent.json
```
  ）：当
```
guardrails[]
```
  非空或Agent匹配防护配置用例时，应用
```
references/agents/guardrails/guardrails-review.md
```
  。生成
```
LC_GUARDRAIL_ACTION_INEFFECTIVE
```
  /
```
LC_GUARDRAIL_MISAPPLIED
```
  （缺陷，
```
judgment
```
  级别）和
```
LC_GUARDRAIL_RECOMMENDED
```
  （信息，每个缺失的防护配置对应一条）。
- 编码（SDK中间件/入口
```
.py
```
  中的
```
@guardrail
```
  装饰器）：当入口源码使用防护配置或Agent匹配用例时，应用
```
references/agents/guardrails/coded-guardrails-review.md
```
  （其步骤0仅在发现必须提及Agent源码中未显示的Python类时，才会获取公共Python SDK文档）。生成
```
CODED_GUARDRAIL_ACTION_INEFFECTIVE
```
  /
```
CODED_GUARDRAIL_MISAPPLIED
```
  （缺陷，
```
judgment
```
  级别）和
```
CODED_GUARDRAIL_RECOMMENDED
```
  （信息）。CLI的确定性
```
CODED_GUARDRAIL_WRONG_IMPORT
```
  /
```
CODED_GUARDRAIL_TOOL_SCOPE_NO_TOOLS
```
  /
```
CODED_GUARDRAIL_INVALID_CONTRACT
```
  （步骤2.5a）需原样带入报告，不会在此处重新标记。
- 无论哪种情况，如果防护配置规则集不可用，将审计模式规则记录在“跳过的规则”下，并保留推荐模式的源码检测。
应用每个规则的
detection_method
：读取指定的源材料（系统提示、工具描述、评估数据点、模式）并进行推理。当符合条件时生成发现；将推理过程记录在发现的
```
description
```
中。
跟踪跳过的规则及其原因（
```
status: deferred
```
、缺少可选文件、评审CLI不可用）。绝不静默跳过。
验证rule_id来源。合并前，确认每个引用的
```
rule_id
```
完全匹配加载的规则集文件或
```
uip agent review
```
/
```
uip codedagent review
```
的JSON输出中的内容。任何
```
rule_id
```
不匹配的发现需降级为无
```
rule_id
```
的严重发现（保留观察结果，移除错误引用）——如果是警告或信息类发现，则直接忽略。此操作执行核心规则12。
将发现合并到步骤5的报告中——放入严重/警告/信息发现表格，每个发现一行：
```
| <id> | `<rule_id>` | `<file>`: <问题>. <修复方案>. |
```
前缀根据
```
references/rule-format.md
```
中的严重程度映射为
```
C-D-
```
（严重）、
```
W-D-
```
（警告）或
```
I-D-
```
（信息）。

详见

references/rule-catalog-workflow.md

获取完整流程，包括CLI契约和确定性规则。

Step 3 — Manual Quality Review

步骤3 — 手动质量评审

For each project (one for single-project, all for solution/multi-project), load the relevant checklist from

references/

based on the type classified in Step 1. Read project files, check patterns, evaluate design.

对于每个项目（单个项目范围为1个，解决方案/多项目范围为所有项目），根据步骤1分类的类型，从

references/

加载相关清单。读取项目文件，检查模式，评估设计。

3a. Unit of Work Discovery (mandatory, generic)

3a. 工作单元发现（必填，通用）

Every project has two units of work: what the contract declares one invocation represents, and what the execution body actually does. A mismatch is a Critical-to-Warning finding regardless of project type. Do not ask the user — derive both mechanically from the project.

Step 3a.1 — Discover the declared unit of work (per project type):

Project type	Where the declared unit lives
RPA + queue	Queue item schema ( `Data/*.json` , `JSON Schema/` , or the SpecificContent fields used by `Add Queue Item` / `Get Transaction Item` )
RPA without queue	`Main.xaml` input arguments
Flow	`.flow` file → `variables.globals` → entries with `direction: "in"` or `"inout"`
Maestro BPMN	Process start-event payload / process input variables
Agent (low-code)	`agent.json` → `inputSchema`
Agent (coded)	`Input` class in `main.py` (Pydantic `BaseModel` )
API workflow	Request input schema in `Workflow.json`
Coded app	Entry point input schema in `operate.json` / `entry-points.json`

Step 3a.2 — Discover the actual unit of work (core execution body):

Identify the core execution file (

ProcessTransaction.xaml

Process.xaml

Main.xaml

main.py

, flow body, API handler) then run these mechanical checks:

bash

undefined

每个项目有两个工作单元：契约声明的单次调用代表的内容，以及执行体实际执行的内容。无论项目类型如何，两者不匹配均为严重到警告级别的发现。请勿询问用户——需从项目中机械推导两者。

步骤3a.1 — 发现声明的工作单元（按项目类型）：

项目类型	声明的工作单元位置
RPA + 队列	队列项模式（ `Data/*.json` 、 `JSON Schema/` 或 `Add Queue Item` / `Get Transaction Item` 使用的SpecificContent字段）
无队列的RPA	`Main.xaml` 输入参数
流程	`.flow` 文件 → `variables.globals` → `direction: "in"` 或 `"inout"` 的条目
Maestro BPMN	流程开始事件负载/流程输入变量
Agent（低代码）	`agent.json` → `inputSchema`
Agent（编码）	`main.py` 中的 `Input` 类（Pydantic `BaseModel` ）
API工作流	`Workflow.json` 中的请求输入模式
编码应用	`operate.json` / `entry-points.json` 中的入口点输入模式

步骤3a.2 — 发现实际的工作单元（核心执行体）：

确定核心执行文件（

ProcessTransaction.xaml

、

Process.xaml

、

Main.xaml

、

main.py

、流程体、API处理程序），然后运行以下机械检查：

bash

undefined

Detect iteration inside the execution body

检测执行体中的循环

grep -n 'ForEach|While' <EXECUTION_FILE>

Detect external-effect activities (writes, API calls, queue pushes, workflow invocations)

检测有外部影响的活动（写入、API调用、队列推送、工作流调用）


For coded projects, look for `for` / `foreach` / `while` statements and external I/O calls.

**Step 3a.3 — Classify using this matrix:**

Classify the **Transaction Shape** using this matrix. Shape is a neutral description of the relationship between input and external effects — it is NOT a pass/fail verdict.

| Actual execution pattern | Transaction Shape |
|---|---|
| One invocation → one atomic external state change (one write, one submission, one workflow call) | **One-to-one** |
| Execution iterates over an array/collection field of the declared input, and the loop body contains external effects (see list below) | **One-to-many** |
| Iteration only over retry counters, UI element enumeration, or pure in-memory transformations (no external effects in loop body) | **One-to-one** (in-memory iteration is intra-unit; not a sub-unit of work) |
| No iteration at all | **One-to-one** |
| Contract or execution cannot be deterministically mapped (schema missing/unclear, dynamic dispatch) | **Unclear** |

**External effects inside a loop body that make it one-to-many** (none of these are defeated by session scope, shared credentials, single portal, or business-model arguments):

- `InvokeWorkflowFile` / `Invoke Method` to workflows with external side effects
- HTTP activities (`HTTP Request`, connector activities, REST calls)
- Queue operations (`Add Queue Item`, `Set Transaction Progress`, `Set Transaction Status`)
- Database writes (`Execute Non Query`, `Insert Data Table`, `Bulk Insert`)
- File writes outside `Temp/` directories (`Write Range`, `Write CSV`, `Append to File`)
- UI activities that modify target-system state (Click on submit/save, Type Into fields that persist, SAP `Call Transaction`)
- Email send activities

Classification is mechanical. It does not change based on:
- "The portal models this as one transaction" (UX framing ≠ atomicity)
- "One browser session" (session ≠ transaction)
- "Idempotency guards exist so it's fine" (guards are a remediation signal, not a reclassifier)
- "The PDD calls it one transaction" (declared intent ≠ execution reality)
- "The queue only has one item" (queue is the declared unit; actual unit is what gets written)

**Step 3a.4 — Record shape, then separately assess remediation.**

The shape itself is reported neutrally. Whether it becomes a finding — and at what severity — depends on remediation posture:

**For One-to-one:** No finding. Report the shape observation in Summary, move on.

**For One-to-many:** Assess two separate questions.

*Question A — Can the sub-units be independently queued / split?*
- Yes: the proper fix is dispatcher/performer — split the queue so each sub-unit is an atomic transaction. Use this when sub-units are independent (one invoice, one employee record, one order, one file).
- No: the domain forces a sequential session-bound submission (SAP new-plan enrollment, carrier portal group application, bank multi-step wire). Queue splitting is infeasible. The fix is not architectural — it is operational: verify atomicity, error handling, crash recovery, and progress tracking using the **10-point hardening checklist** in [rpa-common-issues.md](references/rpa/rpa-common-issues.md) → "When it cannot be split — hardening checklist." Each missing safeguard is a separate finding.

*Question B — What partial-failure recovery exists today?*

Look for any of these patterns (semantically, not by filename):

| Pattern | Detection |
|---|---|
| Read-check-before-write before each sub-unit write | Inspect activity sequence in the loop body |
| Conditional skip based on "already exists/processed" state | Inspect If/Switch branches wrapping writes |
| Orchestrator queue dedup via `UniqueReference` | Check `Add Queue Item` properties |
| SQL idempotent writes (`MERGE`, `ON CONFLICT`, `UPSERT`, `WHERE NOT EXISTS`) | Grep SQL statements |
| HTTP idempotency (`Idempotency-Key` header, ETag `If-Match` / `If-None-Match`) | Check HTTP Request headers |
| Status-column filters (`WHERE Status != 'Processed'`) | Grep queries |
| Pre-check workflow invocation (names often contain `check`/`verify`/`exists`/`processed`/`already`/`skip`/`idempoten` — one of many forms, not the only signal) | Inspect invoked workflow names and bodies |
| Per-sub-item progress written to queue `Output` / Data Service / external state | Inspect what's persisted during the loop |

**Severity and finding framing:**

| Scenario | Severity | Finding framing |
|---|---|---|
| One-to-many + sub-units splittable + no idempotency guards + `MaxRetryNumber` < 2 | **Critical** | "Transaction granularity: split into dispatcher/performer. Current architecture risks partial-state corruption on transient failure." |
| One-to-many + sub-units splittable + idempotency guards exist but progress/output fidelity weak | **Warning** | "Transaction granularity: consider dispatcher/performer split for better analytics and retry isolation." |
| One-to-many + sub-units NOT splittable (domain constraint) + missing safeguards | **Warning–Critical** | "Cannot be split — run the 10-point hardening checklist in [rpa-common-issues.md](references/rpa/rpa-common-issues.md) → 'When it cannot be split.' Report each missing safeguard as a separate finding." |
| One-to-many + splittable + guards + retry + per-sub-item output | Info (tech debt) | "Transaction granularity: working with compensation; consider dispatcher/performer if volume grows." |
| Unclear | Info | "Unit of work ambiguous — schema/code documentation gap." |

The shape observation belongs in the **Executive Summary** of the report as a one-liner (see Step 5). Any finding generated from the shape analysis becomes a normal numbered finding in the Critical/Warning/Info sections — not a separate "Unit of Work Analysis" block.


对于编码项目，查找`for`/`foreach`/`while`语句和外部I/O调用。

**步骤3a.3 — 使用以下矩阵分类：**

使用以下矩阵对**事务形态**进行分类。形态是输入与外部影响之间关系的中性描述——**不是**通过/失败的判定。

| 实际执行模式 | 事务形态 |
|---|---|
| 一次调用 → 一次原子外部状态变更（一次写入、一次提交、一次工作流调用） | **一对一** |
| 执行过程中遍历声明输入的数组/集合字段，且循环体包含外部影响（见下方列表） | **一对多** |
| 仅在重试计数器、UI元素枚举或纯内存转换中循环（循环体无外部影响） | **一对一**（内存内循环属于工作单元内部；不是子工作单元） |
| 无循环 | **一对一** |
| 无法确定性映射契约或执行体（模式缺失/不清晰、动态调度） | **不明确** |

**循环体中导致形态为一对多的外部影响**（会话范围、共享凭证、单一门户或业务模型论点均无法消除这些影响）：

- `InvokeWorkflowFile`/`Invoke Method`调用带有外部副作用的工作流
- HTTP活动（`HTTP Request`、连接器活动、REST调用）
- 队列操作（`Add Queue Item`、`Set Transaction Progress`、`Set Transaction Status`）
- 数据库写入（`Execute Non Query`、`Insert Data Table`、`Bulk Insert`）
- 写入`Temp/`目录外的文件（`Write Range`、`Write CSV`、`Append to File`）
- 修改目标系统状态的UI活动（点击提交/保存、输入持久化字段、SAP `Call Transaction`）
- 发送邮件活动

分类是机械性的。不会因以下情况改变：
- “门户将此建模为一个事务”（UX框架≠原子性）
- “一个浏览器会话”（会话≠事务）
- “存在幂等性防护，所以没问题”（防护是补救信号，不是重新分类的依据）
- “PDD称其为一个事务”（声明的意图≠执行实际情况）
- “队列中只有一个条目”（队列是声明的工作单元；实际工作单元是写入的内容）

**步骤3a.4 — 记录形态，然后单独评估补救措施**。

形态本身需中性报告。是否成为发现以及严重程度取决于补救措施：

**对于一对一：** 无发现。在摘要中报告形态观察结果，继续后续步骤。

**对于一对多：** 评估两个独立问题。

*问题A — 子单元是否可独立排队/拆分？*
- 是：正确的修复方案是调度器/执行者模式——拆分队列，使每个子单元成为原子事务。当子单元相互独立时使用此方案（如单个发票、单个员工记录、单个订单、单个文件）。
- 否：领域要求顺序的会话绑定提交（如新SAP计划注册、运营商门户组应用、银行多步骤转账）。队列拆分不可行。修复方案不是架构层面的——而是操作层面的：使用[rpa-common-issues.md](references/rpa/rpa-common-issues.md)中的**10点强化清单**验证原子性、错误处理、崩溃恢复和进度跟踪→“无法拆分时的强化清单”。每个缺失的防护措施都是单独的发现。

*问题B — 当前存在哪些部分故障恢复机制？*

查找以下模式（按语义，而非文件名）：

| 模式 | 检测方式 |
|---|---|
| 每个子单元写入前执行读取-检查-写入 | 检查循环体中的活动序列 |
| 根据“已存在/已处理”状态有条件跳过 | 检查包裹写入操作的If/Switch分支 |
| 通过`UniqueReference`实现Orchestrator队列去重 | 检查`Add Queue Item`属性 |
| SQL幂等写入（`MERGE`、`ON CONFLICT`、`UPSERT`、`WHERE NOT EXISTS`） | 搜索SQL语句 |
| HTTP幂等性（`Idempotency-Key`头、ETag `If-Match`/`If-None-Match`） | 检查HTTP Request头 |
| 状态列过滤（`WHERE Status != 'Processed'`） | 搜索查询语句 |
| 预检查工作流调用（名称通常包含`check`/`verify`/`exists`/`processed`/`already`/`skip`/`idempoten`——多种形式，并非唯一信号） | 检查调用的工作流名称和内容 |
| 每个子项的进度写入队列`Output`/数据服务/外部状态 | 检查循环期间持久化的内容 |

**严重程度和发现表述：**

| 场景 | 严重程度 | 发现表述 |
|---|---|---|
| 一对多 + 子单元可拆分 + 无幂等性防护 + `MaxRetryNumber` < 2 | **严重** | “事务粒度：拆分为调度器/执行者模式。当前架构在临时故障时存在部分状态损坏风险。” |
| 一对多 + 子单元可拆分 + 存在幂等性防护但进度/输出保真度较弱 | **警告** | “事务粒度：考虑拆分为调度器/执行者模式，以获得更好的分析和重试隔离效果。” |
| 一对多 + 子单元**无法**拆分（领域约束） + 缺少防护措施 | **警告–严重** | “无法拆分——运行[rpa-common-issues.md](references/rpa/rpa-common-issues.md)中的10点强化清单→‘无法拆分时’。将每个缺失的防护措施作为单独发现报告。” |
| 一对多 + 可拆分 + 有防护措施 + 可重试 + 每个子项有输出 | 信息（技术债务） | “事务粒度：已使用补偿机制；如果数量增加，考虑拆分为调度器/执行者模式。” |
| 不明确 | 信息 | “工作单元不明确——模式/代码文档存在缺口。” |

形态观察结果需放在报告的**执行摘要**中，作为一行内容（见步骤5）。形态分析产生的任何问题需作为正常编号的发现放入严重/警告/信息部分——不要放在单独的“工作单元分析”块中。

3b. PDD Alignment Review (if PDD is available)

3b. PDD对齐评审（如果PDD可用）

If a PDD was found or provided in Step 0, use it as the primary benchmark for the manual review. For each project, verify:

PDD Section	What to Check	Severity if Mismatched
Business process description	Does the implementation match the described process flow?	Warning
Expected inputs/outputs	Do workflow arguments match PDD-defined inputs and outputs?	Warning
Exception handling requirements	Are Business Exceptions thrown for the cases the PDD defines? Are retries configured per PDD specs?	Warning
Application list	Are all applications from the PDD automated? Any missing? Any extras not in PDD?	Warning
Transaction definition	Does the transaction item structure match the PDD?	Warning
Queue specifications	Queue names, retry counts, SLAs match PDD?	Warning
Credential requirements	Are all credentials from PDD stored securely (assets/vault)?	Critical if hardcoded
SLAs and performance targets	Does the automation design support PDD-defined throughput/timing?	Info
Happy path + exception scenarios	Are all PDD-documented scenarios handled?	Warning
Out of scope items	Does the automation stay within PDD-defined scope?	Info

Report PDD mismatches as a dedicated section in the review report. A technically sound automation that doesn't match its PDD is still a problem.

If no PDD is available, skip this sub-step and note in the report:

Note: No PDD was available for this review. Business logic alignment could not be verified. This review covers technical quality and best practices only.

如果在步骤0中找到或获取了PDD，将其作为手动评审的主要基准。对于每个项目，验证：

PDD章节	检查内容	不匹配时的严重程度
业务流程描述	实现是否符合描述的流程？	警告
预期输入/输出	工作流参数是否符合PDD定义的输入和输出？	警告
异常处理要求	是否针对PDD定义的情况抛出业务异常？是否按PDD规范配置重试？	警告
应用列表	PDD中的所有应用是否都已自动化？是否有遗漏？是否有PDD中未提及的额外应用？	警告
事务定义	事务项结构是否符合PDD？	警告
队列规范	队列名称、重试次数、SLA是否符合PDD？	警告
凭证要求	PDD中的所有凭证是否都安全存储（资产/ vault）？	如果硬编码则为严重
SLA和性能目标	自动化设计是否支持PDD定义的吞吐量/时间要求？	信息
正常路径 + 异常场景	PDD文档中描述的所有场景是否都已处理？	警告
超出范围的项	自动化是否保持在PDD定义的范围内？	信息

报告PDD不匹配情况，作为评审报告中的专门章节。技术上合理但不符合PDD的自动化仍然存在问题。

如果没有PDD，跳过此子步骤并在报告中注明：

注意： 此评审无可用PDD。无法验证业务逻辑对齐情况。本评审仅涵盖技术质量和最佳实践。

3c. Technical Quality Review

3c. 技术质量评审

For each project, load the type-specific checklist:

For Solution / Multi-project scope, also perform solution-level checks from references/solution-review-guide.md:

Solution structure validation (.uipx, config.json, orphan projects) — skip
.uipx
checks if any detected executable is Windows-Legacy; recommend migration instead
Cross-project dependency checks
Configuration consistency across projects
Multi-project architecture pattern assessment

For deep-dive RPA reviews, also consult:

RPA (advanced): rpa-advanced-checklist.md — project organization, selector robustness, variable hygiene, data patterns, error handling depth, testing maturity, idempotency
RPA (long-running): long-running-workflow-issues.md — load when project uses persistence activities (
```
Suspend
```
,
```
Wait and Resume
```
,
```
Create Form Task
```
, Orchestration Process type)
RPA (Modern Studio): modern-studio-issues.md — load for Studio 2024.10+ projects (Modern vs Classic mixing, coded/XAML interop, Object Repository, Data Manager, Healing Agent)
Document Understanding: du-review-checklist.md — load when DU packages detected in
```
project.json
```
dependencies

For common antipatterns per project type, also consult:

RPA: rpa-common-issues.md
Flows: flow-common-issues.md

对于每个项目，加载特定类型的清单：

对于解决方案/多项目范围，还需执行references/solution-review-guide.md中的解决方案级检查：

解决方案结构验证（.uipx、config.json、孤立项目）——如果检测到任何可执行文件为Windows-Legacy，跳过
.uipx
检查；建议迁移
跨项目依赖检查
项目间配置一致性
多项目架构模式评估

对于深度RPA评审，还需参考：

RPA（高级）：rpa-advanced-checklist.md——项目组织、选择器鲁棒性、变量卫生、数据模式、错误处理深度、测试成熟度、幂等性
RPA（长期运行）：long-running-workflow-issues.md——当项目使用持久化活动（
```
Suspend
```
、
```
Wait and Resume
```
、
```
Create Form Task
```
、Orchestration Process类型）时加载
RPA（Modern Studio）：modern-studio-issues.md——针对Studio 2024.10+项目加载（Modern与Classic混合、编码/XAML互操作、对象库、数据管理器、修复Agent）
文档理解：du-review-checklist.md——当
```
project.json
```
依赖项中检测到DU包时加载

针对每种项目类型的常见反模式，还需参考：

RPA：rpa-common-issues.md
流程：flow-common-issues.md

Step 4 — Evaluate Optimization

步骤4 — 评估优化方案

Only after validation (Step 2) and manual review (Step 3) are complete, evaluate optimization.

Solution / Multi-project scope — evaluate cross-project concerns:

Architecture: Is the multi-project design appropriate (dispatcher/performer, main + libraries, flow + resources)?
Cross-project dependencies: Are library versions pinned? Any circular dependencies?
Queue usage: Should this solution use queues for work distribution?
Bulk operations: Are there loops that could use bulk APIs?
Transaction handling: Is error recovery and retry properly implemented across projects?
Resource efficiency: Are there redundant API calls, excessive logging, or unnecessarily large files?
Configuration consistency: Do all projects use the same pattern for configuration (assets, config.json)?

Single Project scope — evaluate within-project optimization:

Queue usage: If processing >50 independent items, should this use queues?
Bulk operations: Are there loops with individual API calls that could be batched?
Transaction handling: Is REFramework or equivalent retry logic needed?
Resource efficiency: File sizes, logging volume, selector efficiency, data handling patterns

Read references/review-workflow-guide.md for the full optimization evaluation criteria.

Read references/architecture-assessment-guide.md for the architecture-level evaluation framework — process suitability, complexity classification, environment separation, and architecture principles scoring.

仅在完成验证（步骤2）和手动评审（步骤3）后，评估优化方案。

解决方案/多项目范围——评估跨项目问题：

架构：多项目设计是否合适（调度器/执行者、主项目+库、流程+资源）？
跨项目依赖：库版本是否固定？是否存在循环依赖？
队列使用：此解决方案是否应使用队列进行工作分配？
批量操作：是否存在可使用批量API的循环？
事务处理：跨项目的错误恢复和重试是否正确实现？
资源效率：是否存在冗余API调用、过度日志记录或不必要的大文件？
配置一致性：所有项目是否使用相同的配置模式（资产、config.json）？

单个项目范围——评估项目内优化：

队列使用：如果处理>50个独立条目，是否应使用队列？
批量操作：是否存在可批量处理的单个API调用循环？
事务处理：是否需要REFramework或等效的重试逻辑？
资源效率：文件大小、日志量、选择器效率、数据处理模式

阅读references/review-workflow-guide.md获取完整的优化评估标准。

阅读references/architecture-assessment-guide.md获取架构级评估框架——流程适用性、复杂度分类、环境分离和架构原则评分。

Step 4.5 — Compute the Agent Letter Grade (A–F)

步骤4.5 — 计算Agent字母等级（A–F）

Agent projects only (phase 1) — matching the Step 2.5 judgment catalog, which is agent-only today. Grade every agent project, and (for a multi-agent solution) the agent set overall, on an A–F scale. Non-agent projects are not graded yet (RPA, flows, coded apps are future phases) — report their findings without a grade. The grade is derived — never a fresh judgment. Take the worse of two sub-grades: G_det is read from the review CLI, G_jud you compute from judgment:

Final grade = min(G_det, G_jud)        where G_det = <review CLI>.Data.Grade

G_det (deterministic) — read it from the review CLI; do not recompute.
```
uip agent review
```
/
```
uip codedagent review
```
(Step 2.5a) returns
```
Data.Grade
```
— that letter, collapsed to its base letter (
```
C+
```
→
```
C
```
), is G_det. (
```
Data.Issues[]
```
are still reported verbatim, but the grade comes from
```
Data.Grade
```
, not from tallying them.)
G_jud (non-deterministic) — the only sub-grade you compute, from the judgment-catalog (2.5b) + manual review (Step 3) findings.

CLI findings already shaped

Data.Grade

(G_det); only judgment findings feed G_jud — so each finding lands in exactly one sub-grade.

G_jud score —

100 − (15 × Criticals) − (4 × Warnings) − (1 × Infos)

over the judgment findings, floored at 0, looked up in the rubric's grade chart:

85–100

→A,

65–84

→B,

45–64

→C,

25–44

→D,

0–24

→F. Then cap: any unmitigated judgment Critical → at most D; security/data-integrity judgment Critical → F. Architecture-principle scores do not feed the grade.

Overall Agent Grade: single agent → its grade. Multiple agents → the worst per-agent grade. Never average grades.

Report the binding constraint in one line (e.g. "B — gated by G_det = CLI Data.Grade B; judgment clean (G_jud A)"). Since the skill grade is

min(Data.Grade, G_jud)

, it is always ≤

Data.Grade

— report both; never overwrite the CLI grade. This goes in the Summary's

Agent Grade

line, and the letter alone is restated as

**Final grade: <A–F>**

on the report's last line (Step 5).

Full rubric, grade chart, low-code section omissions, edge cases (no-PDD / CLI-unavailable / no-eval-set), CLI-grade alignment, and worked examples: references/agents/agent-grading-rubric.md.

仅针对Agent项目（第一阶段）——与步骤2.5的判断规则集匹配，目前规则集仅针对Agent。为每个Agent项目以及（多Agent解决方案）Agent集合整体生成A–F等级。非Agent项目暂不评分（RPA、流程、编码应用属于后续阶段）——报告其发现但不评分。等级需推导得出——绝不主观断言。取两个子评分中的较低值：G_det从评审CLI读取，G_jud由判断得出：

最终等级 = min(G_det, G_jud)        其中G_det = <评审CLI>.Data.Grade

G_det（确定性）——从评审CLI读取；不得重新计算。
```
uip agent review
```
/
```
uip codedagent review
```
（步骤2.5a）返回
```
Data.Grade
```
——该字母，简化为基础字母（
```
C+
```
→
```
C
```
），即为G_det。（
```
Data.Issues[]
```
仍需原样报告，但等级来自
```
Data.Grade
```
，而非计数。）
G_jud（非确定性）——唯一需要计算的子评分，来自判断规则集（2.5b）+ 手动评审（步骤3）的发现。

CLI发现已决定

Data.Grade

（G_det）；仅判断发现会影响G_jud——因此每个发现仅属于一个子评分。

G_jud分数——

100 − (15 × 严重发现数) − (4 × 警告发现数) − (1 × 信息发现数)

，最低为0，对照规则集中的等级表：

85–100

→A，

65–84

→B，

45–64

→C，

25–44

→D，

0–24

→F。然后限制：任何未缓解的严重判断发现→最高为D；安全/数据完整性相关的严重判断发现→F。架构原则评分不影响等级。

整体Agent等级：单个Agent→其等级。多个Agent→最差的单个Agent等级。绝不平均等级。

用一行内容报告约束条件（例如“B — 受G_det = CLI Data.Grade B限制；判断无问题（G_jud A）”）。由于技能等级为

min(Data.Grade, G_jud)

，始终≤

Data.Grade

——需同时报告两个等级；绝不覆盖CLI等级。此内容放在摘要的

Agent Grade

行中，且仅字母会在报告最后一行重述为

**Final grade: <A–F>**

（步骤5）。

完整规则集、等级表、低代码部分省略内容、边缘情况（无PDD/CLI不可用/无评估集）、CLI等级对齐和示例：references/agents/agent-grading-rubric.md。

Step 5 — Produce the Review Report

步骤5 — 生成评审报告

Output a structured report in chat (do NOT create a file):

Report rules — do not violate:

NEVER use internal workflow labels in the output. Forbidden terms: "Path A", "Path B", "Step 3a", "Step 0c", "Mismatch"/"Aligned" (use "one-to-one" / "one-to-many" / "unclear"), "disqualifying criteria", "verdict". The report is for the user, not a trace of the skill's internal workflow.
Do NOT create a separate "Unit of Work Analysis" section. The shape observation is a one-liner in the Summary. If the shape analysis produces a concern, it becomes a normal numbered finding.
Size metrics per file type use activity / variable / node counts, not "lines". Lines are meaningless for XAML and misleading for any file. See "Structural Metrics" table below.
Low-code agent reviews omit some sections — see agent-grading-rubric.md.
Validation Status for Legacy projects says "Use
```
uipath-rpa
```
(Legacy mode) for Legacy-specific validation" — it does NOT say "Could not run" or "Failed". Legacy is supported indefinitely in Studio LTS; the
```
uip rpa
```
CLI targets Modern projects (Legacy mode uses the
```
uip rpa-legacy
```
CLI internally).

Structural metrics to report (never "lines"):

File type	Metrics to use
`.xaml`	Activity count, max nesting depth, root-scope variable count, argument count, invoke-workflow count
`.cs` (coded workflow)	Method count, statement count (LOC excluding blank/comment), class count
`.flow`	Node count, gateway count, longest path depth, subflow count
`.py` (coded agent)	Function count, statement count, import count
Config (JSON/XLSX)	Entry count, nesting depth

Required report structure:

markdown

undefined

在聊天中输出结构化报告（请勿创建文件）：

报告规则——不得违反：

绝不要在输出中使用内部流程标签。禁止使用的术语：“Path A”、“Path B”、“Step 3a”、“Step 0c”、“Mismatch”/“Aligned”（使用“一对一”/“一对多”/“不明确”）、“取消资格标准”、“ verdict”。报告面向用户，而非技能内部流程的跟踪记录。
请勿创建单独的“工作单元分析”部分。形态观察结果是摘要中的一行内容。如果形态分析产生问题，需作为正常编号的发现。
每种文件类型的大小指标使用活动/变量/节点数量，而非“行数”。行数对XAML无意义，对任何文件都有误导性。见下方“结构指标”表格。
低代码Agent评审需省略部分章节——详见agent-grading-rubric.md。
Legacy项目的验证状态需注明“使用
```
uipath-rpa
```
（Legacy模式）进行Legacy专属验证”——不得注明“无法运行”或“失败”。Legacy在Studio LTS中永久支持；
```
uip rpa
```
CLI针对Modern项目（Legacy模式内部使用
```
uip rpa-legacy
```
CLI）。

需报告的结构指标（绝不使用“行数”）：

文件类型	使用的指标
`.xaml`	活动数量、最大嵌套深度、根作用域变量数量、参数数量、调用工作流数量
`.cs` （编码工作流）	方法数量、语句数量（排除空白/注释的LOC）、类数量
`.flow`	节点数量、网关数量、最长路径深度、子流程数量
`.py` （编码Agent）	函数数量、语句数量、导入数量
配置（JSON/XLSX）	条目数量、嵌套深度

必填报告结构：

markdown

undefined

Review Report: <Project or Solution Name>

评审报告：<项目或解决方案名称>

Summary

摘要

Overall Quality: Good / Needs Improvement / Critical Issues
Agent Grade: <A–F> — <verdict label> (<binding constraint, e.g. "gated by G_det = CLI Data.Grade B; judgment clean (G_jud A, 91)">) — agent projects only; omit this line if the review has no agent projects
Business Value: <1-2 sentence description of what this automation does>
Review Scope: Single project / Solution (N projects) / Multi-project repo (N executables + M libraries)
Project Types Found: <list with type and language, e.g., "RPA (XAML, VisualBasic)", "Agent (Coded, Python)">
Validation Status: <per project: pass with counts, or "Validation via uipath-rpa (Legacy mode)" for Legacy>
PDD Available: Yes (path) / No — business logic alignment not verified
Transaction Shape: <one line per project, e.g., "Processes 1 invoice per invocation (one-to-one)." or "Processes 1 company per invocation; internally writes N employee enrollments (one-to-many) — see [W-002].">

整体质量： 良好 / 需要改进 / 严重问题
Agent等级： <A–F> — <判定标签>（<约束条件，例如“受G_det = CLI Data.Grade B限制；判断无问题（G_jud A，91分）”>）——仅Agent项目；如果评审无Agent项目，省略此行
业务价值： <1-2句话描述此自动化的功能>
评审范围： 单个项目 / 解决方案（N个项目） / 多项目仓库（N个可执行项目 + M个库）
发现的项目类型： <列表，包含类型和语言，例如“RPA（XAML，VisualBasic）”、“Agent（编码，Python）”>
验证状态： <每个项目：通过及数量，或Legacy项目为“通过uipath-rpa（Legacy模式）验证”>
PDD可用： 是（路径） / 否——未验证业务逻辑对齐情况
事务形态： <每个项目一行，例如“每次调用处理1张发票（一对一）”或“每次调用处理1家公司；内部写入N条员工注册记录（一对多）——详见[W-002]”>

PDD Alignment (only if PDD was available)

PDD对齐情况（仅当PDD可用时）

PDD Requirement	Implementation Status	Finding
...	...	...

If no PDD: "No PDD was available for this review. Business logic alignment could not be verified."

PDD要求	实现状态	发现
...	...	...

如果无PDD：“此评审无可用PDD。无法验证业务逻辑对齐情况。”

Automated Validation Results

自动化验证结果

Project	File	Command	Errors	Warnings	Info
...	...	...	...	...	...

Validation Details: (Errors and Warnings only — omit the heading entirely when there are none)

[V-E-001] <project>/<file>: <rule-id> — <message>
[V-W-001] <project>/<file>: <rule-id> — <message>

For Legacy projects, note: "Validation CLI (
uip rpa validate
,
uip rpa analyze
) targets Modern projects. Legacy validation runs through
uipath-rpa
Legacy mode (using the
uip rpa-legacy
CLI)."

项目	文件	命令	错误	警告	信息
...	...	...	...	...	...

验证详情： （仅错误和警告——如果无错误和警告，完全省略此标题）

[V-E-001] <项目>/<文件>: <rule-id> — <消息>
[V-W-001] <项目>/<文件>: <rule-id> — <消息>

对于Legacy项目，注明：“验证CLI（
uip rpa validate
、
uip rpa analyze
）针对Modern项目。Legacy验证通过
uipath-rpa
Legacy模式（使用
uip rpa-legacy
CLI）运行。”

Rules Skipped

跳过的规则

Rule / Command	Why
`uip codedagent review`	CLI not available in environment (deterministic checks not run)
`LC_GUARDRAIL_ACTION_INEFFECTIVE` , `LC_GUARDRAIL_MISAPPLIED`	Guardrails catalog unavailable (agent declares 2 guardrails, effectiveness unverified)

Only rules that were intended but could not be applied (Critical Rule 11). Group skips sharing one cause into a single row.

规则/命令	原因
`uip codedagent review`	环境中无此CLI（未运行确定性检查）
`LC_GUARDRAIL_ACTION_INEFFECTIVE` 、 `LC_GUARDRAIL_MISAPPLIED`	防护配置规则集不可用（Agent声明了2个防护配置，有效性未验证）

仅记录原本计划应用但无法执行的规则（核心规则11）。将同一原因导致的跳过合并为一行。

Critical Findings (block deployment)

严重发现（阻碍部署）

ID	Rule	Recommendation
C-D-001	`LOWCODE_SYSTEM_MESSAGE_MISSING`	`ClassifierAgent/agent.json` : `messages[0]` (system role) has empty content. Set `messages[0].content` to a non-empty system prompt.
C-001	—	`ProjectA/Helper.cs` : Password argument uses `String` . Change the argument type to `SecureString` .

ID	规则	建议
C-D-001	`LOWCODE_SYSTEM_MESSAGE_MISSING`	`ClassifierAgent/agent.json` : `messages[0]` （系统角色）内容为空。将 `messages[0].content` 设置为非空系统提示。
C-001	—	`ProjectA/Helper.cs` : Password参数使用 `String` 。将参数类型更改为 `SecureString` 。

Warnings (should fix before production)

警告（生产前应修复）

ID	Rule	Recommendation
W-D-002	`LC_PROMPT_ROLE_DEFINITION`	`ClassifierAgent/agent.json` : System prompt starts with task instructions before defining the agent's role. Open with: "You are an X that does Y."

ID	规则	建议
W-D-002	`LC_PROMPT_ROLE_DEFINITION`	`ClassifierAgent/agent.json` : 系统提示在定义Agent角色前先包含任务说明。请以“您是一个X，负责Y。”开头。

Improvement Opportunities

改进机会

ID	Rule	Recommendation
I-D-001	`LC_GUARDRAIL_RECOMMENDED`	`ClassifierAgent/agent.json` : `inputSchema.properties` contains `customer_email` and `ssn` without a PII guardrail. Add an Agent-scope PII guardrail with a block action.

One row per finding. Format each recommendation as
<file>: <issue>. <fix>.
Use the CLI's
File
,
Description
, and
SuggestedFix
verbatim; keep judgment and manual findings concise. Review-CLI, judgment-catalog, and manual-checklist findings all go in these three tables — do not split them into separate sections by source, and never list a finding in more than one table.
Rule
is
—
for a finding with no
rule_id
(Critical Rule 12).

ID	规则	建议
I-D-001	`LC_GUARDRAIL_RECOMMENDED`	`ClassifierAgent/agent.json` : `inputSchema.properties` 包含 `customer_email` 和 `ssn` ，但无PII防护配置。添加Agent范围的PII防护配置，设置阻止操作。

每个发现一行。将每个建议格式化为
<文件>: <问题>. <修复方案>.
。原样使用CLI的
File
、
Description
和
SuggestedFix
；判断和手动发现需简洁。评审CLI、判断规则集和手动清单的发现都放入这三个表格中——请勿按来源拆分到不同章节，且每个发现仅放入一个表格。无
rule_id
的发现，
规则
列填
—
（核心规则12）。

Per-Project Summary

每个项目的摘要

Project	Type	Language	Size	Validation	Quality	Grade	Key Findings
ClassifierAgent	Agent (Coded)	Python	14 functions, 220 statements	Pass	Good	B	W-D-002
ProjectA	RPA (Coded)	CSharp	42 methods, 1,300 statements	1 error, 2 warnings	Needs Improvement	—	V-E-001, W-001
ProjectB	Flow	—	18 nodes, 3 gateways, depth 5	Pass	Good	—	I-001
ProjectC	RPA (XAML)	VisualBasic	84 activities, 50 vars, depth 12	Via uipath-rpa (Legacy mode)	Needs Improvement	—	C-002, W-003

The Grade column is the per-agent
min(G_det, G_jud)
from Step 4.5 — agent projects only (
—
for other types, phase 1). Append the review CLI's
Data.Grade
when it differs, e.g.
B (CLI: A)
. The Quality column (Good / Needs Improvement / Critical Issues) applies to every project type.

项目	类型	语言	大小	验证	质量	等级	关键发现
ClassifierAgent	Agent（编码）	Python	14个函数，220条语句	通过	良好	B	W-D-002
ProjectA	RPA（编码）	CSharp	42个方法，1300条语句	1个错误，2个警告	需要改进	—	V-E-001、W-001
ProjectB	流程	—	18个节点，3个网关，深度5	通过	良好	—	I-001
ProjectC	RPA（XAML）	VisualBasic	84个活动，50个变量，深度12	通过uipath-rpa（Legacy模式）	需要改进	—	C-002、W-003

等级列是步骤4.5中每个Agent的
min(G_det, G_jud)
——仅Agent项目（其他类型填
—
，第一阶段）。如果与CLI等级不同，附加评审CLI的
Data.Grade
，例如
B (CLI: A)
。质量列（良好/需要改进/严重问题）适用于所有项目类型。

Recommended Next Steps

建议的下一步操作

Route each fix to the appropriate skill:

Fix needed	Use skill
Fix RPA workflow / coded workflow / XAML / project.json	`uipath-rpa`
Fix RPA Windows-Legacy project	`uipath-rpa` (Legacy mode)
Fix agent (coded or low-code)	`uipath-agents`
Fix flow (.flow)	`uipath-maestro-flow`
Fix Maestro BPMN (.bpmn)	`uipath-maestro-bpmn`
Fix API workflow (Workflow.json)	`uipath-api-workflow`
Fix coded app	`uipath-coded-apps`
Fix Orchestrator resources (assets, queues, folders)	`uipath-platform`
Fix `.uipx` solution / pack / publish / deploy lifecycle	`uipath-solution`

Fix [C-001] using
```
uipath-rpa
```
— change argument type to SecureString
...

将每个修复任务路由到相应技能：

需要修复的内容	使用技能
修复RPA工作流/编码工作流/XAML/project.json	`uipath-rpa`
修复RPA Windows-Legacy项目	`uipath-rpa` （Legacy模式）
修复Agent（编码或低代码）	`uipath-agents`
修复流程（.flow）	`uipath-maestro-flow`
修复Maestro BPMN（.bpmn）	`uipath-maestro-bpmn`
修复API工作流（Workflow.json）	`uipath-api-workflow`
修复编码应用	`uipath-coded-apps`
修复Orchestrator资源（资产、队列、文件夹）	`uipath-platform`
修复 `.uipx` 解决方案/打包/发布/部署生命周期	`uipath-solution`

使用
```
uipath-rpa
```
修复[C-001]——将参数类型更改为SecureString
...

Optimization Notes

优化说明

<queue usage, bulk operations, retry/idempotency observations — e.g., partial-failure handling for one-to-many shapes. Only print section when optimization is relevant and applicable to the project or solution.>

Final grade: <A–F>


> **`Final grade:` is the report's last line — nothing follows it.** No notes, caveats, or commentary, inside the report or after it. It restates the Summary's `Agent Grade` letter so the grade stays visible at the tail of a long report; the two must always match. Letter only. Only print for agent projects.

**Finding severity labels (never "Mismatch"/"Aligned"):**
- Overall Quality: `Good` / `Needs Improvement` / `Critical Issues` (all project types)
- Agent Grade: `A` / `B` / `C` / `D` / `F` (no `+`/`-`) — agent projects only; see Step 4.5 and [agent-grading-rubric.md](references/agents/agent-grading-rubric.md)
- Transaction Shape: `one-to-one` / `one-to-many` / `unclear`
- Findings: `Critical` / `Warning` / `Info`

**Overall Quality thresholds** (all project types):
- **Good** — 0 Critical, 0–3 Warnings
- **Needs Improvement** — 0 Critical, 4+ Warnings OR 1 Critical with clear fix
- **Critical Issues** — 2+ Critical OR 1 Critical with security/data-integrity implications

**Agent Grade → verdict label** (agent projects only; the line reads "B — Good"):

| Grade | Verdict label |
|---|---|
| **A** / **B** | Good |
| **C** / **D** | Needs Improvement |
| **F** | Critical Issues |

This maps the letter to the verdict word only. The agent grade is `min(G_det, G_jud)` from Step 4.5, where **G_det is the review CLI's `Data.Grade`** and the G_jud band lives in Step 4.5 — do not restate either here.

<队列使用、批量操作、重试/幂等性观察——例如一对多形态的部分故障处理。仅当优化与项目或解决方案相关且适用时，才打印此部分。>

Final grade: <A–F>


> **`Final grade:`是报告的最后一行——无后续内容。** 报告内或报告后不得添加任何注释、警告或说明。它重述摘要中的`Agent Grade`字母，以便在长报告末尾仍能看到等级；两者必须始终一致。仅显示字母。仅在Agent项目中打印。

**发现严重程度标签（绝不使用“Mismatch”/“Aligned”）：**
- 整体质量：`良好`/`需要改进`/`严重问题`（所有项目类型）
- Agent等级：`A`/`B`/`C`/`D`/`F`（无`+`/`-`）——仅Agent项目；详见步骤4.5和[agent-grading-rubric.md](references/agents/agent-grading-rubric.md)
- 事务形态：`一对一`/`一对多`/`不明确`
- 发现：`严重`/`警告`/`信息`

**整体质量阈值**（所有项目类型）：
- **良好**——0个严重发现，0–3个警告发现
- **需要改进**——0个严重发现，4个以上警告发现 或 1个有明确修复方案的严重发现
- **严重问题**——2个以上严重发现 或 1个涉及安全/数据完整性的严重发现

**Agent等级→判定标签**（仅Agent项目；行内容为“B — 良好”）：

| 等级 | 判定标签 |
|---|---|
| **A**/**B** | 良好 |
| **C**/**D** | 需要改进 |
| **F** | 严重问题 |

此映射仅将字母转换为判定词。Agent等级为步骤4.5中的`min(G_det, G_jud)`，其中**G_det为评审CLI的`Data.Grade`**，G_jud来自步骤4.5——请勿在此处重述。

Task Navigation

任务导航

I need to...	Read this
Compute the A–F letter grade for an agent (Step 4.5)	agent-grading-rubric.md
Understand the rule row schema	rule-format.md
Run the review CLI + judgment catalog (Step 2.5)	rule-catalog-workflow.md
Apply the low-code agent judgment catalog	agents-lowcode-rules.md
Apply the coded agent judgment catalog	agents-coded-rules.md
Understand the full review workflow in detail	review-workflow-guide.md
Review a solution structure (.uipx)	solution-review-guide.md
Review an RPA project (coded or XAML)	rpa-review-checklist.md
Find common RPA issues	rpa-common-issues.md
Review a flow project	flow-review-checklist.md
Find common flow issues	flow-common-issues.md
Review a Maestro BPMN project (.bpmn)	bpmn-review-checklist.md
Review an API workflow project (Workflow.json)	api-workflow-review-checklist.md
Review a coded app	coded-app-review-checklist.md
Review Orchestrator resources	platform-resources-checklist.md
Deep-dive an RPA project	rpa-advanced-checklist.md
Review a long-running / Orchestration Process (persistence, Wait/Resume, Suspend)	long-running-workflow-issues.md
Review Modern Studio (2024.10+) specific concerns (Modern vs Classic, coded/XAML interop, Object Repo, Healing Agent)	modern-studio-issues.md
Review a Document Understanding project	du-review-checklist.md
Assess architecture and process suitability	architecture-assessment-guide.md
Review source control / CI-CD / DevOps readiness (any project type)	devops-readiness-checklist.md

我需要...	阅读此文档
计算Agent的A–F字母等级（步骤4.5）	agent-grading-rubric.md
理解规则行模式	rule-format.md
运行评审CLI + 判断规则集（步骤2.5）	rule-catalog-workflow.md
应用低代码Agent判断规则集	agents-lowcode-rules.md
应用编码Agent判断规则集	agents-coded-rules.md
详细理解完整评审流程	review-workflow-guide.md
评审解决方案结构（.uipx）	solution-review-guide.md
评审RPA项目（编码或XAML）	rpa-review-checklist.md
查找常见RPA问题	rpa-common-issues.md
评审流程项目	flow-review-checklist.md
查找常见流程问题	flow-common-issues.md
评审Maestro BPMN项目（.bpmn）	bpmn-review-checklist.md
评审API工作流项目（Workflow.json）	api-workflow-review-checklist.md
评审编码应用	coded-app-review-checklist.md
评审Orchestrator资源	platform-resources-checklist.md
深度评审RPA项目	rpa-advanced-checklist.md
评审长期运行/编排流程（持久化、Wait/Resume、Suspend）	long-running-workflow-issues.md
评审Modern Studio（2024.10+）特定问题（Modern与Classic混合、编码/XAML互操作、对象库、修复Agent）	modern-studio-issues.md
评审文档理解项目	du-review-checklist.md
评估架构和流程适用性	architecture-assessment-guide.md
评审源代码控制/CI-CD/DevOps就绪情况（任何项目类型）	devops-readiness-checklist.md

Anti-Patterns — What NOT to Do

反模式——请勿执行以下操作

Do not modify files. This is a review skill, not a builder. Identify issues, recommend fixes, and tell the user which skill to use.
Do not review without running automated validation first. Manual review alone misses structural issues that CLI tools catch instantly.
Do not skip solution-level discovery. Reviewing a single project without understanding the solution context leads to wrong optimization recommendations (e.g., suggesting queues when the solution already has a dispatcher/performer pattern).
Do not report validation errors as manual findings. Reference the validation output — do not re-describe what the CLI already reported.
Do not provide a review without severity ratings. Every finding must be Critical, Warning, or Info. An undifferentiated list of issues is not actionable.
Do not recommend architecture changes without understanding business context. Ask about volume, frequency, SLA, and error tolerance before suggesting queue-based processing, parallel execution, or other architectural patterns.
Do not attempt to fix issues yourself. Report the issue, suggest the fix, name the skill that can apply it. Stop there.
Do not flag Windows-Legacy compatibility as Critical. Legacy is supported indefinitely in Studio LTS — 2024.10, 2025.10, 2026.10, and all future LTS releases continue to support creating, opening, editing, running, and deploying Legacy projects. It is NOT a deployment blocker and NOT a mid-term support risk. Deprecation means "no new features added to Legacy," not "Legacy will be removed." Flag as Warning (if the project would benefit from capabilities Legacy lacks — see rpa-review-checklist.md §10 for ranked feature list) or Info (if Studio LTS is the organizational standard or SOAP web services are required). When recommending migration, lead with the 2-3 features most relevant to the project's actual pain (typically Healing Agent, Unified Target / Modern UIA, Object Repository, ScreenPlay, coded test cases, Autopilot, Agents/Maestro). Route Legacy-specific deep validation to
```
uipath-rpa
```
(Legacy mode).
Do not recommend removing a dependency without grepping for usages. A package may be the sole supplier of an activity used elsewhere — recommend removal only after confirming no consumers exist.
Do not flag
-preview
package versions. Many UiPath packages currently ship preview-by-default during the public preview phase, and resolution defaults to bringing them in with explicit user confirmation. Surface stability concerns through activity-owner channels, not user-facing review reports.
Do not run scripts or install Python packages from this skill. Deterministic checks run in the
```
uip agent review
```
/
```
uip codedagent review
```
CLI (Step 2.5a), not via scripts. The skill itself ships no executable code.

请勿修改文件。此为评审技能，而非构建技能。识别问题，建议修复方案，并告知用户应使用的技能。
请勿在未运行自动化验证的情况下进行评审。仅手动评审会遗漏CLI工具可立即捕获的结构问题。
请勿跳过解决方案级发现。在不了解解决方案上下文的情况下评审单个项目，会导致错误的优化建议（例如，当解决方案已使用调度器/执行者模式时，仍建议使用队列）。
请勿将验证错误报告为手动发现。引用验证输出——请勿重新描述CLI已报告的内容。
请勿提供无严重程度评级的评审。每个发现必须标记为严重、警告或信息。未区分严重程度的问题列表不具备可操作性。
请勿在不理解业务上下文的情况下建议架构变更。在建议基于队列的处理、并行执行或其他架构模式前，询问数量、频率、SLA和错误容忍度。
请勿尝试自行修复问题。报告问题，建议修复方案，指明可应用修复的技能。到此为止。
请勿将Windows-Legacy兼容性标记为严重问题。Legacy在Studio LTS中永久支持——2024.10、2025.10、2026.10及所有未来LTS版本将继续支持创建、打开、编辑、运行和部署Legacy项目。它不是部署阻碍，也不是中期支持风险。弃用意味着“不再为Legacy添加新功能”，而非“Legacy将被移除”。如果项目可从Legacy不具备的功能中受益，标记为警告（详见rpa-review-checklist.md §10的功能列表）；如果组织标准为Studio LTS或需要SOAP Web服务，标记为信息。建议迁移时，重点提及与项目实际痛点最相关的2-3个功能（通常为修复Agent、统一目标/Modern UIA、对象库、ScreenPlay、编码测试用例、Autopilot、Agents/Maestro）。将Legacy专属深度验证路由到
```
uipath-rpa
```
（Legacy模式）。
请勿在未搜索使用情况的情况下建议移除依赖项。包可能是其他地方使用的活动的唯一来源——仅在确认无使用者后，才建议移除。
请勿标记
-preview
包版本。许多UiPath包在公开预览阶段默认以预览版发布，且需用户明确确认才会引入。通过活动所有者渠道反馈稳定性问题，而非在面向用户的评审报告中提及。
请勿从此技能运行脚本或安装Python包。确定性检查在
```
uip agent review
```
/
```
uip codedagent review
```
CLI中运行（步骤2.5a），而非通过脚本。此技能本身不包含可执行代码。