# /review 技巧（公关综合审核） ## 目的全面审查 Next.js 16 + Supabase + Stripe + Playwright 代码库 PR 并确定是否可以合并。 ## 调用 /review [所有者/存储库] [pr-number] [--focus ] /review --local [--focus <方面>] ### 参数论点|必填|描述 ---|---|--- `所有者/仓库` |是* | GitHub 存储库（例如“my-org/ppt-trans”） `pr 编号` |是* |公关号码 `--本地` |没有 |检查本地差异（用于在创建 PR 之前进行自我检查） `--焦点` |没有 |限制要执行的审查视角（默认值：“all”） *指定“--local”时不需要“owner/repo”和“pr-number” ### \--焦点选项价值|代理执行|使用案例 ---|---|--- `全部` |全部 5 名代理商 |正常PR审核（默认） `安全` |安全代码审阅者 |更改身份验证/授权/Stripe 时 `性能` |绩效审核员 |更改 N+1/cache/PPTX 处理时 `qa` |测试覆盖率评审员 |更改测试文件时 `文档` |文档准确性审阅者 |更改 env/README/CLAUDE.md 时 `类型` |代码质量审查员 |更改类型定义/API 时 ### \--本地选项（本地审核） /review --local [--focus <方面>] 创建 PR 之前检查本地差异： * 自动检测基础分支（按优先级顺序如下） * 未发布 PR 评论（仅限终端输出） * 全面审查或仅限于“--focus” **基础分支自动检测（按优先级顺序）：** 1. `git symbolic-ref refs/remotes/origin/HEAD` → 默认分支 2. 如果`main`存在，则`main` 3. 如果`master`存在则`master` 4. 如果“develop”存在，则“develop” 5. 什么对 `git merge-base HEAD ` 有效 ### 示例 # 所有视角审核（默认） /回顾我的组织/ppt-trans 123 # 仅限安全 /review my-org/ppt-trans 123 --焦点安全 # 仅性能 /review my-org/ppt-trans 123 --focus 性能 # 本地差异的全面审查 /评论--本地 # 仅本地差异安全审查 /review --local --focus 安全 ## 输出合约（需要输出） 1.总结（2-4行） 2. **清单覆盖范围**（必须 - 始终输出）： ### 检查表覆盖范围（必须检查 v1.0） |域名 |状态 | |--------|--------| |苏帕巴斯| ✅ 好的 / ⚠️ 需要确认 / ❌ NG / N/A | |管道| ✅ / ⚠️ / ❌ / 不适用 | |环境/秘密 | ✅ / ⚠️ / ❌ / 不适用 | |测试 | ✅ / ⚠️ / ❌ / 不适用 | |条纹| ✅ / ⚠️ / ❌ / 不适用 | 3. 阻碍因素（每个：为什么 + 哪里 + 修复 + **证据**） 4. 建议（**需要证据**置信度>=75） 5. 值得拥有的 6.合并决策： * ✅ 合并 * ⚠️ 与后续合并（后续列表） * ❌ 需要更改（阻止列表） ### 证据规则（必须） **始终**为结果添加证据，置信度 >= 75： * 文件路径+行号 * **此外** grep/diff 片段或相关代码引用示例： - [confidence=85] 缺少 RLS 策略 (supabase/migrations/xxx.sql:15) 证据： `grep -n "CREATE POLICY" supabase/migrations/xxx.sql` → 无结果 ## 护栏 * 不要在日志/评论中发布秘密信息（env值、密钥、令牌） *拦截器仅限于那些实际导致错误/漏洞/数据丢失/计费错误/不稳定 CI 的拦截器。 * 提出大规模重构作为后续问题 ** ** ## 工作流程 ### 第 0 阶段：初步信息收集 1. **加载项目规则** * 阅读`CLAUDE.md` * 提取的项目： * Stack（Next.js 16、React 19、Supabase、Stripe、Playwright） * 编码规则（任何禁止的、服务器操作首选、架构优先） * 安全策略（RLS、速率限制、CSRF） * 测试策略（UNIFIED_TEST_CONFIG，MVP范围） 2. **加载审核清单** * 阅读 `.claude/review-checklists/README.md` * 阅读 `.claude/review-checklists/must-check.md` * 记录版本（例如`v1.0`） 3. **公关信息获取** **\--本地选项（稳健的 BASE 检测）：** # 0) 预取（即使失败也继续） git fetch origin --prune --tags >/dev/null 2>&1 ||真实 # 基础分支自动检测（安全地循环）基地=“” # 1) 从origin/HEAD获取默认分支如果 git symbolic-ref -q refs/remotes/origin/HEAD >/dev/null 2>&1;然后 BASE="$(git symbolic-ref refs/remotes/origin/HEAD | sed 's|refs/remotes/origin/||')" 菲 # 2) 后备候选者（主要 → 主控 → 开发）如果[-z“$BASE”];然后对于主开发中的b；如果 git show-ref -q "refs/remotes/origin/$b";然后基数=“$b” 打破菲完成菲 #3）最后的手段 [ -z "$BASE" ] && BASE="main" echo“基础分支：$BASE” # 4) 先确认目标文件顺序（减少审阅负担） CHANGED_FILES=$(git diff --name-only "origin/$BASE...HEAD") echo“更改的文件：” 回显“$CHANGED_FILES” # 5）区域确定（如果只有docs/，则将security/perf设置为N/A等）如果回显“$CHANGED_FILES”| grep -qv '^文档/';然后 # 代码更改 → 从各个角度进行审查 git diff "origin/$BASE...HEAD" 否则 # docs/ only → 仅文档视角 echo“检测到仅文档更改，重点关注文档审查” 菲 **正常（所有者/回购 PR#）：** gh pr view --repo --json 标题、正文、作者、标签、文件、添加、删除、url gh pr diff --repo 4. **公关摘要创建** * 变更的目的（第 1-2 行） * 影响范围（UI/API/DB/Billing/Auth/PPTX/E2E） * 风险标记（架构更改、身份验证更改、计费更改、文件处理） ### 第 1 阶段：代理并行执行 **\根据 --focus 选项选择代理** : \--焦点 |执行代理人 ---|--- `全部`（默认）|所有 5 个代理并行 `安全` |仅限安全代码审查者 `性能` |仅限绩效审核员 `qa` |仅限测试覆盖率审阅者 `文档` |仅限文档准确性审阅者 `类型` |仅限代码质量审查者 **所有代理名单**：代理|子代理类型 |职责 ---|---|--- 代码质量审查员 |代码质量审查员 |代码质量、设计和类型安全绩效审核员 |绩效审核员 |性能/N+1/缓存安全代码审阅者 |安全代码审阅者 | RLS/Webhook/IDOR/XSS 测试覆盖率评审员 |测试覆盖率评审员 |剧作家决定论/模拟报道文档准确性审阅者 |文档准确性审阅者 |环境、过程和措辞的一致性 **实施说明**： * 如果`--focus all`或未指定，所有5个代理将**并行**任务 * 当指定`--focus `时，只执行对应的agent **每个代理的常见提示：** ## 上下文 - 堆栈：Next.js 16 + React 19 + TypeScript + Supabase + Stripe + Playwright - 项目规则：[CLAUDE.md 摘要] - PR 总结：[第 0 阶段总结] - 更改的文件：[文件列表] ## 优先级检查（ppt-trans 特定） - Next.js 16：params：Promise 的正确实现 - 如何使用服务器操作与 API 路由 - 模式优先开发（openapi.yaml 优先） - Supabase RLS、snake_case 类型、类型再生 - E2E：参见 UNIFIED_TEST_CONFIG，禁止硬编码 ### 第 2 阶段：自动检查（推荐）如果可能，请执行以下操作并将结果包含在审核正文中： npm run type-check # 类型检查 npm run lint # lint npm run test #测试影响范围结果格式： * ✅ 成功 * ❌失败（错误详细信息） * ⏭️未执行（原因） ###阶段2.5：安检门自动检测（三）对 PR 差异中包含的文件自动执行以下操作。仅那些可通过 grep base 检测到的。 #### Gate 1：错过了 PerformSecurityChecks() 调用 # 检测不调用performSecurityChecks的PR差异API Route文件 # 白名单：webhook（自签名验证）、运行状况、测试端点 for f in $(git diff --name-only "origin/$BASE...HEAD" | grep 'src/app/api/.*/route\.ts');做如果！ grep -q“performSecurityChecks”“$f”；然后 basename_dir=$(目录名 "$f" | sed 's|src/app/api/||') # 白名单检查案例“$basename_dir” stripe/webhook|health|test/*) 继续 ;; *) echo "缺少执行安全检查: $f" ;; 埃萨克菲完成 **输出**：如果存在泄漏，请将其报告为阻止程序（置信度=90） #### Gate 2：新表RLS策略存在确认 # 检测到有 CREATE TABLE 但没有 CREATE POLICY 的 PR 差异迁移 for f in $(git diff --name-only "origin/$BASE...HEAD" | grep 'supabase/migrations/.*\.sql');做表=$(grep -oP '创建表(?:IF NOT EXISTS)?(?:public\.)?\K\w+' "$f" 2>/dev/null) 对于 $tables 中的 t；做如果！ grep -q "创建策略.*ON.*$t" "$f";然后 echo "缺少 RLS: 表=$f 中的 $t" 菲完成完成 **输出**：如果存在泄漏，请将其报告为阻止程序（置信度=95） #### Gate 3：检测到 SecurityMonitor.logEvent() 未安装 # 检测到一个具有安全相关代码路径的文件 (reject/error/401/403)，但 PR 差异中没有 logEvent for f in $(git diff --name-only "origin/$BASE...HEAD" | grep -E '\.(ts|tsx)$');做 # 是否包含安全判断代码（403/401返回、拒绝、未授权）？ if grep -qE '(status.*40[13]|"未经授权"|"禁止"|rejectWith|createErrorResponse.*40)' "$f";然后如果！ grep -q "logEvent\|SecurityMonitor" "$f";然后 echo“缺少安全监视器：$f” 菲菲完成 **输出**：如果有任何遗漏，请报告为建议（置信度=75） ### 第 3 阶段：反馈集成（使用评论聚合器）调用 **review-aggregator 代理** (`.claude/agents/review-aggregator.md`) 来集成每个审阅者的输出。 **聚合器处理**： 1. **解析** ：从每个审阅者输出中提取 `[confidence=XX]` 标签 2. **过滤**： * 阻止者：保留全部（置信度<60 标记为“⚠️ 需要确认”） * 重要提示：仅置信度 >=70（<70 降级为“需要确认”） * 建议：仅confidence>=80（<80省略） 3. **去重**：合并同一文件：行的指示，采用最高置信度 4. **Merge Decision判断** : * 拦截器 0 → ✅ 合并 * 拦截器全部“需要确认”且 <=2 项 → ⚠️ 与后续合并 * 1 个或多个置信度 >=60 的阻止者 → ❌ 需要更改 **输入格式**：每个审稿人以统一格式输出（参见`.claude/docs/reviewer-output-format.md`） ### 第 4 阶段：公关帖子 **顶级评论（必填）：** gh pr 评论 --repo --body "$(cat <<'EOF' ## 代码审查总结 ### 总结 [2-4行总结] ### 检查表覆盖范围（必须检查 v1.0） |域名 |状态 | |--------|--------| |苏帕巴斯| ✅ / ⚠️ / ❌ / 不适用 | |管道| ✅ / ⚠️ / ❌ / 不适用 | |环境/秘密 | ✅ / ⚠️ / ❌ / 不适用 | |测试 | ✅ / ⚠️ / ❌ / 不适用 | |条纹| ✅ / ⚠️ / ❌ / 不适用 | ### 🔴 阻滞剂 - [如果没有，则“无”] ### 🟡建议 - [需要证据才能保证置信度>=75] ### 🟢 很高兴有 - [子弹] ### 自动检查 - 类型检查：[✅/❌/⏭️] - 棉绒：[✅/❌/⏭️] - 测试：[✅/❌/⏭️] ### 合并决策 [✅/⚠️/❌+原因] --- 🤖 Claude Code 审稿（5个领域并行审稿） EOF ）” **内嵌评论（选择性）：** * 仅当它可以清楚地锚定到特定文件/行时 * 最小化以避免垃圾邮件 ### 机器可处理的输出（尾部 YAML 块） **必须**在审核结果末尾添加以下 YAML 块（只有一个 YAML 栅栏，无嵌套）：评论元： checklist_version：“v1.0” domains_ran：[“代码质量”，“安全性”，“性能”，“测试覆盖率”，“文档”] 拦截者计数：0 重要计数：2 建议数：5 最大置信度：85 merge_decision: "合并" # 合并 |与后续合并 |需求变更页脚： 🤖 Claude Code 审阅（ppt-trans 5 域审阅） **\--本地选项：** * 未发布 PR 评论（仅限终端输出） * 也可以保存到 `review_output.md` 文件（用于 GitHub Actions） ** ** ## 代理提示模板有关每个代理的提示模板，请参阅 [references/agent-prompts.md]()。 ** ** ## AI助手使用说明该技能发动时： 1. **先运行阶段0**：加载CLAUDE.md → 加载清单→ 获取PR信息 2. **根据\--focus**选择agent：所有5个agent并行，仅限对应的一个 3. **参见代理提示模板** : 从 `references/agent-prompts.md` 获取提示 4. **运行阶段 2.5 安全门**：对 PR diff 中包含的文件进行 3 次 grep 检查 5. **与审查聚合器合并**：置信度过滤→重复数据删除→合并决策 6. **严格遵循输出合同**：摘要、清单、阻碍、建议、锦上添花、合并决策总是： * 请务必将证据（文件：行+代码引用）添加到阻止者中 * 置信度 >=75 的建议还需要证据 * 确保在末尾添加 `review_meta` YAML 块 * 当`--local`时，仅终端输出，不发布PR评论从不： * 不要在日志/评论中发布秘密信息（env值、密钥、令牌） * 不要“以防万一”添加阻止程序（仅针对实际错误/漏洞/数据丢失） * 不要跳过阶段0（理解项目规则与质量直接相关） ** ** ## 注释 1. **第二阶段自动检查结果包含在审核正文中** * 明确指示成功/失败/未执行 2. **Merge with followups的后续是假设它会成为问题的粒度** * 示例：“RLS测试添加”、“429返回的E2E稳定” 3. **仅当可以锚定差异时才使用内嵌注释** * 避免垃圾邮件，专注于顶级评论 4. **gh CLI 先决条件** * 必须安装`gh`并进行身份验证

审查

包含技能