# Cy Fix Reviews

> Executes agent-authored review remediation using existing round files under .compozy/tasks/<name>/reviews-NNN/. Use when resolving batched review issues, updating issue markdown files, implementing fixes, and verifying the result. Do not use for task execution, review generation, or generic coding tasks without review issue files.

- Skill: `compozy/cy-fix-reviews` (Agent Skill)
- Install (CLI): `npx skillmds@latest add compozy/cy-fix-reviews`
- Raw SKILL.md: https://api.skillmd.com/api/skills/compozy/cy-fix-reviews/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML, Product & Planning
- Author: compozy (https://skillmd.com/u/compozy)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/compozy/cy-fix-reviews

---


# Fix Reviews

Execute the review remediation workflow in a strict sequence. The review files already exist and define the full scope for the run.

## Required Inputs

- The scoped issue files listed in `<batch_issue_files>`.
- The task review round directory and issue-file frontmatter.
- The repository verification workflow required by `cy-final-verify`.

## Workflow

1. Gather round context.
   - Read the scoped issue file frontmatter to understand the round number and issue status/severity. If multiple issue files are in scope, verify their `round` and `round_created_at` values agree.
   - Read `<batch_scope>` to identify the task name, review round, code files in scope, and conditional flags such as auto-commit.

2. Read and triage the scoped issue files.
   - Read every listed issue file completely before editing code.
   - Update each issue file frontmatter `status` from `pending` to `valid`, `invalid`, `unresolved`, or `blocked`.
   - Record concrete technical reasoning in `## Triage`: state why the issue is valid or invalid, identify the root cause if valid, outline the intended fix approach, or explain why it is unresolved/blocked.

3. Fix valid issues completely.
   - Fix issues in severity order: critical first, then high, medium, low. This ensures the most impactful fixes land even if the batch is interrupted.
   - Implement production-quality fixes for every `valid` issue in scope.
   - Name the changed invariant and its owning suite. Reuse existing coverage; add or update a test only for a coverage gap. Test edits needed to validate the fix are in scope.
   - Keep code changes constrained to the files listed in `<batch_scope>` code files. If a fix absolutely requires touching a file not listed there, limit the change to the minimum needed and document why in the issue file's `## Triage` section.
   - Do not refactor, clean up, or improve code that is unrelated to the issues being fixed.

4. Close out issue files correctly.
   - Leave a `valid` issue at frontmatter `status: valid` after the code and focused verification are done.
   - Leave an `invalid` issue at frontmatter `status: invalid` after documenting why it is invalid.
   - For a valid finding that cannot be resolved in this cycle because it requires an external change or an out-of-scope dependency, set frontmatter `status: unresolved` (or `blocked`), document the blocker in `## Triage` with `- Decision: UNRESOLVED` (or `BLOCKED`), and return `resolution: unresolved` (or `blocked`).
   - Never set `status: resolved`; the Loop's Go finalizer owns that transition after the batch completes.

5. Verify before completion.
   - Use `cy-final-verify` before any completion claim or automatic commit.
   - Run the real checks required for the scoped fix; reuse current evidence for unchanged inputs. The workflow owner handles remaining delivery gates.
   - If verification fails, fix the failing checks in the code you changed. Do not revert your fixes to pass verification -- find the root cause of the failure and address it. If the failure is in pre-existing code unrelated to your changes, document it in the relevant issue file’s `## Triage` section and proceed. If two fixes conflict with each other and verification cannot pass after two attempts, document the conflict in both issue files and report the situation rather than looping indefinitely.
   - If all issues in the batch are invalid and no code was changed, skip the commit step entirely -- do not create an empty commit. Cite the triage evidence; do not run product tests solely for issue-status prose.
   - Leave the diff ready for manual review unless `<batch_scope>` shows "Automatic commits: enabled".

## Critical Rules

- Do not generate another review inside this workflow. The reviewer agent already produced the round files.
- Do not publish or push changes. This workflow is local-only.
- Do not modify issue files outside the scoped batch.
- Do not create, rename, timestamp, or mark an issue `resolved`; the Go writer and finalizer own those bytes.