القائمة
Review a GitHub PR of this repo: description accuracy, code quality against the project dev-skill standards, and a bug hunt with concrete failure scenarios.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when work may edit files, push branches, open or update pull requests, wait for CI, merge changes, or modify issue state, especially when the prompt is terse or says AFK, take to completion, fix and merge, or do not stop.
Use when two or more pull requests must be rebased, repaired, validated, queued, merged, drained, or coordinated as a set, especially for prompts such as take all open PRs, merge every PR, drain the PR queue, or orchestrate PRs.
Use when an existing pull request must be diagnosed, rebased, repaired, pushed, brought through CI, queued, or merged, including prompts such as fix this PR, rebase on main, fix CI, push back, CI pass, or merge.
Default delivery workflow for tracked repo changes. Use when the user asks to fix, add, implement, update, refactor, rename, bump, tweak, or otherwise end in a file change. Do not use for read-only questions or investigation.
Drain the ready-for-agent GitHub issue backlog: claim the oldest unclaimed issue via the lock-branch protocol, ship it through tdd-ship, label the outcome, repeat.
Python standards and verification gate for this repo. Use when editing .py files, Python dependencies, pytest tests, backend behavior, or investigating ruff, mypy, ty, pyrefly, or pytest failures.
| name | pr-review |
| description | Review a GitHub PR of this repo: description accuracy, code quality against the project dev-skill standards, and a bug hunt with concrete failure scenarios. |
| disable-model-invocation | true |
Invoked as /pr-review <PR#>; without a number, review the PR of the current
branch. Work the steps in order — the verdict is earned by the evidence, not
sketched first.
gh pr view <PR#> --json title,body,url,baseRefName,statusCheckRollup
gh pr diff <PR#>
Read the linked issue if the body names one. For every changed file, read enough surrounding source to judge the hunk — a hunk alone is not context; follow the change into its callers and callees. Completion: every file in the diff read, in place, with its neighbours.
Treat the description as a set of claims and audit in both directions:
Completion: each claim marked verified or flagged, and each changed file mapped to a claim.
The quality rules live in the dev skills — apply them, do not restate them:
.py, pyproject.toml, or backend tests → read
python-dev/SKILL.md..ts/.tsx, npm or Vite config, or frontend tests → read
typescript-dev/SKILL.md.Hold the changed lines against every rule in the matching skill, including its test-authoring rules — a behavior change with no regression test is a finding. Completion: every changed file checked against its standard, or explicitly outside both.
Read the diff as an adversary: for each changed function, look for the inputs or state that make it misbehave. A finding is confirmed only when you can state that concrete failure scenario, traced through the actual code — not pattern-matched from its shape. What you suspect but cannot trace is potential, reported separately, never silently dropped. Completion: every changed function either cleared or attached to a finding.
Deliver the review in the session; comment on the PR only when asked.
file:line, its axis
(description / quality / confirmed bug / potential issue), and — for bugs —
the failure scenario.