Ship a multi-PR feature with Cursor Projects

What you will learn

• What Cursor Projects is, and how a coordinator differs from a normal Agent chat
• When to start a Project instead of staying in a single chat
• How to run a small multi-step feature through a Project: describe work, review the plan, give one round of feedback, and see pull request(s)
• How shared context and cloud-by-default runs help work that outlives one session
• Where subscriptions (PRs, schedules, Slack) fit once the basic loop works

First success: you start a Project from the left nav, ship a small multi-step feature with at least one pull request, and leave feedback the coordinator can reuse.

Prerequisites

• Cursor installed and signed in (Projects is rolling out in beta to all users from 10 September 2026)
• A repository you already know (Next.js, Expo, or similar is ideal)
• GitHub connected the way you normally open PRs from Cursor / your course setup
• A feature idea that needs more than one tidy change (UI plus API, or settings plus persistence)

If Projects is not visible in your left nav yet, you are still on the rollout queue. Keep using Agent chat for short tasks and check Cursor again after an update.

Official reading:

• Introducing Projects (10 September 2026)
• Changelog: Cursor Projects

Core concepts

Coordinator versus chat

In a normal Agent chat, you talk to one agent that plans and edits in that thread. When the thread gets long, context gets noisy. When you close the laptop, local work stops.

In a Project, you chat with a coordinator. The coordinator does not write the product code itself. It plans, delegates implementation to other agents (including cloud agents), and brings finished work back for you to review. You stay in the director's chair.

Shared context

Each Project keeps files that sync across the cloud and local machines its agents use. Agents store research, how to test a service, and what you preferred in earlier feedback. That context grows over the life of the Project, so you do not re-onboard a new chat every morning.

Cloud by default

A Project runs on its own computer in the cloud, so closing your laptop does not stop delegated work. When something must run on your machine (device smoke test, local-only secret, interactive UI check), the coordinator can start a local agent for that piece.

When to choose a Project

Start a Project when the work will outlive one session: several PRs, a migration, or a job you want watched while you are away. Stay in normal chat when the task fits in one sitting and one review.

Step-by-step: ship a small multi-PR feature

Use a feature that is real but contained. Example: add a new section to an existing settings screen (label, toggle or text field, and persistence). Adapt the wording to your stack.

1. Open your app repository in Cursor

Open the folder you already develop in. Confirm you can create a branch and open a PR the usual way. You do not need a greenfield app.

2. Start a Project from the left nav

In the left-hand navigation, open Projects and create a new Project. Give it a clear name, for example settings-notifications-section.

Attach or select the repository you have open. You are now talking to the Project's coordinator, not a throwaway chat.

3. Describe the feature as multi-step work

Write a brief that forces planning across more than one change. Example prompt:

Add a "Notification preferences" section to the existing settings screen.

1. UI: section heading, email toggle, push toggle, short helper text matching nearby styles.
2. Persistence: save preferences with the same pattern this app already uses (API route, Supabase table, or local store - follow existing code).
3. Open a pull request for the UI, and a second PR for persistence if that keeps review safer. Propose a short plan before editing. Do not invent a new design system.

Ask for a plan first. Coordinators shine when you require a plan you can correct before agents fan out.

4. Review the plan, then let it work

Read the coordinator's plan. Check:

1. Does it reuse existing settings patterns?
2. Are the PR boundaries sensible?
3. Are tests or manual checks named?

Reply with concrete corrections in one message if needed, for example: "Use the existing SettingsSection component" or "Put persistence in the same module as theme preference." Then tell it to proceed.

While it works, agents may research the codebase and write notes into the Project's shared context. You can leave the Project running in the cloud if you step away.

5. Give one round of feedback on the result

When the coordinator reports progress or opens PR(s):

1. Skim the diff like a code review
2. Leave one focused feedback round ("helper text is too long", "toggle labels should match Marketing emails style")
3. Let it apply fixes rather than hand-editing everything yourself

That feedback also teaches the Project for later turns.

6. Confirm the PR(s) exist

Open GitHub and confirm the pull request(s) the coordinator created. Merge only when you are happy; Projects accelerate work, they do not replace your review.

First success looks like: a Project named for the feature, at least one PR from that Project, and one feedback round that improved the result.

Check your understanding / common mistakes

Quick check

1. Who writes most of the code in a Project: you, the coordinator, or delegated agents?
2. Should you use a Project for a one-line typo fix?
3. What survives across sessions that a normal chat often loses?

Answers

1. Delegated agents implement; the coordinator directs; you review and steer.
2. No. Prefer a normal Agent chat for tiny work.
3. Shared Project context (research, preferences, how to test).

Common mistakes

• Treating the coordinator like a single chat agent and stuffing huge unstructured dumps into one message. Give a multi-step brief and demand a plan.
• Starting a Project for every micro-task. You will drown in empty Projects. Reserve them for work that spans sessions or PRs.
• Skipping review because "the agents opened a PR". You still own merge quality.
• Never correcting the plan. Early steering is cheaper than fixing three wrong PRs.
• Forgetting cloud-by-default: closing the laptop does not mean the Project stopped. Check status before starting duplicate work.

What's next / Going further

Subscriptions (brief)

Once the basic feature loop works, the coordinator can subscribe to signals instead of waiting for your next prompt:

• Follow your PRs (for example help with CI failures)
• Run on a schedule
• Watch a Slack channel for bug reports

Start with PR follow-up after you trust the Project on a known feature. Connect Slack only when you have a clear channel and triage rules. Details: Introducing Projects.

Patterns Cursor's team uses

The launch post describes three practical patterns:

1. Feature work - research, plan, parallel implementation, local try-out, then monitor after ship
2. Migrations - agree a safe approach, then apply it across many PRs with decreasing review intensity
3. Gardening - ongoing quality work driven by subscriptions

Use those as mental models once your first feature Project feels natural.

Beta note

Projects launched in beta on 10 September 2026 and are rolling out to all users. UI labels may shift slightly as the beta continues; the coordinator model (you direct, agents implement, context accumulates) is the stable idea to learn.

Next step after this guide: pick a real multi-PR feature in your Buildcamp app, keep the Project alive through merge, and only then add a subscription.