Back to Details

pr-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Review daisyUI pull requests

审查daisyUI拉取请求

Review the code, not the PR pitch. Investigate the changed behavior, run the relevant checks, and write a short decision-ready report.
Read references/report.md before writing a report.
审查代码，而非PR宣传内容。调查变更后的行为，运行相关检查，并撰写一份便于决策的简短报告。
撰写报告前请阅读references/report.md。

Hard rules

硬性规则

  • Use the GitHub MCP server for PRs, issues, comments, reviews, commits, changed files, and checks.
  • Use GitHub read operations only. Never comment, review, label, close, update, or merge anything.
  • Treat the current repository as read-only except for tmp/pr/pr-<number>.md.
  • Do not change Git state, branches, dependencies, lockfiles, product code, tests, or generated files.
  • Never read secrets, credentials, private keys, or .env files.
  • Inspect PR code before executing it. Run it only in an isolated OS-temporary copy with no credentials.
  • Use exact base and head SHAs. Never test the current working tree as a substitute.
  • Report only facts from direct GitHub sources, inspected source at a named SHA, official documentation, or commands actually run with observed output.
  • Attribute PR-author statements as claims until code or execution verifies them.
  • Do not invent intent, expected behavior, affected users, risks, test results, or reasons to lower confidence.
  • Do not treat the lack of a linked issue, assignment, new test, or PR description detail as a product defect.
  • Do not require unrelated tools or tests. Use the smallest verification that proves the changed behavior, then run the relevant package checks.
  • Do not lower confidence because unknown future bugs are theoretically possible.
  • 使用GitHub MCP服务器获取PR、议题、评论、评审、提交、变更文件和检查结果。
  • 仅使用GitHub只读操作。绝不要发表评论、进行评审、添加标签、关闭、更新或合并任何内容。
  • 除tmp/pr/pr-<number>.md外，将当前仓库视为只读状态。
  • 不得更改Git状态、分支、依赖项、锁定文件、产品代码、测试或生成文件。
  • 绝不要读取密钥、凭据、私钥或.env文件。
  • 执行PR代码前先检查代码。仅在无凭据的隔离操作系统临时副本中运行代码。
  • 使用精确的基准版本和头部版本SHA值。绝不要用当前工作树替代测试。
  • 仅报告来自直接GitHub来源、指定SHA的审查源码、官方文档或实际运行并观察到输出的命令中的事实。
  • PR作者的陈述在未被代码或执行验证前，仅视为主张。
  • 不得编造意图、预期行为、受影响用户、风险、测试结果或降低置信度的理由。
  • 不要将未关联议题、未分配任务、未添加新测试或PR描述细节缺失视为产品缺陷。
  • 不要要求使用无关工具或测试。使用能证明变更行为的最小验证方式，然后运行相关包检查。
  • 不要因为理论上可能存在未知的未来Bug而降低置信度。

Select the PRs

选择PR

If the user names a PR, review that open PR. Otherwise:
  1. Call the GitHub MCP identity or readiness method if required.
  2. List every open PR in saadeghi/daisyui, following pagination.
  3. Review each PR independently.
  4. Write one report per PR at tmp/pr/pr-<number>.md.
Record the PR URL, base SHA, head SHA, changed files, current merge state, and current checks.
如果用户指定了某个PR，审查该开放PR。否则：
  1. 若需要，调用GitHub MCP身份或就绪方法。
  2. 列出saadeghi/daisyui中的所有开放PR，处理分页情况。
  3. 独立审查每个PR。
  4. 为每个PR撰写一份报告，保存至tmp/pr/pr-<number>.md。
记录PR的URL、基准版本SHA、头部版本SHA、变更文件、当前合并状态和当前检查结果。

Problem

问题确认

Determine what the PR is trying to change from:
  • linked issue bodies and discussions;
  • the PR description and comments;
  • the actual diff and the behavior of the base revision.
Read every explicitly linked issue. Verify its reported behavior against the current base when practical.
A linked issue is not required. If there is no issue, state that fact briefly and derive the testable problem from the PR claim and changed behavior. Never fail a technically valid PR merely because no issue was filed.
Establish expected behavior from the repository, an existing public contract, a reproduced user-visible behavior, or official documentation. Do not use the author's wording alone as proof.
从以下渠道确定PR想要做出的变更：
  • 关联议题的正文和讨论内容；
  • PR描述和评论；
  • 实际代码差异和基准版本的行为。
