SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillspr-change-analysis

pr-change-analysis

Coding & development

View repository

Updated 10-15 23:48

About this skill

PR / Branch Change Analysis

Aimed at code reviewers, first reconstruct requirements and implementation boundaries from the real diff, then judge whether there are changes beyond the requirements, overly complex reorganizations, testing and modularization risks, and styles inconsistent with similar code.

Basic Principles

  • Output in Chinese by default.
  • Base it on the checked-out code and diff, not merely restating the PR title or description.
  • Prioritize answering "what exactly was changed this time, why it is useful, what it affects, and where it includes changes that do not look like they belong to the same requirement".
  • Do not submit reviews, approvals, change requests, or push code by default; perform GitHub write operations only after the user explicitly requests them.
  • Do not modify workspace code; if split experiments or temporary commands are needed for review, perform read-only checks only.
  • Preserve the user's existing changes. Before switching PRs, you must check git status --short; when encountering uncommitted changes, first explain the risks and let the user decide, and do not stash, reset, or checkout over them on your own.

Entry Point Determination

  1. If the user provides a PR URL or number:
    • Use gh pr view <pr> to get number,title,body,author,headRefName,baseRefName,files,additions,deletions,commits。
    • As requested by the user, use gh pr checkout <pr> to switch to that PR branch.
    • git fetch upstream main, and by default use upstream/main...HEAD as the review baseline.
    • If the PR's baseRefName is not main, state this clearly in the report, and decide based on the context whether to also supplement the comparison with upstream/<baseRefName>...HEAD .
  2. If the user does not provide a PR and only mentions the current branch:
    • Confirm the current branch name:git branch --show-current。
    • git fetch upstream main。
    • Use git diff upstream/main...HEAD and related statistics as the review baseline.
  3. If the current branch is main or the diff is empty:
    • Clearly state that there are no branch differences to analyze, and if necessary check whether another base needs to be compared.

Information Collection

Prioritize using these commands to establish a global view:

git status --short
git branch --show-current
git fetch upstream main
git diff --stat upstream/main...HEAD
git diff --name-status upstream/main...HEAD
git log --oneline --decorate upstream/main..HEAD

Then go deeper by file type:

git diff upstream/main...HEAD -- <path>
git diff --word-diff=color upstream/main...HEAD -- <path>
rg -n "关键函数|关键类型|关键字段" <相关目录>

When checking requirement sources, prioritize reading:

  • PR title, body, and commit message.
  • New or modified API schemas, database schemas, workflow node definitions, configuration defaults, and permission checks.
  • Old implementations or similar feature implementations adjacent to the changed files.
  • Test files and high-risk paths with missing tests.

Review Dimensions

1. Requirement Change Description

It needs to be explained in a way that a reviewer can quickly understand:

  • What problem this change solves, and what effect it brings to users, administrators, developers, or system operation.
  • What the core behavior changes from and to.
  • Whether external interfaces, data structures, configuration, permissions, billing, workflow runtime, or frontend interactions have changed.
  • Key implementation path: where the entry point is, where the main processing logic is, and which modules it ultimately lands in.

Do not merely list file names. Each key file must explain the behavioral change it carries.

2. Whether It Exceeds the Requirement Impact Scope

Focus on finding these signals:

  • Formatting, renaming, moving files, dependency upgrades, and bulk cleanup unrelated to the requirement.
  • Modifying shared types, global utilities, common components, or runtime core logic when the requirement only needs a local fix.
  • Mixing multiple independent requirements or historical cleanup into the same branch.
  • Behavior changes disguised as refactoring, causing changes to legacy path compatibility, default values, inheritance semantics, or persistence boundaries.
  • Removing compatibility logic, or changing error handling, logging, permissions, caching, or concurrency strategy without explanation in the PR description.

Conclusions must distinguish:

  • 合理扩散: upstream and downstream changes that are necessary to implement the requirement.
  • 可疑越界: changes that appear unrelated to the requirement and need the author to split them out or explain them.
  • 高风险越界: changes that may cause regressions and should be split out or covered with tests.

3. Code quality

Check whether:

  • There is duplicated logic, temporary hardcoding, overly long functions, or mixing of multiple layers of responsibility.
  • It could be tested as an independently modularized unit, but is actually written in UI, API routes, or branch logic, making it hard to test.
  • It lacks handling for boundary conditions, exception paths, null values, legacy data compatibility, concurrency, or idempotency.
  • The contract is not placed at the correct boundary, for example FastGPT API input parameters should use parseApiInput, and shared schemas should be placed in packages/global/openapi or the corresponding shared layer.
  • Tests only cover the happy path, or newly added core logic has no corresponding unit tests.

When evaluating quality, give specific files and functions; do not say vaguely that "optimization is needed."

4. Code style and consistency with similar functionality

Compare against adjacent implementations, rather than judging only by personal preference:

  • Whether API routes, services, schemas, hooks, components, i18n, error handling, logging, and permission checks follow nearby patterns.
  • i18n calls must use keys that can be statically recognized by the cleanup script: do not write t(`ns:key_${value}`)、t(prefix + value)、t(variableKey) or t(condition ? 'ns:a' : 'ns:b') such dynamic/expression keys; finite enumerations should be split into explicit branches or static mappings, and the final call site should retain the t('ns:literal_key') form. After changes, check whether the corresponding language pack keys are complete, to avoid the cleanup script mistakenly deleting them or raw keys being displayed at runtime.
  • Whether frontend interactions, Chakra UI component organization, state naming, and modal/form/list layouts are consistent with the same module.
  • Whether backend naming, directory layering, model access, and transaction/queue/cache patterns are consistent with similar code.
  • Whether comments explain the design rationale, especially for exported functions, core business functions, and complex helpers; avoid meaningless line-by-line comments.
  • Whether new abstractions, new tools, or new dependencies inconsistent with project conventions are introduced.

Deep-dive method

For each core change, perform at least one "call-chain closure":

  1. Find the trigger point from the entry: page, API route, worker, workflow dispatcher, service method, or configuration loading.
  2. Trace to the state/data landing point: database, cache, request body, response body, runtime variables, frontend store.
  3. Find similar functionality: similar routes in the same directory, similar components, similar workflow nodes, similar model configurations.
  4. Compare old behavior: use git show upstream/main:<path> or git diff to confirm it is not a misreading.
  5. Assess tests: whether existing tests cover this path; if there are no tests, explain the gap and risk.

If a large-scale refactor is found, first identify "pure moves/pure renames/formatting" versus "real behavioral changes," to avoid treating noise as requirements.

Output format

The final report should preferably use the following structure, organized by risk level; do not write a lengthy summary report:

## 需求变更

- ...

## 关键实现路径

- `path/to/file.ts`: ...

## 影响范围与越界判断

- 合理扩散: ...
- 可疑越界: ...
- 高风险越界: ...

## 代码质量

- [风险等级] `path/to/file.ts`: 问题、原因、建议。

## 代码风格一致性

- ...

## 测试与验证缺口

- ...

## 需要作者确认的问题

- ...

Issue items must include file paths and line numbers whenever possible. When no issues are found, also explicitly write "no obvious out-of-bounds/quality/style issues found," and list the verification blind spots that are still uncovered.