Back to Details

arinhub-verify-pr-implementation

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Verify PR Implementation

验证PR实现情况

Verify that a pull request fully implements the requirements described in its linked GitHub issue. Extracts the issue reference, analyzes the PR diff against the issue description, and produces a coverage report.
验证拉取请求（Pull Request）是否完整实现了其关联的GitHub Issue中描述的需求。提取Issue引用，对照Issue描述分析PR代码差异，并生成覆盖范围报告。

Input

输入

  • PR number or URL (required): The pull request identifier. Accepts:
    • Number: 
      123
    • Hash-prefixed: 
      #123
    • Full URL: 
      https://github.com/owner/repo/pull/123
  • PR编号或URL（必填）：拉取请求的标识，支持以下格式：
    • 纯编号：
      123
    • 带#前缀：
      #123
    • 完整URL：
      https://github.com/owner/repo/pull/123

Procedure

步骤

1. Resolve PR Identifier

1. 解析PR标识

Extract the PR number from the user input. Strip any 
#
prefix or parse the number from a URL.
PR_NUMBER=<extracted number>
从用户输入中提取PR编号，去除
#
前缀或从URL中解析编号。
PR_NUMBER=<extracted number>

2. Fetch PR Metadata

2. 获取PR元数据

Gather PR details including body and linked issues:
bash
gh pr view $PR_NUMBER --json number,title,body,baseRefName,headRefName,files,url
收集PR的详细信息，包括正文和关联Issue：
bash
gh pr view $PR_NUMBER --json number,title,body,baseRefName,headRefName,files,url

3. Extract Linked Issue Number

3. 提取关联Issue编号

Determine the related issue using these methods in priority order:
Method A -- Closing keywords in PR body:
Search the PR body for GitHub closing keywords followed by an issue reference:
  • closes #N
    , 
    fixes #N
    , 
    resolves #N
    (and their variants: 
    close
    , 
    closed
    , 
    fix
    , 
    fixed
    , 
    resolve
    , 
    resolved
    )
  • Full URL references: 
    closes https://github.com/owner/repo/issues/N
Method B -- GitHub linked issues API:
bash
gh api graphql \
  -F owner='{owner}' \
  -F repo='{repo}' \
  -F pr_number=$PR_NUMBER \
  -f query='
    query($owner: String!, $repo: String!, $pr_number: Int!) {
      repository(owner: $owner, name: $repo) {
        pullRequest(number: $pr_number) {
          closingIssuesReferences(first: 10) {
            nodes { number title }
          }
        }
      }
    }
  ' --jq '.data.repository.pullRequest.closingIssuesReferences.nodes'
Method C -- Issue reference in PR body:
If Methods A and B yield no results, scan the PR body for any 
#N
pattern or issue URL that is not a closing keyword reference.
No issue found: If no linked issue can be determined, inform the user and stop. Do not guess or fabricate an issue number.
ISSUE_NUMBER=<extracted number>
If multiple issues are found, process each one and produce a separate coverage report per issue.
按以下优先级顺序确定相关Issue：
方法A -- PR正文中的关闭关键字：
在PR正文中搜索GitHub关闭关键字后跟Issue引用：
  • closes #N
    、
    fixes #N
    、
    resolves #N
    （及其变体：
    close
    、
    closed
    、
    fix
    、
    fixed
    、
    resolve
    、
    resolved
    ）
  • 完整URL引用：
    closes https://github.com/owner/repo/issues/N
方法B -- GitHub关联Issue API：
bash
gh api graphql \
  -F owner='{owner}' \
  -F repo='{repo}' \
  -F pr_number=$PR_NUMBER \
  -f query='
    query($owner: String!, $repo: String!, $pr_number: Int!) {
      repository(owner: $owner, name: $repo) {
        pullRequest(number: $pr_number) {
          closingIssuesReferences(first: 10) {
            nodes { number title }
          }
        }
      }
    }
  ' --jq '.data.repository.pullRequest.closingIssuesReferences.nodes'
方法C -- PR正文中的Issue引用：
如果方法A和B未找到结果，扫描PR正文中所有非关闭关键字引用的
#N
格式或Issue URL。
未找到Issue： 如果无法确定关联Issue，告知用户并停止操作，请勿猜测或编造Issue编号。
ISSUE_NUMBER=<extracted number>
如果找到多个Issue，逐个处理并为每个Issue生成单独的覆盖范围报告。

4. Fetch Issue Details

4. 获取Issue详情

Retrieve the full issue description:
bash
gh issue view $ISSUE_NUMBER --json number,title,body,labels
获取完整的Issue描述：
bash
gh issue view $ISSUE_NUMBER --json number,title,body,labels

5. Extract Requirements from Issue

5. 从Issue中提取需求

Parse the issue body and title to identify discrete, testable requirements. Look for:
  • Checklist items (
    - [ ]
    or 
    - [x]
    )
  • Numbered steps or acceptance criteria
  • Explicit behavioral descriptions ("should", "must", "when X then Y")
  • UI changes, API changes, or data model changes mentioned
  • Edge cases or error handling requirements
  • Non-functional requirements (performance, security, accessibility)