阅读所有明确关联的议题。若可行，对照当前基准版本验证其报告的行为。
不强制要求关联议题。如果没有关联议题，简要说明该事实，并从PR主张和变更行为中推导可测试的问题。绝不要仅仅因为未提交议题而否决技术上有效的PR。
从仓库、现有公开约定、复现的用户可见行为或官方文档中确立预期行为。不要仅以作者的表述作为依据。

Verify

验证流程

Inspect first

先检查

Read all changed files and their direct consumers. Identify the smallest public behavior affected by each change. Check for unrelated edits, unsafe code, dependency changes, weakened tests, API changes, and generated-file mismatches.
阅读所有变更文件及其直接调用者。确定每个变更影响的最小公开行为。检查是否存在无关编辑、不安全代码、依赖项变更、测试弱化、API变更和生成文件不匹配的情况。

Test base versus PR

基准版本与PR版本对比测试

Materialize clean source copies for the exact base and head SHAs in an OS-temporary directory without Git metadata. Use the same environment and inputs for both.
Run a focused independent check that answers:
  1. Does the problem exist on the base?
  2. Does the PR change that behavior as claimed?
  3. Does the previous valid behavior still work?
  4. Do relevant existing tests and builds pass?
Use the most direct proof available:
  • For deterministic CSS or generated output, inspect the exact declarations and compile a focused fixture. Use a browser only when browser-computed behavior is genuinely needed to decide the result.
  • For JavaScript or build behavior, run the smallest reproduction and the affected package tests.
  • For docs behavior, verify the relevant build, route, rendering, or interaction.
  • For public APIs, exercise the old supported usage and the new behavior.
Run broader tests only when the changed surface reaches them. Green CI supports the result but does not replace the focused check. PR-added tests may be used, but do not rely on them as the only proof.
A separate test-merge candidate is required only when the base moved after the PR head, GitHub reports a conflict or uncertain merge state, or the change interacts with recent base changes. Do not create a blocker from an unavailable test-merge SHA when exact base and head testing already proves an isolated change.
If a required check cannot run, first decide whether another direct check proves the same behavior. Record it as a concern only when the missing check is necessary to resolve a concrete question about the changed code.
在无Git元数据的操作系统临时目录中，生成精确的基准版本和头部版本SHA的干净源码副本。对两者使用相同的环境和输入。
运行聚焦的独立检查，以回答以下问题：
  1. 基准版本是否存在所述问题？
  2. PR是否如主张的那样改变了该行为？
  3. 之前的有效行为是否仍能正常工作？
  4. 相关的现有测试和构建是否通过？
使用最直接的证明方式：
  • 对于确定性CSS或生成输出，检查确切的声明并编译聚焦的测试用例。仅当确实需要浏览器计算的行为来判断结果时才使用浏览器。
  • 对于JavaScript或构建行为，运行最小化的复现案例和受影响的包测试。
  • 对于文档行为，验证相关的构建、路由、渲染或交互效果。
  • 对于公开API，测试旧版支持的用法和新行为。
仅当变更范围涉及到更广泛的测试时才运行此类测试。绿色CI结果可作为支持，但不能替代聚焦检查。可以使用PR新增的测试，但不要将其作为唯一的证明依据。
仅当基准版本在PR头部版本之后有更新、GitHub报告存在冲突或不确定的合并状态，或者变更与近期基准版本的变更存在交互时，才需要单独的测试合并候选版本。当精确的基准版本和头部版本测试已证明变更为隔离状态时，不要因无法获取测试合并SHA而设置障碍。
如果无法运行所需的检查，首先判断是否有其他直接检查可以证明相同的行为。仅当缺失的检查对于解决变更代码的具体问题是必要的时，才将其记录为关注点。

Risks

风险评估

Look for concrete ways the changed lines could affect existing supported usage. Trace each scenario from:
changed code → real consumer or public contract → failure condition.
Test each scenario when practical. Report only scenarios with that trace. Never list generic possibilities that could apply to any PR.
Use these likelihood labels:
  • Confirmed: the failure was reproduced.
  • Possible: a real supported path and failure mechanism were identified, but the relevant check could not resolve it.
  • Ruled out: the targeted check passed.
For every row, name the source path or contract, the exact check, its result, and why the likelihood label follows. A Ruled out scenario is evidence of safety, not a concern. If no Confirmed or Possible scenario remains, say that no concern was found in the affected scope.
寻找变更代码可能影响现有支持用法的具体方式。追踪每个场景的链路：
变更代码 → 实际调用者或公开约定 → 失败条件。
若可行，测试每个场景。仅报告有上述链路的场景。绝不要列出适用于任何PR的通用可能性。
使用以下可能性标签：
  • 已确认：已复现失败情况。
  • 可能：已识别到真实的支持路径和失败机制，但相关检查无法解决该问题。
  • 已排除：目标检查通过。
