用途：以资深 QA 负责人/架构师身份，对同事已完成的拉取请求（PR）中的测试自动化工作给出同行评审反馈，而非充当 linter 或挑刺工具。每条发现都需可追溯：来自 diff 的具体行、技能/规范文件的章节，或明确标注为个人意见。
主要能力：先做严格度预检（Flexible / Standard / Strict），再读取 diff；加载目标仓库自身的规范（若其自带 AGENTS.md、.agents/skills/、.context/ 等），无则回退到本仓库 KATA 约定并明确说明；将发现归入 Real/Reliability、Pattern/Doctrine-deviation、Positive 三类，并附 Critical/Major/Minor/Trivial 严重度；始终填充 Positive 桶；输出发现表格、亮点与 10 分制评分作为检查点，允许用户当场重新分类与调整严重度；默认按 praise → constructive → praise 结构起草反馈。
使用方式：按 Step 0 至 Step 7 流程执行。读取实际 diff 而非 PR 描述；大型 PR 用 gh api repos/<owner>/<repo>/pulls/<N>/files --paginate 分页获取逐文件补丁，并先看提交标题以排除无关批量同步提交；大 PR 可依 briefing-template.md 与 dispatch-patterns.md 派发子代理读取文件。发布时本仓库用 gh pr comment <N> --body-file <path>，外部仓库加 --repo <owner>/<repo>。
适用场景：需要针对 KATA/QA 规范、有证据链与校准严重度的已完成 PR 反馈。与 /judgment-day（盲审通过/升级判定）、/code-review（评审自身未提交改动）、/git-flow-master（开 PR、管分支）互补。
限制：未获 Step 7 明确确认不得发布评论，同一会话中针对其他 PR 的先前批准不适用；不得将起草或发布反馈委派给子代理；不得把无文件章节引用的“最佳实践”表述为仓库要求；Flexible/Standard 下模式偏差仅为观察，不得像真实缺陷那样影响评分；不得从本工作流串联 /sdd-* 技能，若 PR 确需框架级流程应指向 /framework-development；发布评论默认使用英文，除非用户指定其他语言。依赖 agentic-qa-core，并按需加载其 references 文件。