Analyze PR

分析 GitHub Pull Request，评估必要性、描述完整性、验证证据、主要风险与是否可直接合入。

Repository: https://github.com/SiinXu/stock-pulse-ai/pulls

Source of truth: repository root AGENTS.md. Issue #890 review entry: /review-pr. Hard rules: .claude/skills/references/hard-rules.md.

Usage

/analyze-pr <pr_number>

Instructions

分析时使用简洁中文，优先遵循仓库根目录 AGENTS.md 和 .github/PULL_REQUEST_TEMPLATE.md。
所有发布到 GitHub 的标题、正文、评论、review 和建议回复必须使用英文；本地分析文档可继续使用中文。

Step 1: 同步最新代码基线

分析 PR 前必须先刷新远端状态，并尽量把本地安全推进到最新基线：

git status --short
git fetch --all --prune
# 仅当工作区干净且当前分支可 fast-forward 时执行：
git pull --ff-only

• 只有在工作区干净、当前分支有可 fast-forward 的上游时，才执行并接受 git pull --ff-only 的结果。
• 如存在本地改动、冲突状态、未跟踪风险文件、无上游分支或无法 fast-forward，不要执行 stash、reset、强制切分支或覆盖本地状态；改用已 fetch 的 origin/main、PR head 或 GitHub diff 做分析。
• 在输出文档的 Validation Evidence 中记录同步结果：本地 HEAD、使用的远端基线，以及未更新本地工作树的原因（如有）。

Step 2: 拉取 PR 基本信息

gh pr view <pr_number> --repo SiinXu/stock-pulse-ai
gh pr view <pr_number> --repo SiinXu/stock-pulse-ai --comments
gh pr checks <pr_number> --repo SiinXu/stock-pulse-ai
gh pr diff <pr_number> --repo SiinXu/stock-pulse-ai

如有失败的 CI，优先查看失败日志，而不是立刻在本地重跑全部检查：

gh run view <run_id> --log-failed

Step 3: 检查标题与描述完整性

先检查 PR title 是否符合 AGENTS.md 的非阻断建议：

• 格式应为英文 <type>: <change summary>，例如 fix: preserve market analysis history
• 类型优先为 fix/feat/refactor/docs/chore/test/ci
• 不应包含 [codex]、codex、autocode、copilot 或其他工具/agent 来源前缀
• 标题应描述实际变更；若标题与 diff 不符，在描述完整性中指出，但不应单独作为 review process blocker。

对照 .github/PULL_REQUEST_TEMPLATE.md，确认是否覆盖：

• PR Type
• Background And Problem
• Scope Of Change
• Issue Link
• Verification Commands And Results
• Visual Evidence（仅当 PR 修改报告格式、报告渲染效果或 Web UI 界面时要求截图或替代可视证据）
• Compatibility And Risk
• Rollback Plan

若 PR 涉及第三方模型 / API 兼容语义、请求参数固定值、OpenAI-compatible 路由、YAML alias、fallback 行为或运行时配置保存 / 清理 / 迁移逻辑，还要额外检查描述里是否明确写出：

• 官方来源链接或公告
• 当前锁定依赖 / 运行时兼容范围（例如 LiteLLM 版本窗口）
• 已验证的调用链路覆盖面
• 旧配置是否会被静默改写、清空、迁移或保持不变
• 最小回滚路径（通常是 revert 本 PR）

若 PR 修改报告格式、报告渲染效果或 Web UI 界面，还要检查 Visual Evidence 是否附受影响报告 / 页面截图；涉及前后差异时优先检查前后对比。若无法截图，描述中应说明原因与替代可视证据。

Step 4: 优先使用 CI / Diff 证据

• 先根据 gh pr checks、PR diff、现有测试与工作流日志判断问题
• 仅当 CI 未覆盖改动面、CI 结果不足以定性问题、或需要验证关键回归风险时，再补充本地最小验证
• 不要默认切换当前分支或执行 gh pr checkout

如果必须补本地验证，按改动面选择最接近的检查，例如：

• 后端：./scripts/ci_gate.sh 或 python -m py_compile <changed_python_files>
• 前端：cd apps/dsa-web && npm ci && npm run lint && npm run build
• 桌面端：先构建 Web，再构建 Electron

Step 5: 评估正确性与风险

重点检查：

• 是否解决了明确问题，且没有夹带无关改动
• 是否破坏 API / Schema / Web / Desktop 兼容性
• 是否破坏 fallback、降级路径、通知链路或发布流程
• 是否存在明显逻辑错误、异常吞没、安全问题、配置语义变化未同步文档
• Config registry：新增 .env.example 键是否已注册（hard-rules §2）
• Reachability：用户可达性证据（hard-rules §3）
• Squash 正文体检：标题/正文是否与最终 head 一致（hard-rules §1）
• Merge train（若适用）：无产品代码编辑、Cancelled 不算通过（hard-rules §5）

区分 Blocker 与 Nit（完整表见 /review-pr）。任一 Blocker → 不可建议合入。

Step 6: 生成评审文档

保存到 .claude/reviews/prs/pr-<number>.md

Output Document Format

# PR #<number> Analysis

**Date**: YYYY-MM-DD
**Status**: Pending Review

## Findings

- [严重级别] file:line - 问题描述

## Summary

- 必要性：
- 是否有对应 issue：
- PR 类型：
- PR title：
- description 完整性：
- 验证情况：
- 主要风险：
- 是否可直接合入：

## Validation Evidence

- 代码同步基线：
- CI 结论：
- 本地补充验证（如有）：

## Compatibility And Risk

- API / Web / Desktop：
- 配置 / Docker / GitHub Actions：
- fallback / 通知 / 报告结构：
- 第三方依赖 / 官方约束来源：
- 运行时兼容窗口 / 已覆盖链路：
- 旧配置迁移或静默改写风险：

## Draft Review Comment

<English draft review comment>

Allowed Auto-Actions (No Confirmation Needed)

• 拉取 PR 元数据、diff、评论和 CI 状态
• 执行 git fetch --all --prune，并在工作区干净且可 fast-forward 时执行 git pull --ff-only
• 阅读相关代码、模板、工作流与文档
• 在必要时执行最小化本地验证
• 生成评审文档

Actions Requiring Confirmation

执行以下动作前，先询问用户：

1. 发布评论
2. Approve PR
3. Request changes
4. Merge PR
5. 关闭 PR