code-review

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Code review

代码审查

Coordinate a compact reviewer or focused specialists to review an existing change set as read-only input and produce one evidence-backed report.

协调一名精简审查者或一组专注的专项审查者，将现有变更集作为只读输入进行审查，并产出一份有证据支撑的报告。

Orchestrator instructions

编排器说明

Spawn every reviewer fresh with
```
fork_turns="none"
```
; never reuse one for validation or resolution.
Ignore staged versus unstaged status. Review all uncommitted changes together; never report a staging split as a finding.
Treat review as read-only. Repository task-completion verification instructions apply to implementation work, not review.
Record validation results available when review starts as
```
Available validation evidence
```
, including their exact target and actual status when known; use
```
Unavailable
```
when none exist. Treat this evidence as context, not proof that the change is correct.
Build each reviewer launch envelope from the shared review context, its assignment packet, reviewer instructions, applicable mode instructions, assigned review roles, and applicable guidance collected in Step 1. Include subagent model selection when the recipient can delegate. Keep review-wide routing and lifecycle metadata outside assignment packets so packets describe only review responsibility; do not ask reviewers to rediscover scope.
Schedule or batch specialists so each specialist can spawn its required children without exceeding the available agent limit.
Report checked scope and actual findings. Mark review incomplete when missing context or expertise blocks completion; otherwise use "No issues found." when none exist.

每位审查者都要使用
```
fork_turns="none"
```
全新启动；绝不将同一审查者复用于验证或问题解决。
忽略 staged 与 unstaged 状态差异。将所有未提交更改作为一个整体审查；绝不把暂存区划分本身作为问题报告。
将审查视为只读操作。代码仓库中有关任务完成验证的说明仅适用于实现工作，不适用于审查。
审查开始时，将已有的验证结果记录为
```
Available validation evidence
```
，并在已知时注明其确切目标和实际状态；没有验证结果时使用
```
Unavailable
```
。将这些证据视为上下文，而不是变更正确的证明。
根据共享审查上下文、任务包、审查者说明、适用的模式说明、所分配的审查角色以及第 1 步收集的适用指导，构建每位审查者的启动信息包。当接收方可以委派时，还应包含 subagent 模型选择。将审查范围的路由和生命周期元数据保留在任务包之外，使任务包仅描述审查职责；不要要求审查者重新推断范围。
调度或分批安排专项审查者，确保每位专项审查者都能派生其所需的子 Agent，同时不超过可用 Agent 限额。
报告已检查的范围和实际发现。缺少上下文或专业知识阻碍完成时，将审查标记为不完整；否则，如果没有发现问题，使用 "No issues found."。

Subagent model selection

Subagent 模型选择

Apply this policy to every subagent assignment, including planning, review children, validation, and resolution. Leave the user's main-agent model and effort unchanged.
Use the configured subagent defaults for ordinary assignments, including routine final validation, and omit both
```
model
```
and
```
reasoning_effort
```
at launch. The intended baseline is
```
gpt-6.1-sol
```
with
```
xhigh
```
. Routine cross-file tracing, asynchronous UI states, and fixture or guard checks belong on this baseline.
Before choosing stronger settings, collect available context and check the assignment. Split independent responsibilities that compete for attention, but keep interacting contracts together when they need joint analysis.

Choose from these automatic escalations based on the assignment's concrete reasoning difficulty:

Model	Effort	Use when
`gpt-6.1-sol`	`max`	A focused assignment needs a long, well-defined chain of reasoning across files or states.
`gpt-6-astra`	`high`	Available evidence supports competing explanations across interacting contracts that are hard to distinguish, or a well-scoped Sol analysis leaves a specific reasoning problem that stronger expertise can settle with the available evidence.

Select the needed tier directly. Record the chosen settings and concrete reason in routing metadata, outside the scope packet, and pass both
```
model
```
and
```
reasoning_effort
```
explicitly for each escalation.
Return any escalation records with your report so the orchestrator can account for nested assignments.

