I'm a believer in Git from minute one. Even before there's an app, I want a remote, a history, and a place to push.

If you're collaborating, this is non-negotiable. If you're solo, it's still how you checkpoint your work and open PRs when you're ready.

I already have a repo ready on GitHub called FocusSync and I have Cursor open ready to connect.

All I need to do is choose clone repo and I'll paste in the path, then select clone from GitHub. A window opens and I select my folder locally and then open the Cursor window.

Let's have a quick look around before anything else. Your Cursor install might open a little different to mine, but intrinsically all the tools are there.

On the left, the quick access menu. This is the folder tree, extensions, and GitHub tools such as review and pull requests. When we select the file, the middle section is where we do our coding and we'll use this later. And over on the right, is the agent chat window where we'll do much of the interaction.

At the top, there are settings where you can tweak how your Cursor install works behind the scenes.

I will point out a key feature here. Right at the bottom of settings, you can see data sharing is set by default to share data. Eventually you'll use Cursor to work on proprietary code, and this is where you can stop anyone from being able to access your code base.

So, we have a Git repo with one commit and a dream. But before I let anything write code, I'm going to talk to the code base. Even when the code base is basically empty; well, that's called “ask mode”.

In the chat window, there's a drop down which is very easy to miss, but so very important. This gives us a choice of the contracts with AI. Ask, Plan, and Agent are our main focus here, but we also have Multitask and Debug modes.

We'll make sure Ask is selected as it lets us explore product thinking and architecture without the risks of editing or creating files I haven't asked for.

I'm going to paste in a prompt. Now I cannot overstate the importance of good prompting skills. Vague prompts gives you vague outputs and a load of assumptions made.

“I want to build FocusSync: a shared focus timer for remote teams. Hosts create a room with six-character codes, teammates join with a display name, everyone sees the same 25-minute focus or 5-minute break timer synced over WebSocket.

For V1: no auth, no database, in memory rooms only.

The stack should be Vite, React, TypeScript, Express, and WebSocket server. All around an NPM workspace. What are the main risks and what should the MVP include versus defer?”

Let's run this and see what it comes up with.

OK, let's see what this says. Good — it's flagging clock sync and host disconnect as risks. That's real. If everyone's timer drifts, the product is pointless. If the host closes their laptop and the room vanishes instantly, that's also very bad UX.

We'll address host disconnect with a grace period, and I'll add that in plan mode.

It's also suggesting we defer accounts persistence billing. Perfect. Scope creep kills MVPs.

See what Ask is doing? I'm having a design conversation with something that can hold context without touching disc.

I might disagree with it — actually, I want eight-character codes — and that's fine. We iterate that in chat.

Let me ask a follow up question; still Ask, still safe. “For WebSocket sync, should the server own the canonical timer and client render state? Or should clients run local timers and only sync on join? Recommend one approach for MVP.”

Let's run this and see what it comes up with. Server authoritative timer, clients render remaining.

Yeah, that's the right call for MVP. Simpler debugging. One source of truth. Clients aren't trusted to countdown correctly. I'm going to copy that decision mentally into our plan prompt.

This is a workflow tip. Asked to decide, plan to document, agent to implement. Don't skip ask just because the folder is empty.

I'll make sure I'm in plan mode and I'll paste in my prompt. Let's have a look.

“Plan the FocusSync MVP vertical slice:, NPM workspaces, a client, Vite React TS, server Express and WebSockets.

NPM run dev starts both client and server.

Server owns canonical time; client renders room state.

WebSocket messages: join_room, room_state, host_control, timer_tick.

Shared/types.ts — so all messages as discriminated unions with type field.

We need to be able to create and join. Plus, we need to think about the room view itself.

Session summary when focus block ends.

The room survives 10 minutes after host disconnect, then expires.

TypeScript strict, no ‘any’ at all.

Now README with manual test steps.

I've also said there list every file to create: phases, scaffold, WS protocol, UI polish. Do not write code yet. “

And let's run this code. While this prompt runs, Plan mode is doing what a good tech lead does in a design dock.

It's thinking about folder layout, message shapes, dev ergonomics. You'll see phases, file paths, maybe open questions.

It stopped here to get some clarity from us.

“During the 10-minute grace period after host disconnects, should the timer keep auto advancing (focus/break) server side while host controls stay disabled until the host returned?”

And it's given us some suggestions…

“Yes —timer auto advances start pause skip disabled until the host returns.”That's recommended.

“No — pause the timer when host disconnects, resume when host returns.”

“Promote olderst participant to host immediately on disconnect.”

I'll just go for the recommended option.

OK, and here is the plan. I like to treat these as a PR review and let's look at the points.

So, we have monorepos scaffold; everything shared, complete/shared/types.ts with constraints, an implementation of room store, room code, timer engine, and WebSockets server and handler.

It will implement the WebSockets client session storage, use WebSocket, use room state hooks. Excellent.

It'll build a landing page, room page, timer, participant list, host controls, connection status, room code badge, and user time display.

And session summary on focus end with a read me manual test checker. OK, perfect.

