Verify PR Implementation

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.

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

Procedure

1. Resolve PR Identifier

Extract the PR number from the user input. Strip any # prefix or parse the number from a URL.

PR_NUMBER=<extracted number>

2. Fetch PR Metadata

Gather PR details including body and linked issues:

gh pr view $PR_NUMBER --json number,title,body,baseRefName,headRefName,files,url

3. Extract Linked Issue Number

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:

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.

4. Fetch Issue Details

Retrieve the full issue description:

gh issue view $ISSUE_NUMBER --json number,title,body,labels

5. Extract Requirements from 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.

6. Fetch PR Diff

Get the full diff for the pull request:

gh pr diff $PR_NUMBER

Also review the list of changed files from Step 2 to understand the scope of changes.

7. Analyze Coverage

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.

8. Produce Report

Generate one of two outputs based on the analysis:

If all requirements are covered (100% coverage):

PR Coverage: 100%

All requirements from issue #<ISSUE_NUMBER> are implemented in PR #<PR_NUMBER>.

Requirements

Summary

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

If any requirements are missing or partially covered:

PR Coverage: <percentage>%

PR #<PR_NUMBER> does not fully implement issue #<ISSUE_NUMBER>.

Requirements

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>

9. Report to User

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

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