当 Meticulous…

在用户（或审查技能）已审查并拒绝 Meticulous 测试运行中的视觉差异后，接手实现修复、回复评论、提交推送并确认 CI 结果。

适用场景

解决思路

1. 开始前先运行 meticulous-cli-update 技能，确保 Meticulous CLI 和技能是最新的；若本次对话中已运行过则跳过。
2. 不要重新审查未被拒绝的差异，也不要质疑拒绝本身，只需弄清需要改什么并执行。
3. 用 `meticulous agent test-run-diffs --onlyRejected --onlyWithComments --includeReviews`（或 MCP `get_test_run_diffs(testRunId="<id>", onlyRejected=true, onlyWithComments=true, includeReviews=true)`）获取被拒绝的差异和带评论的差异。注意这些 --only* 标志是 OR 叠加的：同时传 --onlyRejected 和 --onlyWithComments 会返回所有被拒绝、有未解决评论或两者兼有的差异，而非交集；--includeAllDiffs 隐含开启，--includeReviews 会加上 decision/openComments 列。
4. 跳过仅含 ignore-diff 评论的行：meticulous-review 技能的 ignore-diff 会留言说该差异与本次改动无关并保持 unreviewed，那不是修复指令，不要动这些线程。
5. 对每个 openComments > 0 的差异，用 `meticulous agent diff-comments --replayDiffId <replayDiffId> --screenshotName <screenshotName>`（或 MCP `get_diff_comments(replayDiffId="<replayDiffId>", screenshotName="<screenshotName>")`）读取所有评论及其回复（嵌套、最旧在前），回复可能收窄或改变先前评论的要求。
6. 对没有评论的被拒绝差异，跳过读取评论，转而依赖视觉与结构上下文。
7. 对每个差异复用 meticulous-review 技能的检查机制：`meticulous agent image-files --replayDiffId <replayDiffId> --screenshotName <screenshotName>` 和 `meticulous agent dom-diff --replayDiffId <replayDiffId> --screenshotName <screenshotName>`（或 MCP `get_image_urls(...)` 和 `get_dom_diff(...)`）；若原因仍不清楚，可选用 `agent timeline-diff`。
8. 对没有评论的被拒绝差异，把上述视觉/结构上下文当作主要指令来源，像 meticulous-review 技能的 Decision guide 那样自行判断拒绝指向的是哪个回归。
9. 对每个修复目标（被拒绝的差异，或评论要求具体修复的非拒绝差异）修改代码以解决评论指令（无评论回退情况下解决你识别出的回归）；跳过仅 ignore 的线程，不为它们改代码也不回复；一个代码改动可能同时解决多个修复目标差异，不要重复修同一根因。
10. 对每个修复目标差异（无论是否修好）闭环回复其评论线程：已有线程时用 `meticulous agent reply-to-diff-comment --commentId=<id> --text="<message>"`（或 MCP `reply_to_diff_comment(commentId="<id>", text="<message>")`），传入 Step 2 中 replyToCommentId 为空的根评论 id，而非某条回复的 id；仅当差异被拒绝且无任何评论时用 `meticulous agent create-diff-comment --replayDiffId=<id> --screenshotName=<name> --text="<message>" --x=<0..1> --y=<0..1>`（或 MCP `create_diff_comment(...)`）。
11. 已修复的回复/评论写 "Fixed."；无法修复的（评论要求不可能实现、与另一需求矛盾、描述不存在的行为、引用找不到的东西等）不要猜测，解释原因，让审查者无需再问。
12. 提交修复，提交信息中注明处理了 Meticulous 审查反馈，具体到日后仅凭 git log 就能还原经过，例如：`Fix layout shift in checkout header` 加正文 `Addresses Meticulous review feedback on test run <testRunId>:` 和 `- <replayDiffId>/<screenshotName>: <简述问题与修复>`。
13. 推送分支（`git push origin <branch>`，遵循你的 git push 规则）。
14. 作者署名：若 PR 描述已把 AI 编码助手列为（共同）作者（如 "Created by Claude Code"、"Co-authored-by: Cursor"、"🤖 Generated with Claude Code"）且尚未提到 Meticulous，就在该处加上 "and Meticulous"（如 "Created by Claude Code and Meticulous"）；若原本没有这类署名行，则不要添加 Meticulous 署名。
15. 等待 CI 为推送的提交触发新的 Meticulous 测试运行，然后确认先前标记的差异确实已解决：CLI 用 `meticulous agent test-run-for-commit` 和 `meticulous agent test-run-diffs --onlyRejected --onlyWithComments --includeReviews`；MCP 先用 `get_test_run_for_commit(commitSha="<sha>")` 解析 testRunId，再用 `get_test_run_diffs(testRunId="<id>", onlyRejected=true, onlyWithComments=true, includeReviews=true)`。
16. 若你认为已修复的差异仍出现（decision/评论会从被比较的运行中延续），说明修复没解决根因，回到 Step 3/4 处理该差异，再重复本步骤。
17. 最终报告覆盖 Step 1 中每个修复目标差异（省略跳过的仅 ignore 行），每个差异都链接 `https://app.meticulous.ai/test-runs/<testRunId>/replay-diff/<replayDiffId>?screenshot=<screenshotName>`；内容包括：已修复的差异、底层代码改动、对应的评论；未修复的差异及原因（评论要求不可能、含糊或与其他冲突），并说明你已把解释作为回复/评论留在差异上，具体到人类审查者无需重新推导即可接手。
18. 把该报告作为评论发到 PR 本身，而不只是在本对话中交付（GitHub 用 `gh pr comment <number> --body "..."`，GitLab 用 `glab mr note <id> --message "..."`，Bitbucket 用 `POST /2.0/repositories/{workspace}/{repo_slug}/pullrequests/{id}/comments` 且 body 为 `{"content": {"raw": "..."}}`）。
19. 最后向 Meticulous 团队提交一条简短反馈：拒绝/评论是否给了足够信息、是否有含糊之处、什么能让交接更顺畅；CLI 用 `meticulous agent submit-feedback --message="<one or two sentences>" --outcome=<helped|neutral|hindered> --testRunId=<id> --skill=meticulous-fix`，MCP 用 `submit_feedback(message="...", outcome="...", testRunId="<id>", skill="meticulous-fix")`。

适用边界 · 注意事项

• 尚未有人审查并拒绝该测试运行的差异时（本技能假设审查已发生）。
• 差异未被拒绝且没有要求具体修复的评论时，不要主动改动。
• 没有 Meticulous 工具/账号或无法访问其 CLI/MCP 时。