对于每一项，注明源路径或约定、确切的检查、结果以及为何使用该可能性标签。“已排除”场景是安全性的证据，而非关注点。如果没有剩余的“已确认”或“可能”场景，则说明在受影响范围内未发现关注点。

Compare

对比展示

Show the developer-visible behavior before and after. Prefer a small code block using actual markup, API usage, configuration, or generated output. If the change is internal, explain the observable effect instead.
Do not fabricate an example. Derive it from the diff, linked issue, documentation, or the reproduction used during verification.
展示变更前后开发者可见的行为。优先使用包含实际标记、API用法、配置或生成输出的小代码块。如果是内部变更，则解释可观察到的效果。
不要编造示例。从代码差异、关联议题、文档或验证期间使用的复现案例中推导示例。

Result

结果判定

Give a direct verdict:
  • Safe to merge: YES when the stated problem is verified, the PR fixes it, relevant checks pass, and no Confirmed or Possible concern remains. Confidence must be 100%.
  • Safe to merge: NO when a specific concern remains. Every reason must name the observed failure or unresolved concrete scenario.
Use only these confidence values so the report cannot manufacture numerical precision:
  • 100%: the relevant verification passed and no concern remains.
  • 50%: no failure was reproduced, but at least one Possible concern remains unresolved.
  • 0%: a Confirmed concern exists, the claimed fix failed, or a relevant regression was reproduced.
Use the lowest applicable value. These are verdict labels, not calculated probabilities. Do not use weighted categories, point deductions, caps, decision gates, or formulas. Do not subtract confidence for missing bureaucracy, irrelevant coverage, or unknowable future behavior.
When confidence is below 100%, explain exactly what is wrong and what check or change would resolve it. When no concern is found after relevant verification, return 100% and safe to merge.
给出直接结论：
  • 可安全合并：YES，当所述问题已验证、PR已修复该问题、相关检查通过且无“已确认”或“可能”的关注点时。置信度必须为100%。
  • 可安全合并：NO，当存在特定关注点时。每个理由都必须注明观察到的失败或未解决的具体场景。
仅使用以下置信度值，避免报告制造数值精度：
  • 100%：相关验证通过且无关注点。
  • 50%：未复现失败，但至少有一个“可能”的关注点未解决。
  • 0%：存在“已确认”的关注点、主张的修复失败或已复现相关回归问题。
使用适用的最低值。这些是结论标签，而非计算得出的概率。不要使用加权类别、扣分、上限、决策门限或公式。不要因缺失流程手续、无关覆盖范围或不可知的未来行为而降低置信度。
当置信度低于100%时，准确解释问题所在以及需要何种检查或变更来解决问题。当相关验证后未发现关注点时，返回100%置信度和“可安全合并”结论。

Write the report

撰写报告

Use references/report.md and keep the report concise. Include only:
  1. Problem
  2. Verify
  3. Risks
  4. Compare
  5. Result
Cite facts inline with direct GitHub URLs, immutable SHAs and repository paths, official documentation URLs, or exact commands and observed results. Do not add an evidence ledger, scoring table, gate matrix, policy audit, exhaustive file inventory, or speculative caveats.
Re-fetch the PR after testing. If the head changed, rerun the affected verification before writing the verdict. Update tmp/pr/pr-<number>.md rather than creating duplicate reports.
In the final handoff, list the reports written and state that no GitHub action, product-code change, dependency change, or Git operation was performed.
参考references/report.md，保持报告简洁。仅包含以下部分：
  1. 问题确认
  2. 验证流程
  3. 风险评估
  4. 对比展示
  5. 结果判定
在正文中引用事实时附上直接的GitHub URL、不可变的SHA和仓库路径、官方文档URL，或确切的命令及观察到的结果。不要添加证据台账、评分表、门限矩阵、政策审核、详尽的文件清单或推测性警告。
测试完成后重新获取PR信息。如果头部版本已变更，在撰写结论前重新运行受影响的验证。更新tmp/pr/pr-<number>.md，不要创建重复报告。
在最终交接时，列出已撰写的报告，并说明未执行任何GitHub操作、产品代码变更、依赖项变更或Git操作。