Your Monday Morning Plan With Cursor
This closes out the course by compressing lessons 1 through 9 into three moves. It assumes you've run the earlier lessons on order-api and leans on their vocabulary and examples throughout. If you jumped here first, lesson 0 is the two-minute version of the same argument without the recap.
The whole course, compressed
Here's ten lessons compressed into what actually happens Monday morning, in your own editor, on your own repo.
Lesson one's reframe was the whole argument in miniature: Tab-complete instincts are fast, cheap, and correct for a one-line suggestion, and they will walk you straight into approving a five-file Agent turn you never read, because the accept button looks the same either way. Lesson three named the three modes by scope, not by label: Tab at the cursor, Cmd-K inside a selection, Agent/Composer across as many files as the task needs. Module two turned that reframe into a routine on a real repo, order-api: write the conventions down once in .cursor/rules/*.mdc so Agent stops relearning your project every session, scope the request tightly enough that you know what the diff should look like before Agent writes a line, review what comes back the way you'd review a colleague's pull request, reach for a checkpoint when the diff is wrong instead of hand-patching it, and feed Agent the specific file, doc, or commit it needs with an @-mention instead of hoping it infers the right one. Lesson eight ran that same discipline against a diff that looked fine and wasn't, which is the case the whole course was built around.
Monday morning, in three moves
Not a toy repo, not a hypothetical. Something sitting in your actual backlog: a cache, a rename, a validation rule, a fix with a clear "done" you'd recognize on sight. Bounded the way lesson five's client.ts cache request was bounded: one file named, one method named, one behavior stated, explicit about what Agent shouldn't touch. If you can't say in a single sentence what the diff should contain before you send the prompt, the work isn't scoped yet.
Before the first Agent request, not after. Five to ten lines is enough: the conventions your team already carries in its head and repeats to every new hire, the ones Agent has no way to guess from reading the source alone. Which classes stay thin wrappers, which export style your codebase uses, what needs a test before it ships. Save it to .cursor/rules/<project>.mdc, scope its globs to the part of the tree it actually governs, and say nothing about it in your prompt. If the first answer you get back cites a convention unprompted, the file landed.
Send the scoped request. When the diff comes back, check it against the prompt the way lesson six walked through: does the change stay inside the file and method you named, does it do only what you asked, did anything move outside the stated boundary. Keep the checkpoint as the safety net it is, not a stand-in for reading, a way to throw out the whole turn for free if the diff doesn't match what you asked for, not an excuse to skim it faster.
What actually compounds
A successful Agent turn that never makes it into a rule file doesn't compound. It's one clean diff, on one task, and the next person, maybe you in three weeks, starts from zero and re-explains the same convention Agent could have already known. The run that gets written down is the one that changes what every future session starts with, the same distinction lesson four made about order-api: the rule file isn't documentation for a human teammate, it's context Agent reads automatically, every session, without being asked. Lesson four's own "proving it landed" section made this concrete rather than leaving it as a claim in the abstract: order-api.mdc's thin-wrapper convention, written once, then cited back unprompted the first time Agent was asked a question that touched it. A win nobody wrote down is a nice half hour. A win that lands in .cursor/rules is the thing the whole team gets by default from here on.
Not a toy. The one that's been sitting there because it felt too small to plan properly and too fiddly to do by hand. That's exactly the shape this course was built for: bounded, verifiable, real.
What decides how hard you look
The whole course, in two sentences
Cursor's agent is only as trustworthy as the review habit you bring to it, and Cursor gives you the diff view, the checkpoint, and the rule file to make that review cheap. None of that is automatic: you decide the scope, you read the diff, and you write down what worked, and that decision is the discipline this course spent ten lessons building.
That's all ten lessons. Revisit any of them, or open your own repo and run the first move for real.
Reply here and it goes straight to Rod. Same as replying to one of his emails.