对每个 subagent 任务都应用此策略，包括规划、审查子 Agent、验证和问题解决。保持用户主 Agent 的模型和推理强度不变。
对普通任务（包括常规最终验证）使用已配置的 subagent 默认值，启动时省略
```
model
```
和
```
reasoning_effort
```
。预期基线为
```
gpt-6.1-sol
```
，配合
```
xhigh
```
。常规的跨文件追踪、异步 UI 状态以及 fixture 或 guard 检查均属于该基线范围。
在选择更强设置前，收集可用上下文并检查任务分配。拆分相互独立且会争夺注意力的职责；但当交互契约需要联合分析时，应将其放在一起。

根据任务的具体推理难度，从以下自动升级选项中选择：

模型	推理强度	使用场景
`gpt-6.1-sol`	`max`	聚焦任务需要跨文件或跨状态进行长且定义明确的推理链。
`gpt-6.1-astra`	`high`	可用证据支持多种关于交互契约的解释，而这些解释难以区分；或者范围明确的 gpt-6.1-sol 分析后，仍留下可由更强专业能力依据现有证据解决的具体推理问题。

直接选择所需层级。将所选设置和具体原因记录在路由元数据中（置于范围任务包之外），并在每次升级时明确传入
```
model
```
和
```
reasoning_effort
```
。
随报告返回所有升级记录，以便编排器核算嵌套任务。

Reviewer instructions

审查者说明

Before reviewing code, scan the names and descriptions of all available skills, including global and repository-local skills, for relevance to your assigned scope.
Read every relevant skill and its required references before starting the review, then apply that guidance to behavior, conventions, and cleanup decisions. Supplied domain skills are known applicable guidance, not the complete list. Read additional relevant skills when related code brings another domain into scope.
Review only assigned behavior, following relevant code wherever needed; ignore unrelated concerns.
Check assigned code against applicable global and repository instructions, domain practices, and established patterns in comparable code. Every review role owns this check within its scope, including when the code works and tests pass.
Distinguish established conventions from personal preferences. Check that examples serve the same purpose and fit the current language, framework, and supported versions. Respect instruction priority and documented exceptions; do not copy a legacy pattern or a known defect just for consistency.
Support each finding with an exact code location and evidence. For a defect, show a concrete trigger and consequence. For a practice or consistency violation, cite the applicable rule or comparable code and explain the deviation; a proven convention violation does not need a runtime failure. A general best-practice claim needs a concrete benefit or risk in the assigned code, not preference alone. Use supplied validation as context and return claims that code inspection cannot settle as unresolved candidates.
Merge duplicate root causes into one candidate list, assign a stable ID to every candidate, and do not remove a supported candidate because it is low priority, cosmetic, readability-related, or easy to fix.
Keep findings, incomplete reviews, and human-review candidates separate. Use human review for material decisions or confirmations requiring project context unavailable in the repository; use incomplete review when technical analysis is unfinished. Include the location, missing context, consequence, and required human action.

在审查代码前，扫描所有可用 skill 的名称和描述（包括全局和代码仓库本地 skill），查找与所分配范围相关的内容。
开始审查前，读取每个相关 skill 及其必需引用，然后将其指导应用于行为、约定和清理决策。提供的领域 skill 是已知适用的指导，但不是完整清单。当相关代码引入其他领域时，读取额外的相关 skill。
仅审查所分配的行为；按需跟踪相关代码；忽略无关问题。
根据适用的全局和代码仓库说明、领域实践以及可比代码中已确立的模式，检查所分配代码。每个审查角色都需在其范围内负责此项检查，即使代码可以工作且测试通过。
区分既定约定与个人偏好。检查示例是否服务于相同目的，并是否适合当前语言、框架和受支持版本。遵循指令优先级和已记录的例外；不要仅为保持一致而复制遗留模式或已知缺陷。
每项发现都必须有精确代码位置和证据支持。对于缺陷，给出具体触发条件和后果。对于实践或一致性违规，引用适用规则或可比代码并解释偏差；已证实违反约定无需运行时失败。一般最佳实践主张必须说明在所分配代码中的具体收益或风险，不能仅凭个人偏好。将提供的验证作为上下文，并返回代码检查无法确定的论断，将其列为未解决候选项。
将重复根因合并为一个候选项列表，为每个候选项分配稳定 ID；不得因为某个受支持的候选项优先级低、仅涉及外观、与可读性相关或易于修复，就将其删除。
将发现、不完整审查和需要人工审查的候选项分开。需要项目上下文但仓库中不可得的重大决策或确认事项归入人工审查；技术分析尚未完成时归入不完整审查。包含位置、缺失的上下文、后果和需要人工采取的行动。

