refactor-optimization-plan

name	refactor-optimization-plan
description	Use when Codex needs to propose a safe refactor or optimization roadmap without changing code, including phases, affected files/modules, risk, tests, and rollback checkpoints.

Refactor Optimization Plan

Goal

Create a safe, phased refactor and optimization roadmap from audit findings. The plan must preserve behavior, name affected files/modules, and define validation gates before any implementation.

When to use

Use this skill when the user asks for refactor plan, optimization roadmap, phased cleanup, safe rewrite strategy, technical debt plan, or how to improve performance without risky changes.

Use after one or more audit reports exist when possible.

Required steps

1. Read relevant audit reports in docs/audits if present:
   • project intake
   • architecture/logic
   • system performance
   • frontend performance
   • backend/API performance
   • database performance
2. Re-check current repo files for any plan-critical evidence instead of trusting stale reports.
3. Define non-goals and behavior invariants:
   • public routes/API compatibility
   • data integrity
   • role/permission behavior
   • localization behavior
   • generated output boundaries
4. Group work into phases:
   • Phase 0: measurement and safety net
   • Phase 1: low-risk cleanup and local optimizations
   • Phase 2: module/API/query refactors that need tests
   • Phase 3: architectural changes or background-job/cache redesign
5. For each phase, list:
   • objective
   • affected files/modules/routes/models
   • risk level and priority P0/P1/P2/P3
   • required tests/verification
   • rollback or stop condition
   • dependency on earlier phases
6. Do not edit code unless the user explicitly asks to execute the plan.
7. Write the report in Vietnamese to docs/audits/refactor-optimization-plan.md.

Output format

Write a Vietnamese Markdown report with:

1. Muc tieu refactor
2. Nguyen tac an toan
3. Invariants can giu
4. Phase 0 - do luong va safety net
5. Phase 1 - cai tien it rui ro
6. Phase 2 - refactor can test ky
7. Phase 3 - thay doi kien truc
8. File/module/API/model bi anh huong
9. Validation matrix
10. Thu tu uu tien P0/P1/P2/P3

Each work item must include evidence source, expected benefit, affected surface, tests, and rollback/stop condition.

Quality checklist

• The plan is staged and reversible.
• No phase mixes unrelated ownership areas without reason.
• Every work item has validation.
• Architectural changes are clearly separated from low-risk fixes.
• The plan does not imply code has been changed.

Safety rules

• Do not modify code when producing the plan.
• Do not stage, commit, push, deploy, run migrations, reset data, or edit generated bundles.
• Do not invent file paths; verify affected files exist.
• Do not include secrets or private data in the plan.