dart-review-pr

name	dart-review-pr
description	DART Review PR: review a PR or address review feedback

dart-review-pr

Use this skill in Codex to run the DART dart-review-pr workflow. The editable workflow source lives in .claude/commands/; this file is its generated adapter in the shared .agents/skills/ catalog.

Invocation

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

Treat the text after the skill name 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

Pick the sub-workflow from mode= in $ARGUMENTS, defaulting to review.

Review

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

Check code style, tests, docs, and focused commits. When a claim depends on 3D structure or behavior, require the dart-verify-sim text oracle and claim-relevant assessed visual/debug-layer evidence (or a justified replacement), and inspect both rather than accepting a screenshot alone. Record findings as read-only output; do not push, comment, resolve threads, or re-trigger review without explicit maintainer/user approval for that external mutation.

Address Feedback

gh pr view $1 --comments

Apply minimal fixes locally and verify. For published PRs, prefer a new follow-up commit so reviewers can inspect each round; amend or force-push only after explicit maintainer/user approval and only when the user requests it or a clear reason exists (removing sensitive content, repairing branch history).

1. Make the local fix silently (no reply), then run the relevant local gates, including pixi run lint before any commit.
2. Merge the latest base branch into the PR branch before any push, and follow the base-merge, automated-review, and bot no-reply rules in docs/onboarding/ai-tools.md. If the push is rejected because the remote head moved, fetch and compare it before retrying and validate an equivalent remote fix instead of pushing a duplicate.
3. Ask for explicit maintainer/user approval before any push, PR comment, thread resolution, or review re-trigger. After approval, push silently, resolve only reviewed and addressed thread IDs via GraphQL, and — when the approved push addressed Codex comments — re-trigger once with gh pr comment $1 --body "@codex review".
4. Apply the same no-inline-reply loop to github-code-quality[bot] findings; do not re-trigger Codex solely for non-Codex bot findings unless Codex comments were also addressed.
5. Monitor CI (gh pr checks $1) and repeat until no actionable comments remain. For draft PRs, mark ready after explicit approval once Codex is clean and local validation passes on the current head (default pixi run test-all, plus pixi run -e cuda test-all on Linux hosts with a visible NVIDIA CUDA runtime); merge still waits for required hosted checks.

Output

• PR number and whether the pass was a review or a feedback round
• Findings or fixes applied, with file/line references
• Which actions were local-only and which external mutations were explicitly approved
• Codex/CI state and any remaining blocker