メニュー
Substance-focused review of a PX4 pull request — merit, first-principles correctness, architecture fit. Produces a debrief for the user and a draft review comment.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/PX4/PX4-Autopilot --skill review-prコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
SKILL.md を表示中
| name | review-pr |
| description | Substance-focused review of a PX4 pull request — merit, first-principles correctness, architecture fit. Produces a debrief for the user and a draft review comment. |
| argument-hint | <PR number or URL> |
| allowed-tools | Bash, Read, Glob, Grep, Agent |
Goal: brief the user on a PR before they spend their own time on it, and draft a review comment they can choose to post. The review is by Claude and is presented as such — write from Claude's frame of reference, not the user's, unless the user explicitly requests a different voice.
Focus on substance only. Do not review commit messages, do not recommend a merge strategy, do not audit formatting (CI enforces it). Be extremely thorough — the user wants a deep understanding of the problem, not just verdicts — but scale effort with impact: roughly proportional to lines/files changed and how flight-critical the touched code is. For diffs too large to hold at once, fan out Explore agents per subsystem.
In parallel:
gh pr view <PR> --json number,title,body,author,baseRefName,files,reviewsgh pr diff <PR> — on HTTP 406 (huge diff) do not retry; use gh api repos/{owner}/{repo}/pulls/<PR>/files --paginate and fetch key patches selectivelygh pr checks <PR> (exit code 8 just means checks are pending)gh api repos/{owner}/{repo}/pulls/<PR>/comments --paginate --jq '.[] | {user: .user.login, path, body}' (inline) and (conversation)gh api repos/{owner}/{repo}/issues/<PR>/comments --paginate --jq '.[] | {user: .user.login, body}'Read any linked issue — the claimed problem is the baseline for judging merit. For full post-change file contents without touching the working tree: git fetch origin pull/<PR>/head, then git show FETCH_HEAD:<path>.
Never judge a hunk from the diff alone. Read the enclosing function and file, and grep for callers and consumers — a PR is always reviewed in the context of the surrounding code.
msg/, params, or MAVLink: impact on QGC, uLog tooling, and third-party integrations. uORB: timestamp vs timestamp_sample, device_id. Every new parameter is configuration burden on users — challenge it.boards/<mfr>/<board>/): require a logs.px4.io flight log for the vehicle type, a docs page in docs/en/flight_controller/, the manufacturer's own USB VID/PID, a unique board_id in boards.json, CI build coverage, flash fit, and no copy-pasted template leftovers or board-local forks of common drivers.Also, briefly: the PR title must be type(scope): description (it becomes the commit subject on squash); note CI status and read failure logs only when plausibly related to the change; do not repeat feedback other reviewers already gave — build on it or stay silent.
End with two things, then stop — do not post anything.
1. Debrief for the user. Lead with the findings — the user wants actionable information, not a play-by-play of the diff. Give only the framing they need to judge the change: whether the claimed problem is real, scope and risk (subsystems touched, flight-critical or not), and what CI and other reviewers already said. Restate what the change actually does and why only when the PR description is missing, ambiguous, or misleading. Order findings by severity (blocker / concern / nit) with file:line, and end with a one-or-two-sentence overall take.
2. Draft review comment, shown verbatim in a fenced block. First line: **Claude review on behalf of @<login>** (login via gh api user --jq .login). Then terse, actionable findings only — what is wrong, why it matters, what to do, with file:line references. Frame each as an objective engineering tradeoff, not a moral judgment. Never guess: if you cannot demonstrate a flaw via a concrete code path or a first-principles derivation, stay silent. No praise or "verified OK" notes unless they change what the author should do, no meta sections, no conversational filler, nothing already raised by others.
If the user asks to post it, post the draft verbatim with gh pr comment <PR> --body "$(cat <<'EOF' ... EOF)".
PR to review: $ARGUMENTS