| name | review-fix |
| description | Apply accepted related findings from an implementation or implementation-plan review by resuming the same reviewer task_id. Use after review-implementation or review-implementation-plan returns Needs Rework or Needs Revision. |
| license | MIT |
| compatibility | {"opencode":">=0.1"} |
| metadata | {"category":"review","phase":"remediation"} |
Skill: Review Fix
This skill is the default remediation path after a review. It preserves the reviewer's context instead of making a new agent reconstruct it from files and artifacts.
The primary SHOULD resume the reviewer that produced the findings using the same task_id. The reviewer may apply related fixes across several files, call sites, and tests when they remain part of the reviewed objective. A new implementation session is an exception, not the default.
When to Use
Use after:
review-implementation-plan identifies corrections to an implementation plan.review-implementation identifies code, test, configuration, or integration corrections.
Do not use for:
- Initial review work.
- Plan review corrections; plans remain conversation-owned by the primary. Resume the reviewer for clarification, then update the plan through
update-plan.
- A genuinely new objective, changed gated scope, new dependency decision, or user-requested independent perspective.
- An unavailable, stale, or deliberately discarded reviewer session. Use
execute-work-package for new runtime work or author-and-verify-implementation-plan for new implementation-plan work.
Required Inputs
The continuation prompt SHOULD provide:
- Review artifact path.
- Accepted finding IDs or a clear description of the accepted findings.
- Target type:
implementation-plan or implementation.
- Relevant scope or primary decisions. Do not require an exact file allowlist when related call sites or tests need to be discovered.
- A verification command or the expected verification goal. The reviewer may choose a focused command when none was supplied.
Use tpl-review-fix-prompt.md and resume the same reviewer task_id.
Protocol
- Read the existing review artifact and use the existing session context.
- Confirm the requested fixes still serve the reviewed objective.
- Apply the necessary related corrections. Size alone does not require a new work package.
- Run focused verification or document consistency checks.
- Return the compact digest below.
Remediation posture
No Gold-Plating. No Adversarial Reviewing. No Scope Creep. Fix accepted,
evidence-backed findings and the related changes required to complete them. Do
not use remediation to invent improvements, reopen rejected findings, or
create another review/fix cycle.
The accepted findings and reviewed objective are the gate. Do not add unrelated improvements or silently change the objective. If a new decision is required, report it to the primary; do not invent a new gate or switch agents autonomously.
Write Boundary
- For
implementation-plan, edit the relevant implementation-plan artifacts and related references required by the accepted findings.
- For
implementation, edit related code, configuration, integration points, and tests required by the accepted findings.
- Do not modify the review artifact; it remains the immutable record of the independent review.
- Do not modify phase scope, acceptance criteria, or unrelated docs/plans.
- Do not perform Git history operations.
Output Contract
Return only:
- Outcome: succeeded | partial | blocked
- Findings: fixed and unresolved finding IDs
- Edits: changed files with one-line descriptions
- Verify: command/checks and result
- Next: whether targeted verification is sufficient or an independent re-review is recommended
Independent Re-review
The remediation pass is not an independent review. A fresh review is optional and requires an explicit primary or user decision. Recommend it when:
- the primary wants an independent final opinion;
- the fix exposes uncertainty that the current reviewer cannot resolve;
- security, persistence, public API, or migration risk warrants another perspective.
Do not start a fresh review merely because a fix spans several files or changes runtime code. Do not automatically chain review -> fix -> review -> fix. After one remediation pass, stop at the primary's decision unless another review is explicitly requested.
Rules
- Same
task_id is the preferred path. If the original reviewer session cannot be resumed, use a new workflow rather than pretending the new agent has the old context.
- Keep the same delegate model/variant while resuming.
- Do not re-open already rejected findings unless the primary explicitly asks for reconsideration.
- Do not describe self-verification as an independent review.
- Never weaken, delete, or skip tests to make verification pass.
