| name | code-review |
| description | Review a GitHub pull request for correctness, regressions, tests, and QtAVPlayer-specific integration issues using the GitHub CLI. |
Pull Request Code Review
Use this skill when asked to review a pull request in this repository. Perform the
review with gh; do not require the pull request branch to be checked out unless
runtime validation is necessary.
Gather the pull request context
If a pull request number is not supplied, determine it from the current branch:
gh pr view --json number,title,body,baseRefName,headRefName,files
For a supplied pull request, replace <pr> in the following commands:
gh pr view <pr> --json number,title,body,baseRefName,headRefName,files,commits
gh pr diff <pr> --name-only
gh pr diff <pr> --patch
gh pr checks <pr>
Read the changed code and the directly related callers, declarations, tests, and
build definitions. Use gh api to inspect review discussion when it affects the
correctness of the proposed change:
gh api repos/{owner}/{repo}/pulls/<pr>/comments --paginate
gh api repos/{owner}/{repo}/pulls/<pr>/reviews --paginate
Obtain {owner} and {repo} from gh repo view --json nameWithOwner.
Review focus
Report only actionable, high-confidence defects introduced by the pull request.
Prioritize behavior and regressions over style.
- Validate media lifecycle and state transitions: loading, playing, pausing,
seeking, stream switching, end of media, and errors.
- Trace ownership and thread affinity across the demuxer and decoder threads.
Pay special attention to direct frame-signal connections, FFmpeg object
lifetimes, queued work, and shutdown races.
- Check FFmpeg calls for error handling, correct time bases, packet/frame
ownership, and hardware-frame compatibility.
- Ensure public API changes preserve source and binary expectations where
applicable, and update both public headers and implementation.
- When sources, headers, resources, feature flags, or dependencies change,
verify that the QMake (
.pri/.pro) and CMake build definitions remain
equivalent.
- Check platform-specific hardware paths and relevant Qt 5/Qt 6 compatibility
guards.
- Confirm changed behavior has a focused integration test, or identify the
concrete missing test when its absence could permit a regression.
Do not report formatting preferences, speculative risks, pre-existing issues, or
missing tests that do not exercise a changed behavior.
Findings
Each finding must include:
- A priority:
P0 (release-blocking), P1 (urgent), P2 (normal), or P3
(minor).
- The exact changed file and line range.
- A concise explanation of the failure mode, including the input, state, or
platform required to trigger it.
- A specific remediation direction.
Prefer inline comments for findings tied to changed lines. If a defect spans
multiple files or cannot be anchored to a changed line, put it in the review
summary and identify all affected locations.
If no qualifying findings exist, state that the pull request has no blocking
issues. Do not invent findings to make the review appear more thorough.
Publish the review
Do not submit a review, approve, or request changes unless explicitly asked.
When asked to publish, use the requested review state:
gh pr review <pr> --comment --body "<summary>"
gh pr review <pr> --approve --body "<summary>"
gh pr review <pr> --request-changes --body "<summary>"
Use the GitHub API for inline comments only after verifying the path, changed
line, and diff side. Never post a comment that is not backed by the inspected
diff.