Compact reviewer instructions

精简审查者说明

Review one combined packet directly across all assigned roles and domain skills; spawn no children or validators.
Return candidates and evidence to the orchestrator; if none exist, return checked scope and "No issues found."
Mark unfinished responsibilities incomplete with missing context or expertise and completed scope; do not guess.

直接根据一个合并任务包完成所有所分配角色和领域 skill 的审查；不派生任何子 Agent 或验证者。
向编排器返回候选项和证据；如果不存在候选项，则返回已检查范围和 "No issues found."。
将尚未完成的职责标记为不完整，并说明缺失的上下文或专业知识以及已完成的范围；不要猜测。

Specialist instructions

专项审查者说明

Give each child a self-contained narrower assignment marked as internal, with the reviewer instructions and applicable guidance for its scope, and instruct it to work directly without invoking code-review orchestration. Do not pass these general specialist instructions or the specialist role; the specialist alone controls the child's prompt, scope, evidence contract, and lifecycle.
Delegate one coherent responsibility, not individual checklist items, and verify child evidence before merging it into the candidate list.
When the merged candidate list is empty, return checked scope and "No issues found." without spawning a validator.
When the merged candidate list is nonempty, spawn exactly one fresh final finding validator with
```
fork_turns="none"
```
. Mark the assignment as internal and give it the exact candidate list with IDs, code scope, prior evidence and reproduction results, applicable guidance, and final finding validator instructions.
Return every validator-confirmed finding with its stable ID. Keep validator-rejected candidates out of findings, and return validator-unresolved candidates separately as an incomplete review.

向每个子 Agent 提供一个自包含且范围更窄的任务，将其标记为
```
internal
```
，并附上其范围内的审查者说明和适用指导；指示其直接工作，不要调用代码审查编排。不要传递这些通用专项说明或专项角色；由专项审查者单独控制子 Agent 的提示词、范围、证据契约和生命周期。
委派一项连贯职责，而不是逐个清单项；将子 Agent 证据并入候选项列表前，先验证这些证据。
合并后的候选项列表为空时，返回已检查范围和 "No issues found."，不要派生验证者。
合并后的候选项列表非空时，恰好派生一名全新的最终发现验证者，使用
```
fork_turns="none"
```
。将该任务标记为
```
internal
```
，并向其提供带有 ID 的确切候选项列表、代码范围、已有证据和复现结果、适用指导以及最终发现验证者说明。
返回每项经验证者确认的发现，并保留其稳定 ID。将被验证者否决的候选项排除在发现之外；将验证者无法解决的候选项单独作为不完整审查返回。

Final finding validator instructions

最终发现验证者说明

Perform this internal assignment directly without invoking code-review orchestration. Review only the supplied candidates and code needed to validate them; do not search for new findings or spawn children.
Before inspecting code to validate candidates, scan the names and descriptions of all available skills, including global and repository-local skills, then read every relevant skill and its required references. Apply that guidance when confirming or rejecting findings. Supplied guidance does not replace this skill check.
Independently establish or refute each candidate from its code location and evidence. For defects, check the trigger and consequence. For practice or consistency violations, check the rule or comparable examples, their applicability and exceptions, and the deviation. Do not require a runtime failure for a proven convention violation or accept personal preference as a rule. Reuse supplied evidence and reproduction results; only when they have not settled a claim, run the smallest new read-only reproduction once.
Preserve every candidate ID and return exactly one disposition for each:
```
Confirmed
```
with supporting evidence,
```
Rejected
```
with contradicting evidence, or
```
Unresolved
```
with the missing context or validation needed.
Do not suppress or downgrade a confirmed candidate because it is low priority, cosmetic, readability-related, or easy to fix. Priority is assigned after validation.

