| name | final-review |
| description | Run the repository's final independent Codex review after completing an implementation and its required verification. Use this before declaring implementation work complete. Apply a bounded review-and-fix loop rather than repeatedly reviewing until no possible finding remains.
|
Final Codex Review
Use this skill after the implementation and its required verification are
complete.
Run:
rtk proxy task review:codex
The runner uses automatic scope selection. A dirty worktree is rejected when
it also contains committed changes relative to the review base, because
--uncommitted would otherwise omit those committed changes. In that case,
commit or stash one scope first, or explicitly choose -ReviewMode base or
-ReviewMode uncommitted when reviewing only one scope is intentional.
The command intentionally suppresses the nested reviewer's intermediate
reasoning and tool output.
While it runs, heartbeat messages such as:
⠙ Codex review running... 00:01:15
mean the reviewer is still alive.
Do not cancel, restart, or duplicate the review while heartbeat messages
continue.
Review objective
Treat this review as an independent quality gate, not as a proof that the
implementation is free of every possible defect.
The objective is to identify and resolve high-confidence defects introduced by
the current change without entering an unbounded review-driven patch loop.
Prefer correctness and structural fixes over repeatedly extending local
fallbacks or special cases.
Handling a review
When a review completes:
- Read the entire review before editing code.
- Verify every actionable finding against the implementation.
- Classify each finding as:
- valid and blocking;
- valid and in scope;
- valid but better handled as follow-up work;
- unsupported or false positive.
- Fix valid in-scope findings as a batch where practical.
- Do not blindly apply unsupported or false-positive findings.
- Add focused regression coverage for defects that are fixed.
- Run targeted verification for the affected area after the batch of fixes.
Do not run the complete repository verification suite after every individual
finding unless repository policy or the nature of the change specifically
requires it.
Bounded review loop
Use the following review budget.
Pass 1 — full independent review
Run the normal final review after the implementation and initial verification.
Evaluate all findings before making review-driven changes.
If there are valid in-scope findings:
- fix them as a batch;
- run focused tests and relevant verification;
- then run one additional full review.
Pass 2 — convergence review
Use the second review to detect regressions introduced by the first batch of
review fixes and important issues missed by the first pass.
If Pass 2 has no blocking or clearly in-scope defects, stop the review loop.
P2/P3 findings that are valid but peripheral, pre-existing, speculative, or
better suited to separate work do not require another review cycle. Record or
report them as follow-up work when appropriate.
If Pass 2 exposes additional defects in the same mechanism that was repeatedly
patched during Pass 1, do not immediately continue adding special cases.
Reassess the design first.
Examples of a repeated-pattern signal include successive findings involving:
- additional branches or control-flow forms;
- increasingly specific syntax cases;
- repeated fallback-parser extensions;
- repeated state-machine exceptions;
- repeated compatibility exceptions around the same abstraction.
When this occurs, ask whether the implementation should instead:
- reuse an existing parser, IR, CFG, or semantic abstraction;
- narrow the fallback's responsibility;
- replace multiple special cases with one structural invariant;
- fail conservatively rather than emulate increasingly complex behavior.
Pass 3 — exceptional final review
A third full review is allowed only when resolving a qualifying Pass 2
finding requires a meaningful code change because of:
- a P0 or P1 finding;
- a clear regression introduced by review-driven changes;
- a structural correction needed to resolve a repeated class of defects;
- another correctness issue that would reasonably block merge.
After Pass 3, do not start another full review merely because a new non-blocking
P2/P3 observation is available.
If a blocking defect still remains after Pass 3, stop the automatic loop and
report the unresolved issue rather than continuing indefinitely.
Verification strategy
Use verification proportionally.
During review-driven iteration:
finding batch
↓
focused regression tests
↓
affected package / subsystem verification
Before declaring the task complete:
review fixes settled
↓
required full verification
↓
final review state assessed
Avoid repeatedly running expensive repository-wide validation when the code has
only received a small local fix and focused verification is sufficient for the
current iteration.
Repository policy may still require specific full checks before completion;
this skill does not override those requirements.
Severity and completion
Always resolve before completion:
- P0 findings;
- P1 findings;
- clear regressions introduced by the current implementation;
- high-confidence correctness defects directly within the requested scope.
Usually resolve P2 findings when they are directly caused by the current change
and can be fixed without substantially expanding the implementation scope.
A valid P2/P3 finding may be deferred when fixing it would:
- substantially broaden the task;
- introduce a new subsystem or abstraction;
- trigger a continuing chain of peripheral edge-case work;
- address behavior that is not required for the current change.
When deferring a valid finding, preserve enough detail for follow-up work and
mention it in the implementation summary.
Completion requires that no verified blocking finding remains and that the
change has completed the required independent review and verification within
the bounded process.
Failure
If the review cannot run because Codex is unavailable, authentication is
missing, or the local environment cannot launch it:
- do not repeatedly retry it;
- report the review failure in the final implementation summary;
- do not treat infrastructure failure as a code-review finding.
