dart-review-pr

Use this skill to run the DART dart-review-pr workflow. The editable workflow source lives in .claude/commands/; this generated skill is its entrypoint for Codex and Muse.

Invocation

• Claude Code: /dart-review-pr <arguments>
• Codex: $dart-review-pr <arguments>
• Muse: /dart-review-pr <arguments>

Treat the text after the skill name, or the user's request when the skill is loaded on demand, as $ARGUMENTS. When the workflow references $1, $2, etc., map those to the positional values supplied by the user.

Command Body

Review or respond to PR: $ARGUMENTS

Required Reading

@AGENTS.md @docs/onboarding/code-style.md @docs/onboarding/ai-tools.md (for AI-generated review handling) @docs/ai/verification.md

Workflow

To Review

gh pr view $1 && gh pr diff $1

Check code style, tests, docs, and focused commits. For claims involving 3D structure or behavior, require the dart-verify-sim text oracle plus assessed claim-tied Filament/debug-overlay evidence, or a justified replacement; a screenshot alone is not correctness evidence.

To Address Feedback

gh pr view $1 --comments

Apply minimal fixes locally and verify. Do not push, comment, resolve threads, or re-trigger review without explicit maintainer/user approval for that external mutation.

For published PRs, prefer a new follow-up commit for review fixes so reviewers can inspect what changed since the previous round. Amend or force-push only after explicit maintainer/user approval and only when the user explicitly requests it or when there is a clear reason such as removing sensitive content or repairing broken branch history.

Before every push, first merge the latest base branch into the PR branch (on every push, not just the first) so each pushed/CI-tested state reflects current target base branch and conflicts surface early: git fetch origin <base> then git merge --no-ff origin/<base>, rebuild/retest if the merge touched code, then push. The local base merge is a routine pre-push step; the push itself still requires explicit maintainer/user approval. Do not rebase a published PR branch by default because it invalidates existing CI runs and makes PR review/comment history harder to follow. Rebase or force-push only when the maintainer explicitly requests it.

If the push is rejected because the remote PR head moved, fetch and compare the remote head before retrying. If it already contains an equivalent review fix, validate that head and follow docs/onboarding/ai-tools.md instead of pushing a duplicate commit.

Automated Reviews (Codex, Code Quality, Copilot, etc.)

When a draft PR is first published, request the first Codex review with a top-level @codex review once explicit maintainer/user approval covers PR comments; it can run while the PR remains draft. If Codex already shows an activity signal or submitted review, do not post a duplicate trigger.

1. Make the local fix silently (no reply)
2. Run the relevant local gates, including pixi run lint before any commit
3. Ask for explicit maintainer/user approval before push, thread resolution, PR comment, or review re-trigger
4. If approved, push the fix silently
5. If approved, resolve only the review threads that were actually reviewed and addressed (thread resolution is approval-gated; see docs/onboarding/ai-tools.md § "Approval Boundaries")
6. After the approved push moves the head, ask for explicit maintainer/user approval for the PR comment, then re-trigger Codex for the new head: gh pr comment $1 --body "@codex review"
7. Also handle github-code-quality[bot] review comments with the same no-inline-reply loop. Fix valid findings locally and push silently after approval.
8. Monitor CI: gh pr checks $1
9. Check for new review, repeat until no actionable comments remain
10. Mark a draft ready, and merge, only as docs/onboarding/ai-tools.md § "PR Lifecycle" describes, after explicit maintainer/user approval

Review rules owner: docs/onboarding/ai-tools.md § "AI Review Comments", § "Approval Boundaries", and § "PR Lifecycle"

Output

• Review findings ordered by severity, or the feedback addressed
• Verification commands run for addressed feedback
• Any external mutation left pending explicit approval