Code Review

When to use

Use when you have a local git repo and a base ref to diff against (e.g. upstream/main, origin/master, or a commit SHA) and you want a single merged review from:

•codex review
•PAL codereview (run via pal-mcporter)

Inputs

•path: repo root directory (prefer absolute)
•compare_to: git ref to compare against (e.g. upstream/main)
•extra (optional): focus areas (perf, security, tests, API, etc.)

Workflow

1) Ensure the base ref exists locally

•cd <path>
•
If compare_to is a remote ref like upstream/main, ensure it’s present:
- •git fetch <remote> <branch>

2) Run Codex review + PAL codereview (parallel)

These two passes are independent once compare_to exists locally, so run them in parallel to reduce wall-clock time.

•
Codex review (capture as codex_review):
- •cd <path> && codex review --base "<compare_to>"
- •Note: the current codex review CLI does not accept a custom prompt when --base is used; run it without a prompt.
•
PAL review via MCPorter (capture as pal_review):
- •bash "<path-to-pal-mcporter-skill>/scripts/pal" -o markdown codereview --step "Review changes vs <compare_to>. <extra>" --step-number 1 --total-steps 1 --next-step-required false --findings "" --model auto --review-validation-type internal --review-type quick --severity-filter all --focus-on "<extra>"

Implementation note (when tool-parallelism is available): use multi_tool_use.parallel to run two functions.exec_command calls concurrently (one for codex review, one for pal ... codereview).

3) Merge feedback into one review

•Deduplicate overlapping findings; reconcile disagreements (call them out explicitly).
•
Prioritize into:
- •Blockers (must fix): correctness, security, data loss, breaking API/ABI, missing tests, CI failures.
- •High-signal improvements: maintainability, performance, edge cases, observability.
- •Nits: style/consistency (only if low-noise).
•End with a short verification checklist (tests to run, manual steps, rollout risk).