The four beats of the daily loop

The loop: read → propose → review → commit

Every one of the four gestures in this chapter is a move inside one repeating rhythm. Worn in, it’s four beats:

1. Read. Understand what’s there before you change it - yourself, or by handing the agent the files with @ and asking what’s going on. On inherited code you don’t trust, this beat is not optional; it’s the one that stops you from confidently fixing the wrong thing.
2. Propose. Make the change with the smallest gesture that fits - Tab for the keystrokes you’d type anyway, Cmd/Ctrl+K for a bounded local edit, the Agent for a described outcome. The proposal is the agent’s, or yours; either way it arrives as a diff, not a fait accompli.
3. Review. Read the diff change by change. Keep what’s right, undo what isn’t, re-prompt for the gap. Lean on checkpoints to back out a run that wandered. Nothing lands unread.
4. Commit. The moment a change is green - tests pass, you’ve read it, it does what the ticket said - commit it. A reviewed, green, committed change is a save point you can build the next change on without fear.

# One turn of the loop on budgetcli - the date bug's quieter cousin:
# negative balances render without a sign in the overspend report.

read    →  @src/report/report.ts @tests/report.test.ts  where does the report format
           a balance? does it ever drop the minus sign?

           → balances format via formatMoney(); for values < 0 it strips
             the sign before the currency symbol. tests/report.test.ts has
             no negative-balance case.

propose →  (Agent) fix formatMoney so negatives keep their sign, and add
           a report test case for an overspent account.

           ⏵ Edit  src/report/report.ts   → preserve sign in formatMoney
           ⏵ Edit  tests/report.test.ts   → add negative-balance case
           ⏵ Run   npx vitest src/report/

review  →  diff: formatMoney change is right - keep. test case asserts
           "-$40.00" - correct, keep. npx vitest → ok.

commit  →  git commit -m "fix: keep minus sign on negative balances"

That’s the day. Not one heroic prompt, but the same four beats run forty times, each one cheap because you reached for the right-sized gesture and never let an edit land unread.

Read before you edit

The loop’s read beat has its own gesture - when you can’t yet name the change, drop the agent into a read-only posture before you escalate to one that can edit - but that dial belongs to the modes chapter, which owns the Ask → Agent escalation and the Shift+Tab chord that cycles postures.

The skill, restated

The daily loop isn’t five features to memorize. It’s one rhythm - read → propose → review → commit - run with the smallest gesture each beat allows:

• Tab finishes keystrokes you were already making. Read its guesses; don’t autopilot.
• Cmd/Ctrl+K does the bounded local edit you can scope with a selection.
• The Agent sidebar does the outcome you can describe but not type.
• @ attaches, / runs - the grammar under every prompt.
• Diffs are your veto; keep and undo per change, never unread.
• Checkpoints are your fine-grained undo inside an un-committed run; git is your save point once it’s green.

The person who’s merely installed Cursor types into the Agent for everything and accepts whatever diff comes back. The person who’s good with it feels which rung each edit wants before they touch the keyboard, reads every diff like a review, and commits the second a change is green - so the next one starts from solid ground.

Every beat of that loop assumes something you haven’t yet set on purpose: how far the agent is allowed to go before you look. That posture is one chord away, and it’s the next chapter. Next: Ask, Plan, Agent, and Debug.