cursor-build-loop
Cursor Build Loop
Quality-gated feature work: nothing ships on "it compiles" — every increment is built, reviewed, tested end to end, and fixed before the user hears "done."
Source of work
- A plan file exists (roadmap, refactor plan, or task list with
- [ ]checkboxes — search the repo): work the first unchecked task. In a ProductOS repo the plan files aredocs/ROADMAP.md,docs/REFACTOR.md, and — when the user asks for security fixes — the Fix plan indocs/SECURITY-AUDIT.md;docs/PLAN.md(the programme plan) and theproductos/*-CHECKLIST.mdfiles are never build plans; ignore them even though they contain lists. Tasks are ordered intentionally — never skip ahead. If the plan references spec docs, read only the sections relevant to the current task. - No plan (or the request is outside it): build from the user's prompt. Restate it as a verifiable goal with 2–4 success criteria and confirm scope in one message before building.
The loop
Run per task (or per prompted feature). Do not advance until every step passes.
-
Build. Implement exactly what the task specifies. Simplest implementation that satisfies it, surgical changes, no speculative scope. Match existing project conventions.
-
Review. Run Cursor's
/reviewon the changes. If the change touches auth, payments, user input, or data access, run a second review pass focused on security — prompt Cursor to review the diff specifically for vulnerabilities (injection, authorization gaps, secrets exposure, unsafe input handling), or let Bugbot review the PR if it's configured. Fix all findings in scope — bugs, security issues, edge cases, performance, style in files you touched. If the project has a design system spec (design tokens file, DESIGN.md, theme config), check UI changes against it — no hardcoded colors, type, or spacing that bypass tokens. Note pre-existing issues in untouched code for the report instead of fixing silently. Re-run/reviewuntil clean. If a finding contradicts the task or spec, the spec wins — flag the disagreement. -
Test end to end. Run the task's verification step (or the success criteria). Run the full test suite — everything that passed before must still pass. Add tests for new logic. Then exercise the feature as a user would: run the app, walk the real flow including empty, loading, and error states.