do-execute-review-fix

name

do-execute-review-fix

description

Recebe o caminho de um arquivo de fix task em review-fixes/ (ex: review-fixes/fix-R01-critico-senha.md), implementa a correção, roda a suite de testes e atualiza o status do arquivo. Use quando do-execute-review gerou arquivos de fix task e o usuário quiser resolver um problema específico. Não use para correções em lote — invoque uma vez por arquivo. Não use para QA, correção de bugs de QA (use do-execute-qa-bugfix) ou implementação de novas features.

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.

1. NEVER pause, stop, or wait for user input.
2. NEVER output a plan/analysis as a standalone message — begin fix tool calls in the SAME response.
3. NEVER ask the user questions. Resolve ambiguities from the fix task file, PRD, and TechSpec context.
4. 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:

1. Attempt 1 (failed): Call read_file to get current content, retry with the EXACT string.
2. Attempt 2 (failed): Try a smaller, more unique old_string.
3. Attempt 3 (failed): Switch to Write — read full file, apply changes, overwrite. HARD LIMIT: max 3 Edit attempts per change.

Directory Convention

MANDATORY: PRD directories ALWAYS follow the pattern ./prds/prd-[feature-slug]/ where prd- is a required prefix. Example: feature user-auth → directory ./prds/prd-user-auth/. NEVER reference a path like ./prds/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 ./prds/prd-[feature-slug]/review-fixes/fix-[R-XX]-[severidade]-[slug].md

If 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:

1. Check for .claude/ directory in the project root → Claude Code
2. Check for .github/copilot-instructions.md or .github/ directory → GitHub Copilot
3. Check for .cursor/rules/ or .cursor/mcp.json → Cursor AI
4. Check for opencode.json, .opencode/ directory, or AGENTS.md → Opencode
5. Resolve available tools based on environment:
   • TaskUpdate: available in Claude Code; in Copilot, Cursor, and Opencode, skip gracefully

Skill assets/references are loaded via your AI tool's native skill resolver — do not hard-code paths. Store the detected tool and capability flags internally.

Step 1: Context Analysis (Mandatory)

1. Read the fix task file provided by the user. If the file does not exist, halt and report.
2. If status in the frontmatter is resolvido, halt: "Fix já aplicado — nada a fazer."
3. Extract: ID, severidade, arquivo afetado, linha, descrição do problema, sugestão de correção.
4. Read ./prds/prd-[feature-slug]/review-report.md for additional context on the finding.
5. Read ./prds/prd-[feature-slug]/prd.md and ./prds/prd-[feature-slug]/techspec.md for context.
6. Read the project configuration file (CLAUDE.md, .github/copilot-instructions.md, or .cursor/rules/project.mdc) for project conventions.

Step 2: Plan Fix (INTERNAL — do NOT output as standalone message)

1. Identify affected files and determine root cause from the fix task description.
2. Define fix strategy.
3. 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)

1. Detect package manager from lock files (bun.lockb → bun, pnpm-lock.yaml → pnpm, package-lock.json → npm, default: npm).
2. Read the affected file(s) completely.
3. Implement the root-cause fix — no superficial workarounds.
4. Run typecheck if it exists in package.json.
5. Iteration limit: Maximum 3 fix-and-test cycles per finding. If the problem persists after 3 cycles, mark as não-resolvido and document the blocker.

Step 4: Run Full Test Suite (Mandatory Gate)

1. Run all tests using the detected package manager (e.g., npm test).
2. If all tests pass → proceed to Step 5.
3. 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.
4. 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)

1. Update the fix task file's frontmatter status:
   • Fixed: resolvido
   • Blocked: não-resolvido
2. Append a ## Resolução section describing the fix applied.
3. Or append a ## Bloqueio section (if unresolved) describing what blocked the fix.

Step 6: Update review-report.md (Mandatory)

1. Locate the corresponding finding entry in review-report.md by matching the ID.
2. Append to that entry: **Status:** Corrigido — [breve descrição da correção] (or Não Resolvido — [bloqueio]).
3. Do NOT modify original review metadata (date, branch, summary).

Step 7: Report Results (Mandatory)

1. If TaskUpdate is available, mark internal tasks as completed.
2. 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.
3. Inform the user: finding fixed (or blocked) and tests passing.
4. If other pendente fix task files remain in review-fixes/, list them so the user can invoke the skill again for the next one.
5. If all CRÍTICO and MAIOR findings are resolved: instruct the user to run do-execute-review to 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 pendente fix task files in review-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.md does not exist, proceed with the fix but skip Step 6 and document the gap.
• If PRD 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): ./prds/prd-[feature-slug]/review-fixes/fix-[R-XX]-[severidade-completa]-[slug].md
• Review Report: ./prds/prd-[feature-slug]/review-report.md
• PRD: ./prds/prd-[feature-slug]/prd.md
• TechSpec: ./prds/prd-[feature-slug]/techspec.md