Produce a numbered list of requirements:
R1: <requirement description>
R2: <requirement description>
...
If the issue body is vague or contains no clear requirements, use the issue title and any available context to infer the expected behavior. Flag inferred requirements clearly.
解析Issue正文和标题，识别可独立测试的明确需求，重点关注：
  • 复选列表项（
    - [ ]
    或 
    - [x]
    ）
  • 编号步骤或验收标准
  • 明确的行为描述（如“应该”“必须”“当X发生时则Y”）
  • 提及的UI变更、API变更或数据模型变更
  • 边缘情况或错误处理需求
  • 非功能性需求（性能、安全、可访问性）
生成编号的需求列表：
R1: <需求描述>
R2: <需求描述>
...
如果Issue正文模糊或没有明确需求，使用Issue标题和可用上下文推断预期行为，并清晰标记推断的需求。

6. Fetch PR Diff

6. 获取PR代码差异

Get the full diff for the pull request:
bash
gh pr diff $PR_NUMBER
Also review the list of changed files from Step 2 to understand the scope of changes.
获取拉取请求的完整代码差异：
bash
gh pr diff $PR_NUMBER
同时查看步骤2中获取的变更文件列表，了解变更范围。

7. Analyze Coverage

7. 分析覆盖情况

For each requirement from Step 5, determine whether the PR diff addresses it:
  • Covered: The diff contains code changes that directly implement the requirement
  • Partially covered: The diff addresses some aspects but misses edge cases or details
  • Not covered: No code changes in the diff relate to this requirement
Use evidence from the diff to justify each assessment. Do not speculate -- base judgments on actual code changes.
针对步骤5中的每个需求，判断PR代码差异是否满足该需求：
  • 已覆盖：代码差异包含直接实现该需求的变更
  • 部分覆盖：代码差异涉及部分内容，但遗漏了边缘情况或细节
  • 未覆盖：代码差异中没有与该需求相关的变更
使用代码差异中的证据来支撑每个评估，请勿猜测——判断必须基于实际的代码变更。

8. Produce Report

8. 生成报告

Generate one of two outputs based on the analysis:
If all requirements are covered (100% coverage):
undefined
根据分析结果生成以下两种输出之一：
如果所有需求均已覆盖（100%覆盖）：
undefined

PR Coverage: 100%

PR覆盖范围：100%

All requirements from issue #<ISSUE_NUMBER> are implemented in PR #<PR_NUMBER>.
Issue #<ISSUE_NUMBER>中的所有需求均已在PR #<PR_NUMBER>中实现。

Requirements

需求列表

#RequirementStatus
R1<description>Covered
R2<description>Covered
编号需求描述状态
R1<描述>已覆盖
R2<描述>已覆盖

Summary

总结

<2-3 sentences confirming that the PR fully addresses the issue, highlighting key implementation decisions>

**If any requirements are missing or partially covered:**
<2-3句话确认PR完全满足Issue需求，重点突出关键实现决策>

**如果存在未覆盖或部分覆盖的需求：**

PR Coverage: <percentage>%

PR覆盖范围：<百分比>%

PR #<PR_NUMBER> does not fully implement issue #<ISSUE_NUMBER>.
PR #<PR_NUMBER>未完整实现Issue #<ISSUE_NUMBER>的需求。

Requirements

需求列表

#RequirementStatusNotes
R1<description>Covered
R2<description>Not covered<what is missing>
R3<description>Partially covered<what is incomplete>
编号需求描述状态备注
R1<描述>已覆盖
R2<描述>未覆盖<缺失内容>
R3<描述>部分覆盖<未完成细节>

Missing Implementation

未实现内容

<For each uncovered or partially covered requirement, describe specifically what code changes are needed to complete the implementation>
<针对每个未覆盖或部分覆盖的需求，具体描述完成实现所需的代码变更>

Summary

总结

<2-3 sentences describing the overall gap between the issue requirements and the PR implementation>
undefined
<2-3句话描述Issue需求与PR实现之间的整体差距>
undefined

9. Report to User

9. 向用户提交报告

Present the coverage report from Step 8. Include:
  • The issue number and title for context
  • The PR URL for reference
  • The coverage percentage
  • Clear next steps if coverage is incomplete
展示步骤8生成的覆盖范围报告，内容需包括：
  • 用于上下文的Issue编号和标题
  • 用于参考的PR URL
  • 覆盖范围百分比
  • 如果覆盖不完整，提供清晰的后续步骤

Important Notes

重要说明

  • Never fabricate requirements that are not present or implied in the issue
  • If the issue lacks acceptance criteria, clearly state which requirements were inferred from context
  • Do not evaluate code quality -- this skill only checks implementation completeness against the issue description
  • For issues with sub-tasks or linked child issues, only evaluate the requirements in the specific linked issue
  • When multiple issues are linked, report coverage for each issue separately
  • 切勿编造Issue中未提及或未隐含的需求
  • 如果Issue缺乏验收标准，清晰说明哪些需求是从上下文推断而来
  • 请勿评估代码质量——该流程仅检查是否根据Issue描述完成实现
  • 对于包含子任务或关联子Issue的主Issue，仅评估当前关联Issue中的需求
  • 如果关联多个Issue，为每个Issue单独生成覆盖范围报告