直接执行此
```
internal
```
任务，不调用代码审查编排，也不派生子 Agent。仅审查所提供的候选项及验证这些候选项所需的代码；不要搜索新发现，也不要派生子 Agent。
在检查代码以验证候选项前，扫描所有可用 skill 的名称和描述（包括全局和代码仓库本地 skill），然后读取每个相关 skill 及其必需引用。在确认或否决发现时应用这些指导。所提供的指导不能替代此项 skill 检查。
根据代码位置和证据，独立确立或推翻每个候选项。对于缺陷，检查触发条件和后果。对于实践或一致性违规，检查规则或可比示例、其适用性和例外，以及偏差。对于已证实的约定违规，不要求运行时失败；也不接受个人偏好作为规则。复用所提供的证据和复现结果；仅当这些材料尚未解决某项论断时，才运行一次最小的新只读复现。
保留每个候选项 ID，并针对每项返回且仅返回一种处置结论：
```
Confirmed
```
（附支持证据）、
```
Rejected
```
（附反驳证据）或
```
Unresolved
```
（附缺失上下文或所需验证）。
不要因为某个已确认候选项优先级低、仅涉及外观、与可读性相关或易于修复，就将其抑制或降级。优先级在验证后确定。

Workflow

工作流

Step 1: Select review mode and assignments

第 1 步：选择审查模式和任务分配

Use one subagent with
```
fork_turns="none"
```
for this internal planning task to identify review source: branch, commit, pull request, or uncommitted changes. Give it the applicable global and user instructions already available to the orchestrator and the subagent model selection policy. Unless the user specifies one, review all uncommitted changes when any exist; otherwise fetch the remote default branch and review the entire current branch against its fresh remote-tracking ref.
Collect applicable guidance for the changed code: global user instructions, root and nested repository instructions, relevant documentation and tool configuration, and domain skills. Inspect nearby code and shared helpers for established patterns in comparable implementations. Record each rule or pattern with its source and scope, including relevant exceptions; resolve conflicts by instruction priority. Keep this guidance in shared context and pass the relevant parts to reviewers, children, validators, and resolvers instead of relying on inherited conversation history.
Select
```
compact
```
only for one clearly local, simple, low-risk, self-contained responsibility that one generalist can review from one packet. Use
```
specialist
```
for authorization, security, privacy, destructive or transactional data changes, concurrency, migrations, public or cross-system contracts, backward compatibility, infrastructure, any other material risk, or uncertain classification.
File or line count may rule out
```
compact
```
but never justify it.
Assign every applicable review role to an explicit owner. For substantial UI or state changes with substantial tests, give product behavior and test protection separate focused assignments, with frontend interaction covered where applicable. Combine compatible roles for small, coherent assignments.
Return one review plan containing: shared context with the review source and target, exactly one selected mode and reason, changed behavior or contracts, entry points,
```
Available validation evidence
```
, and applicable guidance; reviewer routing that maps each packet to its assigned review roles, known applicable domain skills, and any model escalation with its reason; and assignment packets that contain only a coherent responsibility and relevant code or context.
Give
```
compact
```
exactly one packet covering every change. Give
```
specialist
```
one named packet per specialist, overlapping only for cross-target behavior. Keep the selected mode in shared context. Do not copy nested-assignment lifecycle markers such as
```
internal
```
or direct-execution restrictions into first-level packets or routing; they apply only where the child or validator instructions explicitly require them.
Return planning output only; do not spawn reviewers or report findings and guesses.

