Review Stack
Use this skill to review a stacked GitHub PR one commit at a time. Treat each commit as functionally atomic unless the evidence shows otherwise.
Resources
scripts/get-stack-review-context: fetch PR commits and deduplicated review threads grouped by commit.
scripts/pr-stack-review.graphql: GraphQL query used by the helper.
scripts/group-stack-review.jq: jq transformer used by the helper.
assets/commit-review-template.md: report shape for each commit.
Do not duplicate review comments: a GitHub review thread appears once, with replies nested as context.
Workflow
- Validate that the user provided exactly one positive PR number.
- Identify
OWNER, REPO, PR, BASE_REF, and a local PR head ref.
- Fetch the base branch and PR head without pushing or modifying remote state.
- Run the bundled helper to collect commit order plus review threads and replies:
SKILL_DIR="${SKILL_DIR:-}"
if [ -z "$SKILL_DIR" ]; then
echo "Set SKILL_DIR to the installed review-stack skill directory" >&2
exit 1
fi
OWNER="$(gh repo view --json owner --jq '.owner.login')"
REPO="$(gh repo view --json name --jq '.name')"
PR="<PR_NUMBER>"
BASE_REF="$(gh pr view "$PR" --repo "$OWNER/$REPO" --json baseRefName --jq '.baseRefName')"
mkdir -p _ai_report
CONTEXT_JSON="_ai_report/pr-${PR}-stack-context-$(date +%Y%m%d).json"
"$SKILL_DIR/scripts/get-stack-review-context" -o "$OWNER" -r "$REPO" -p "$PR" -u > "$CONTEXT_JSON"
- Fetch code for local review:
git fetch origin "$BASE_REF"
git fetch origin "pull/${PR}/head:refs/remotes/origin/pr-${PR}"
BASE="$(git merge-base "origin/$BASE_REF" "refs/remotes/origin/pr-${PR}")"
- For each commit in PR order, inspect it independently:
git show --stat --find-renames <COMMIT_SHA>
git show --format=fuller --find-renames <COMMIT_SHA> --
- For each commit, write
_ai_report/pr-NUM-COMMITID.md, where COMMITID is the short commit id from the PR stack. Use assets/commit-review-template.md.
- Include the changed lines or relevant diff hunks for every finding, plus any related existing review thread.
- Include replies to existing comments as context under the same thread. Do not repeat replies as separate comments or findings unless the reply introduces a distinct unresolved issue.
- Label every finding with exactly one severity:
blocker, major, minor, or nit.
- If a commit has no findings, still write its report with
Result: no findings.
Review Rules
- Review the current commit's diff against its first parent, not the aggregate PR diff.
- Preserve atomicity in the review: do not blame a commit for behavior introduced only by a later commit.
- Call out atomicity problems when the commit depends on a later commit to build, test, or make semantic sense.
- Treat existing review comments as context, not as automatic findings.
- Use replies to understand whether a thread was answered, resolved, rejected, or still needs attention.
- Prefer precise line-level findings over broad commentary.
- Do not post GitHub comments, approve, request changes, push, or modify code unless the user explicitly asks.
Report Contents
Each _ai_report/pr-NUM-COMMITID.md report must include:
- PR number, repository, commit id, commit subject, and generated date
- commit scope summary
- existing review threads for that commit, deduplicated by thread, with replies nested
- findings table with severity or
nit
- detailed findings with path, line or hunk, rationale, and suggested fix when useful
- atomicity notes
- result status:
findings, nit-only, or no findings
Severity guide:
blocker: correctness, data loss, security, build failure, or a regression that should block merge
major: important behavior, maintainability, or test coverage problem that should be fixed before merge
minor: localized issue with limited risk
nit: style, naming, wording, or very small cleanup that should not block merge
Final Response
Summarize the PR number, commits reviewed, report paths written, counts by severity including nits, and any commits that could not be reviewed. Keep the final concise and state that no GitHub comments were posted.
1---2name: review-stack3description: GitHub PR review workflow for reviewing each stacked commit in a numbered pull request as a functionally atomic change, mapping existing review threads and replies to specific commits, and writing one severity-labeled local report per commit. Best fit for PRs where commits are intended to be independently reviewable.4---56# Review Stack78Use this skill to review a stacked GitHub PR one commit at a time. Treat each commit as functionally atomic unless the evidence shows otherwise.910## Resources1112- `scripts/get-stack-review-context`: fetch PR commits and deduplicated review threads grouped by commit.13- `scripts/pr-stack-review.graphql`: GraphQL query used by the helper.14- `scripts/group-stack-review.jq`: jq transformer used by the helper.15- `assets/commit-review-template.md`: report shape for each commit.1617Do not duplicate review comments: a GitHub review thread appears once, with replies nested as context.1819## Workflow20211. Validate that the user provided exactly one positive PR number.222. Identify `OWNER`, `REPO`, `PR`, `BASE_REF`, and a local PR head ref.233. Fetch the base branch and PR head without pushing or modifying remote state.244. Run the bundled helper to collect commit order plus review threads and replies:2526```bash27SKILL_DIR="${SKILL_DIR:-}"28if [ -z "$SKILL_DIR" ]; then29 echo "Set SKILL_DIR to the installed review-stack skill directory" >&230 exit 131fi3233OWNER="$(gh repo view --json owner --jq '.owner.login')"34REPO="$(gh repo view --json name --jq '.name')"35PR="<PR_NUMBER>"36BASE_REF="$(gh pr view "$PR" --repo "$OWNER/$REPO" --json baseRefName --jq '.baseRefName')"3738mkdir -p _ai_report39CONTEXT_JSON="_ai_report/pr-${PR}-stack-context-$(date +%Y%m%d).json"40"$SKILL_DIR/scripts/get-stack-review-context" -o "$OWNER" -r "$REPO" -p "$PR" -u > "$CONTEXT_JSON"41```42435. Fetch code for local review:4445```bash46git fetch origin "$BASE_REF"47git fetch origin "pull/${PR}/head:refs/remotes/origin/pr-${PR}"48BASE="$(git merge-base "origin/$BASE_REF" "refs/remotes/origin/pr-${PR}")"49```50516. For each commit in PR order, inspect it independently:5253```bash54git show --stat --find-renames <COMMIT_SHA>55git show --format=fuller --find-renames <COMMIT_SHA> --56```57587. For each commit, write `_ai_report/pr-NUM-COMMITID.md`, where `COMMITID` is the short commit id from the PR stack. Use `assets/commit-review-template.md`.598. Include the changed lines or relevant diff hunks for every finding, plus any related existing review thread.609. Include replies to existing comments as context under the same thread. Do not repeat replies as separate comments or findings unless the reply introduces a distinct unresolved issue.6110. Label every finding with exactly one severity: `blocker`, `major`, `minor`, or `nit`.6211. If a commit has no findings, still write its report with `Result: no findings`.6364## Review Rules6566- Review the current commit's diff against its first parent, not the aggregate PR diff.67- Preserve atomicity in the review: do not blame a commit for behavior introduced only by a later commit.68- Call out atomicity problems when the commit depends on a later commit to build, test, or make semantic sense.69- Treat existing review comments as context, not as automatic findings.70- Use replies to understand whether a thread was answered, resolved, rejected, or still needs attention.71- Prefer precise line-level findings over broad commentary.72- Do not post GitHub comments, approve, request changes, push, or modify code unless the user explicitly asks.7374## Report Contents7576Each `_ai_report/pr-NUM-COMMITID.md` report must include:7778- PR number, repository, commit id, commit subject, and generated date79- commit scope summary80- existing review threads for that commit, deduplicated by thread, with replies nested81- findings table with severity or `nit`82- detailed findings with path, line or hunk, rationale, and suggested fix when useful83- atomicity notes84- result status: `findings`, `nit-only`, or `no findings`8586Severity guide:8788- `blocker`: correctness, data loss, security, build failure, or a regression that should block merge89- `major`: important behavior, maintainability, or test coverage problem that should be fixed before merge90- `minor`: localized issue with limited risk91- `nit`: style, naming, wording, or very small cleanup that should not block merge9293## Final Response9495Summarize the PR number, commits reviewed, report paths written, counts by severity including nits, and any commits that could not be reviewed. Keep the final concise and state that no GitHub comments were posted.