Develop: Refactor Build
Refactor the app by executing every task in docs/REFACTOR.md, in order, until all tasks are checked off.
Setup
Read docs/REFACTOR.md first — it is the source of truth for what to change and in what order, and it encodes decisions already made with the user. Do not relitigate them. docs/PRD.md is the spec the refactor is converging on; docs/DESIGN.md holds the visual design tokens. Do not load these wholesale — each phase lists the specific Reference sections to read, plus whatever a task's Notes line points to. If docs/REFACTOR.md is missing, stop and tell the user to run studio-develop-refactor-plan first.
Work loop
Repeat until every task in the refactor plan is complete:
- Find the first unchecked task (
- [ ]). Tasks are ordered intentionally — removals and foundations come before rebuilds. Never skip ahead.
- Read what the task needs — its Files and Notes lines, plus the current phase's Reference sections if not yet read this session.
- Implement the task exactly as specified. Follow the repo's
CLAUDE.md/AGENTS.md guidelines: surgical changes only — touch what the task names, don't "improve" adjacent code, and remove any imports, variables, or files your change orphans.
- Test and verify before moving on. Run the verification step at the end of the task's Notes, run the app, and run the test suite — a refactor's first job is to not break what works, so existing tests passing is part of every task's definition of done. If the task changes behavior intentionally, update the affected tests and say so. If verification fails, fix it first — never mark a failing task complete or start the next task with the app broken.
- Mark the task complete — change
- [ ] to - [x] and update the header status line (**Status:** X/Y tasks complete, **Current Phase:** ...).
- At each phase boundary: run the app end to end and confirm the phase's Goal is true. Commit with a message
Refactor Phase {N}: {Phase Title} summarizing the goal and completed task range, then push and keep going — there's no need to open a pull request or pause for review between phases. If the phase touched auth, payments, user input, or data access, run the coding agent's built-in review (/review in Claude Code, or the equivalent in Cursor or Codex) and address the findings before continuing.
Rules
- The plan's keep/remove decisions are final — if a task removes a feature, remove it cleanly; don't preserve it "just in case".
- The PRD's stack choices are final — implement them, never substitute alternatives.
- Visual styling comes from
docs/DESIGN.md tokens — never invent colors, type, or spacing.
- If a task is ambiguous or conflicts with the PRD, check the PRD section it references; if still unclear, ask one specific question rather than guessing.
- If you discover work the plan doesn't cover (e.g. a hidden dependency on removed code), surface it and propose adding a task — don't silently expand scope.
- Keep going until
**Status:** Y/Y tasks complete: every task checked, every phase verified, all tests passing, codebase fully aligned with the PRD.
1---2name: studio-develop-refactor-build3description: Use in the app repo — the repository that contains `productos/` — when `docs/REFACTOR.md` exists (generated by `studio-develop-refactor-plan`) and the user wants the refactor executed. Triggers on phrases like "run the refactor", "execute the refactor plan", "work through REFACTOR.md", "start refactoring", "apply the refactor plan", or any request to carry out the planned refactor task by task. Works through every task in `docs/REFACTOR.md` in order — implementing, testing, and verifying each before moving on, marking checkboxes and updating the status line, committing at each phase boundary — and runs until all tasks are complete and the codebase is fully aligned with `docs/PRD.md`.4---56# Develop: Refactor Build78Refactor the app by executing every task in `docs/REFACTOR.md`, in order, until all tasks are checked off.910## Setup1112Read `docs/REFACTOR.md` first — it is the source of truth for what to change and in what order, and it encodes decisions already made with the user. Do not relitigate them. `docs/PRD.md` is the spec the refactor is converging on; `docs/DESIGN.md` holds the visual design tokens. Do not load these wholesale — each phase lists the specific Reference sections to read, plus whatever a task's Notes line points to. If `docs/REFACTOR.md` is missing, stop and tell the user to run `studio-develop-refactor-plan` first.1314## Work loop1516Repeat until every task in the refactor plan is complete:17181. **Find the first unchecked task** (`- [ ]`). Tasks are ordered intentionally — removals and foundations come before rebuilds. Never skip ahead.192. **Read what the task needs** — its Files and Notes lines, plus the current phase's Reference sections if not yet read this session.203. **Implement the task** exactly as specified. Follow the repo's `CLAUDE.md`/`AGENTS.md` guidelines: surgical changes only — touch what the task names, don't "improve" adjacent code, and remove any imports, variables, or files your change orphans.214. **Test and verify before moving on.** Run the verification step at the end of the task's Notes, run the app, and run the test suite — a refactor's first job is to not break what works, so existing tests passing is part of every task's definition of done. If the task changes behavior intentionally, update the affected tests and say so. If verification fails, fix it first — never mark a failing task complete or start the next task with the app broken.225. **Mark the task complete** — change `- [ ]` to `- [x]` and update the header status line (`**Status:** X/Y tasks complete`, `**Current Phase:** ...`).236. **At each phase boundary:** run the app end to end and confirm the phase's Goal is true. Commit with a message `Refactor Phase {N}: {Phase Title}` summarizing the goal and completed task range, then push and keep going — there's no need to open a pull request or pause for review between phases. If the phase touched auth, payments, user input, or data access, run the coding agent's built-in review (`/review` in Claude Code, or the equivalent in Cursor or Codex) and address the findings before continuing.2425## Rules2627- The plan's keep/remove decisions are final — if a task removes a feature, remove it cleanly; don't preserve it "just in case".28- The PRD's stack choices are final — implement them, never substitute alternatives.29- Visual styling comes from `docs/DESIGN.md` tokens — never invent colors, type, or spacing.30- If a task is ambiguous or conflicts with the PRD, check the PRD section it references; if still unclear, ask one specific question rather than guessing.31- If you discover work the plan doesn't cover (e.g. a hidden dependency on removed code), surface it and propose adding a task — don't silently expand scope.32- Keep going until `**Status:** Y/Y tasks complete`: every task checked, every phase verified, all tests passing, codebase fully aligned with the PRD.
buildgreatproducts