使用一个
```
fork_turns="none"
```
的 subagent 执行此
```
internal
```
规划任务，以识别审查来源：branch、commit、pull request 或未提交更改。向其提供编排器已经掌握的适用全局说明和用户说明，以及 subagent 模型选择策略。除非用户另有指定，只要存在未提交更改，就审查所有未提交更改；否则，获取远程默认 branch，并基于新获取的远程跟踪 ref 审查整个当前 branch。
收集变更代码的适用指导：全局用户说明、根目录和嵌套目录中的代码仓库说明、相关文档和工具配置，以及领域 skill。检查邻近代码和共享辅助函数，以了解可比实现中已确立的模式。记录每项规则或模式的来源和适用范围，包括相关例外；按照指令优先级解决冲突。将这些指导保留在共享上下文中，并将相关部分传给审查者、子 Agent、验证者和问题解决者，而不是依赖继承的对话历史。
仅当某项职责明确局部、简单、低风险且自包含，可由一名通才通过一个任务包完成时，才选择
```
compact
```
。对于授权、安全、隐私、破坏性或事务性数据更改、并发、迁移、公共或跨系统契约、向后兼容性、基础设施、任何其他重大风险或分类不确定的情况，使用
```
specialist
```
。
文件或行数可以排除
```
compact
```
，但绝不能成为选择
```
compact
```
的理由。
为每个适用审查角色指定明确负责人。对于同时包含大量测试的大规模 UI 或状态更改，将产品行为和测试保护分别分配给聚焦任务，并在适用情况下覆盖前端交互。对于小型且连贯的任务，可以合并兼容角色。
返回一份审查计划，其中包含：共享上下文，包括审查来源和目标、恰好一种选定模式及其原因、变更后的行为或契约、入口点、
```
Available validation evidence
```
和适用指导；审查者路由，将每个任务包映射到其分配的审查角色、已知适用的领域 skill，以及任何模型升级及其原因；以及仅包含连贯职责和相关代码或上下文的任务包。
```
compact
```
恰好使用一个涵盖所有更改的任务包。
```
specialist
```
为每位专项审查者使用一个命名任务包，仅在跨目标行为上重叠。将选定模式保留在共享上下文中。不要将
```
internal
```
或直接执行限制等嵌套任务生命周期标记复制到第一层任务包或路由中；这些标记仅适用于子 Agent 或验证者说明明确要求的情况。
仅返回规划输出；不要派生审查者，也不要报告发现或猜测。

Step 2: Assign reviewers and perform review

第 2 步：分配审查者并执行审查

For
```
compact
```
, build one launch envelope from the shared context, routing, and single packet, then spawn one fresh compact reviewer. If its candidate list is nonempty, spawn one fresh final finding validator with the exact candidate list and IDs, packet code scope, prior evidence, applicable guidance, and validator instructions. Preserve the reviewer's completed and incomplete scope.
For
```
specialist
```
mode, build one launch envelope per routed packet and spawn one fresh subagent per selected specialist, in batches when necessary to leave capacity for specialist-owned children.
Collect validated reviewer reports and reproduction results. If new context or expertise can settle unresolved IDs, give one fresh resolver with
```
fork_turns="none"
```
only those candidate IDs, all prior evidence, and applicable guidance with its sources, scope, and exceptions. Never rerun the reviewer assignment, repeat a completed reproduction, or revisit confirmed and rejected IDs. Otherwise preserve them as an incomplete review.

对于
```
compact
```
，根据共享上下文、路由和单一任务包构建一个启动信息包，然后派生一名全新的精简审查者。如果其候选项列表非空，则派生一名全新的最终发现验证者，并向其提供带有 ID 的确切候选项列表、任务包代码范围、已有证据、适用指导和验证者说明。保留审查者已完成和未完整的范围。
对于
```
specialist
```
模式，为每个路由后的任务包构建一个启动信息包，并为每位选定的专项审查者派生一名全新的 subagent；必要时进行分批处理，以留出足够容量供专项审查者派生子 Agent。
收集经过验证的审查报告和复现结果。如果新的上下文或专业知识能够解决未确定的 ID，则派生一名全新的问题解决者，使用
```
fork_turns="none"
```
，且只处理这些候选 ID、全部已有证据，以及适用指导及其来源、范围和例外。绝不重新执行审查者任务、重复已完成的复现，或重新审视已确认和已否决的 ID。否则，将其保留为不完整审查。