However, it didn't emphasize copy room code in the UI and I want that explicitly, so I'm going to edit the plan inline. This is crucial. Don't treat the plan as gospel.

There. Now the plan matches what I'd actually ship.

Another plan mode tip: if something feels oversized, add Redis. Delete it. Plan is cheaper than unwinding agent.

I'm satisfied. Build or implement plan depending on your Cursor version. This hands the approved plan to agent and watch the diffs roll in.

So, that's spun up and we can check that out in a second.

But first let's talk models, because which model is a question I get constantly. In this chat, I use Composer 2.5 for scaffold.

That's Cursor's own coding model, optimized for fast turns on real repos, good tool use, and semantic search.

For creating files, wire boilerplate, fixed TSC errors, Composer 2.5 is my default.

Open the picker, you'll see Claude family, GPT, Fable, Codex. The auto slider selects for you based on the ask. Fine when you don't care, but with more a complex task use the tool that works best for you.

Opus for when I'm in a debugging race. A subtle state machine bug, a nasty refactor. It's slower and pricier, but well worth it.

Sonnets the middle ground. Great for refactors and readable UI code.

Fable: I'll reach for it when I need a huge context read. “Explain the entire folder” —it breaks it down nicely.

MAX mode is more context window, higher cost. I toggle it for big refactors, not for a fix this bug.

Rule of thumb I say on every stream: Composer for speed, Opus for pain.

You can switch mid thread if you're stuck. Don't marry to one model.

So, I'll start a room on one browser and start the timer and then join the room from another browser. And there it goes. All synced, and that works quite nicely.

Two browser tabs, same room code, timers ticking together. That's product thesis. Everything else is just polish.

The UI looks like a hackathon project. Good with scaffold for correctness, not drivel.

Next I'll show how you polish fast without opening the agent chat.

Now Tab is the feature people skip out on. They install Cursor, live in agent chat, and miss the thing they'll use 50 times an hour.

Tab watches your recent edits in the surrounding code and linter errors, which is huge. It suggests multiline changes, adds an import, extends a union, and renames across usages.

First, I'm going to go into Shared and types.ts.

I'm going to find the export for host control message and there I'm going to add pipe reset.

When I scroll down now you can see is ClientMessage at the end. I can add double pipe and I get a suggestion, because Cursor knows I changed the file earlier. It tells me what to do next and I can accept that with tab.

I also want to create a new leave room message type after host control message.

I will export type “LeaveRoomMessage” and type “Leave_Room”. Cursor suggests a new edit on the export type line and at the bottom of the window a tab for next edit section.

When I hit tab, it takes me straight to where I need to edit following the changes I've just made.

There may be times when you know exactly what to change and where. This is where the inline editor, Ctrl and K really shines.

Let's say I want a bolder clock. In this version of FocusSync, the timer lives in Client, Source, Components, Timer.tsx — not a separate display file — and it gets formatted, phased, and status from the room snapshot.

I'll select the whole return block from the section down to the closing tag and press Ctrl + K. That opens the inline editor and I'll paste my prompt in there.

“Make the timer more dramatic. Larger monospace digits for the formatted time. Phase label above, status below. Use a circular or ring accent around the time. Keep using colour focus and colour break for phase accents. Keep timer props unchanged. Formatted phase and status. Add aria live equals polite on the time element for accessibility.”

When I click this now you can see Cursor gives me off a diff and after an initial quick review that all looks good to me. I'll accept and quickly spin up my app with NPM run dev.

And there it is, quite nice and bold.

No new chat, no risk it refactors your entire server because you said “make it pretty”.

Back to agent for work that spans files now. I want the summary session modal. The server emits an event, client shows a modal.

Well, there's a test involved there, and that's not just a Ctrl + K job.

I'm going to start a new chat window. I don't want plan mode context and tab renames polluting the thread. A little superstitious, but it's always worked for me.

Here's my prompt: “Add session summary when a focus block ends, a modal with duration and participant count. Start break for hosts. Server emits session summary, client handles it. Add one server unit test for focus and summary transition. Run tests, fix failures.”

This is what agent is good at; multiple files simultaneously edited for a new feature.

And with the app running on the host entity, I can click skip and you can see the modal opens on the client side and details number of participants and length of time.

AI is nothing without knowing what it's working with. We give Cursor context, as we call it, with at symbols.

Quick tour of at — the context you choose explicitly. At file is obviously a single file, at folder is everything under a certain path.

We could say at codebase, which semantically searches the repo, at web, fetches the URL. At docs if you've linked a framework document in your settings. At branch lets you check what's changed recently. Great for “why is this broken since yesterday”.

The failure mode is dumping at codebase on every prompt. Be stingy. Focus context is better diffs, lower cost, and fewer hallucinated files.

When we're happy, we push our changes to GitHub using the source control menu.

Always write a detailed commit message and Cursor can even do this for you.

There we have 0 to saved repo in around 15 minutes.

Introduction to AI enabled Software Engineering with Cursor (Demo Video)

About