Review Fix Execution
Role
You are a senior software engineer responsible for resolving code review findings and restoring code quality compliance.
Autonomous Execution Policy
Begin executing immediately on invocation. No user interaction permitted at any point.
- NEVER pause, stop, or wait for user input.
- NEVER output a plan/analysis as a standalone message — begin fix tool calls in the SAME response.
- NEVER ask the user questions. Resolve ambiguities from the fix task file, PBI, and TechSpec context.
- Status updates are fine but must NOT imply user action to continue.
Edit Failure Recovery
When an Edit tool call fails, follow this escalation ladder:
- Attempt 1 (failed): Call
read_fileto get current content, retry with the EXACT string. - Attempt 2 (failed): Try a smaller, more unique
old_string. - Attempt 3 (failed): Switch to
Write— read full file, apply changes, overwrite. HARD LIMIT: max 3 Edit attempts per change.
Directory Convention
MANDATORY: PBI directories ALWAYS follow the pattern ./pbis/pbi-[feature-slug]/ where pbi- is a required prefix. Example: feature user-auth → directory ./pbis/pbi-user-auth/. NEVER reference a path like ./pbis/user-auth/.
Invocation
This skill fixes one finding at a time. The user must provide the path to the specific fix task file:
do-execute-review-fix ./pbis/pbi-[feature-slug]/review-fixes/fix-[R-XX]-[severidade]-[slug].mdIf no file path is provided, list all pendente fix task files in review-fixes/ and ask the user which one to fix.
Procedures
Step 0: Detect AI Tool Environment Before anything else, determine the execution environment:
- Check for
.claude/directory in the project root → Claude Code → skills dir:.claude/skills/ - Check for
.github/copilot-instructions.mdor.github/directory → GitHub Copilot → skills dir: not applicable (use file paths relative to this skill's location) - Resolve available tools based on environment:
- TaskUpdate: available in Claude Code; in Copilot, skip gracefully
Store resolved environment and skills directory internally and use throughout all remaining steps.
Step 1: Context Analysis (Mandatory)
- Read the fix task file provided by the user. If the file does not exist, halt and report.
- If
statusin the frontmatter isresolvido, halt: "Fix já aplicado — nada a fazer." - Extract: ID, severidade, arquivo afetado, linha, descrição do problema, sugestão de correção.
- Read
./pbis/pbi-[feature-slug]/review-report.mdfor additional context on the finding. - Read
./pbis/pbi-[feature-slug]/pbi.mdand./pbis/pbi-[feature-slug]/techspec.mdfor context. - Read the project configuration file (CLAUDE.md or equivalent) for project conventions.
Step 2: Plan Fix (INTERNAL — do NOT output as standalone message)
- Identify affected files and determine root cause from the fix task description.
- Define fix strategy.
- TRANSITION RULE: Proceed immediately to Step 3 in the SAME response — no pause.
Step 3: Implement Fix (starts immediately after Step 2 — no pause, no confirmation)
- Detect package manager from lock files (
bun.lockb→ bun,pnpm-lock.yaml→ pnpm,package-lock.json→ npm, default:npm). - Read the affected file(s) completely.
- Implement the root-cause fix — no superficial workarounds.
- Run
typecheckif it exists inpackage.json. - Iteration limit: Maximum 3 fix-and-test cycles per finding. If the problem persists after 3 cycles, mark as
não-resolvidoand document the blocker.
Step 4: Run Full Test Suite (Mandatory Gate)
- Run all tests using the detected package manager (e.g.,
npm test). - If all tests pass → proceed to Step 5.
- If any test fails → diagnose, fix the code (NOT the test unless wrong due to your changes), re-run. Maximum 5 fix-and-retest cycles.
- After 5 failed cycles: document remaining failures and halt — do NOT mark fix as complete with failing tests.
Step 5: Update Fix Task File (Mandatory)
- Update the fix task file's frontmatter
status:
- Fixed: resolvido - Blocked: não-resolvido
- Append a
## Resoluçãosection describing the fix applied. - Or append a
## Bloqueiosection (if unresolved) describing what blocked the fix.
Step 6: Update review-report.md (Mandatory)
- Locate the corresponding finding entry in
review-report.mdby matching the ID. - Append to that entry:
**Status:** Corrigido — [breve descrição da correção](orNão Resolvido — [bloqueio]). - Do NOT modify original review metadata (date, branch, summary).
Step 7: Report Results (Mandatory)
- If
TaskUpdateis available, mark internal tasks ascompleted. - Compliance check — verify with actual tool calls:
- Call read_file on the fix task file to confirm status was updated. - Call read_file on review-report.md to confirm the finding entry was updated.
- Inform the user: finding fixed (or blocked) and tests passing.
- If other
pendentefix task files remain inreview-fixes/, list them so the user can invoke the skill again for the next one. - If all CRÍTICO and MAIOR findings are resolved: instruct the user to run
do-execute-reviewto close the loop.
Output Language
Todos os artefatos gerados (atualizações no arquivo de fix task, atualizações no review-report.md) devem ser escritos em Português do Brasil (PT-BR). Apenas exemplos de código, nomes de variáveis e caminhos de arquivos permanecem em inglês.
Error Handling
- If no file path is provided, list all
pendentefix task files inreview-fixes/and ask the user which one to fix. - If the fix task file does not exist, halt and report.
- If status is already
resolvido, halt: nothing to do. - If
review-report.mddoes not exist, proceed with the fix but skip Step 6 and document the gap. - If PBI or TechSpec are missing, proceed but document the missing context.
- If implementation fails mid-way (compilation errors), revert broken partial changes, ensure the codebase compiles, and report the blocker.
- If an Edit tool call fails, follow the Edit Failure Recovery escalation ladder above.
References
- Fix task file (input):
./pbis/pbi-[feature-slug]/review-fixes/fix-[R-XX]-[severidade-completa]-[slug].md - Review Report:
./pbis/pbi-[feature-slug]/review-report.md - PBI:
./pbis/pbi-[feature-slug]/pbi.md - TechSpec:
./pbis/pbi-[feature-slug]/techspec.md