Step 3: Produce final review report to user

第 3 步：向用户生成最终审查报告

Build a finding ledger from every validator-confirmed stable ID and merge IDs only when they describe the same root cause. If validated reports conflict, give one fresh resolver with
```
fork_turns="none"
```
only the conflicting candidate IDs, prior evidence, and applicable guidance with its sources, scope, and exceptions before finalizing. Resolvers follow the final finding validator instructions.
Outside that conflict path, do not inspect code, rerun validation, or spawn agents during Step 3; deduplication alone never justifies a resolver.
Account for every confirmed ID exactly once as its own final finding or as a source of an explicitly merged final finding. Do not omit confirmed findings because of priority, materiality, report length, readability, or ease of cleanup; priority only controls ordering and labels.
Reconcile the ledger before responding and report a compact accounting line with confirmed review findings, final comments, duplicate merges, and omitted findings. The omitted count must be zero.
Report review target, selected mode, actual reviewers and validators used, any model escalations with their reasons, findings summary, every confirmed detailed comment, and a verified, deduplicated
```
Human review
```
section; use
```
None.
```
when no human review is required.

根据每个经验证者确认的稳定 ID 构建发现台账；仅当发现描述相同根因时合并 ID。如果经过验证的报告相互冲突，则派生一名全新的问题解决者，使用
```
fork_turns="none"
```
，且只处理相互冲突的候选 ID、已有证据，以及适用指导及其来源、范围和例外，然后完成最终整理。问题解决者遵循最终发现验证者说明。
除冲突处理路径外，在第 3 步不要检查代码、重新运行验证或派生 Agent；仅去重绝不构成派生问题解决者的理由。
每个已确认 ID 必须恰好记入一次，作为自己的最终发现或作为明确合并后的最终发现的来源。不得因优先级、重要性、报告长度、可读性或修复难度省略任何已确认发现；优先级只控制排序和标签。
响应前核对该台账，并报告一行紧凑的统计，包括已确认的审查发现数、最终评论数、重复合并数和省略发现数。省略数量必须为零。
报告审查目标、所选模式、实际使用的审查者和验证者、任何模型升级及其原因、发现摘要、每项已确认发现的详细评论，以及经过核验且去重的
```
Human review
```
部分；无需人工审查时使用
```
None.
```
。

Review roles

审查角色

Behavioral and contract

行为与契约

Review behavioral logic, state transitions, cross-file behavior, regressions, API contracts, and backward compatibility.

审查行为逻辑、状态转换、跨文件行为、回归、API 契约和向后兼容性。

Data and concurrency

数据与并发

Review data loss, invalid lifecycle transitions, transaction boundaries, idempotency, races, and production-data assumptions.

审查数据丢失、无效生命周期转换、事务边界、幂等性、竞态以及对生产数据的错误假设。

Security and vulnerability

安全与漏洞

Review concrete attacker paths, authorization mistakes, unsafe data exposure, and security consequences.

审查具体攻击路径、授权错误、不安全的数据暴露以及安全后果。

Privacy and data protection

隐私与数据保护

Review privacy violations, data leaks, and unsafe data handling.

审查隐私违规、数据泄露和不安全的数据处理。

Performance and resource usage

性能与资源使用

Review time and space complexity, algorithmic efficiency, caching, and resource management under supported workloads.

审查时间和空间复杂度、算法效率、缓存以及受支持工作负载下的资源管理。

Test and regressions

测试与回归

Review whether tests protect the intended contract, fail when that contract is removed, and cover material negative cases. Check that fixtures, mocks, and shared guards exercise the changed path and that assertions distinguish the required behavior from plausible incorrect outcomes.

审查测试是否保护预期契约、在移除该契约时是否会失败，以及是否覆盖重要的负面用例。检查 fixture、mock 和共享 guard 是否实际执行变更路径，且断言能否区分所需行为与看似合理但错误的结果。

Waste and maintainability

冗余与可维护性

Review assigned non-style dead, duplicate, temporary, or speculative code and artifacts directly.
Compact reviewers also review readability and style waste directly using applicable language, framework, and CSS skills; they do not spawn children.
Waste specialists partition the scope into non-style and style-bearing sections without reviewing style waste directly.
If non-style code exists, spawn one readability child for the combined scope. Give it the exact code scope, applicable repository and language or framework instructions, and code readability reviewer instructions; verify and merge its evidence.
If style-bearing code exists, spawn one CSS child for the combined scope. Give it the exact style scope, applicable CSS skill, and CSS waste reviewer instructions; verify and merge its evidence.

直接审查所分配范围内与样式无关的死代码、重复代码、临时代码、推测性代码及残留物。
精简审查者还应使用适用的语言、框架和 CSS skill，直接审查可读性和样式冗余；不派生子 Agent。
冗余专项审查者将范围划分为与样式无关的部分和包含样式的部分，但自身不直接审查样式冗余。
如果存在与样式无关的代码，为合并后的范围派生一名可读性子 Agent。向其提供确切的代码范围、适用的代码仓库说明以及语言或框架说明，并提供代码可读性审查者说明；验证并合并其证据。
如果存在包含样式的代码，为合并后的范围派生一名 CSS 子 Agent。向其提供确切的样式范围、适用的 CSS skill 和 CSS 冗余审查者说明；验证并合并其证据。

Code readability reviewer instructions

代码可读性审查者说明

Perform this internal assignment directly without invoking code-review orchestration or spawning children; review only the supplied code scope.
Follow the supplied repository and applicable language or framework instructions.
Find code whose intent or execution order is materially obscured by dense expressions, nesting, mixed abstraction levels, misleading names, or unnecessary indirection. Treat these as signals, not an exhaustive checklist.
Recommend the smallest correction that preserves behavior and supported performance characteristics. Report proven convention violations even in simple code; do not report personal formatting preferences.
Report checked scope and actual findings with exact locations and supporting evidence; return "No issues found." when none exist.

直接执行此
```
internal
```
任务，不调用代码审查编排，也不派生子 Agent；仅审查所提供的代码范围。
遵循所提供的代码仓库说明以及适用的语言或框架说明。
查找其意图或执行顺序因密集表达式、深层嵌套、混合抽象层级、误导性名称或不必要间接层而被实质掩盖的代码。视这些为信号，而非穷尽式检查清单。
推荐在保持行为和受支持性能特征的前提下所需的最小修正。即使在简单代码中，也要报告已证实的约定违规；不要报告个人格式偏好。
报告已检查范围和实际发现，并附精确位置和支持证据；没有发现时返回 "No issues found."。

CSS waste reviewer instructions

CSS 冗余审查者说明

Perform this internal assignment directly without invoking code-review orchestration or spawning children; review only the supplied style scope.
Follow the applicable CSS skill and repository browser targets, build configuration, resets, and nearby styling context.
Find dead or duplicate selectors and declarations.
Find declarations proven ineffective by the cascade, inheritance, or layout context.
Find repeated global or base styles and compatibility workarounds outside declared browser targets.
Report checked scope and actual findings with exact locations and supporting evidence; return "No issues found." when none exist.

直接执行此
```
internal
```
任务，不调用代码审查编排，也不派生子 Agent；仅审查所提供的样式范围。
遵循适用的 CSS skill，以及代码仓库的浏览器目标、构建配置、reset 和邻近样式上下文。
查找无用或重复的 selector 和 declaration。
查找已证明因层叠、继承或布局上下文而无效的声明。
查找重复的 global 或 base 样式，以及声明的浏览器目标范围之外的兼容性变通方案。
报告已检查范围和实际发现，并附精确位置和支持证据；没有发现时返回 "No issues found."。

Frontend and user experience

前端与用户体验

Review user-visible states, accessibility, interaction behavior, layout risks, and visual regressions. Follow keyboard focus and visible feedback through state changes, including asynchronous responses and replacement controls.

审查用户可见状态、无障碍性、交互行为、布局风险和视觉回归。跟踪状态变化中的键盘焦点和可见反馈，包括异步响应和替换控件。