# Cursor Projects: put the kit spine in the repo before you hand the coordinator the wheel

> Cursor Projects fleets only help when the owned repo is the source of truth. Put CLAUDE.md, .cursorrules, schema, and deploy in place before the coordinator invents disposable layout.
> By Dave · 2026-09-14
> Source: https://otf-kit.dev/blog/cursor-projects-owned-repo

Cursor Projects (announced September 10, 2026) is a coordinator that directs fleets of subagents across features, migrations, and ongoing "gardening" work. The coordinator does not write the product itself — it delegates. That only pays off if the repo it points at already has a kit spine: agent handoff files, schema, deploy, and reviewable conventions. Hand Projects the wheel on an empty tree and the fleet invents a disposable layout that looks busy and fails the first real merge.

This post is the pre-handoff checklist for that spine. It is not a [`.cursorrules` conventions guide](/blog/cursor-rules-nextjs), not a [plan / scope / verify agent session](/blog/cursor-agent-best-practices), and not a [hooks.json audit layer](/blog/cursor-agent-hooks). Those posts teach how to steer a single agent inside a repo that already exists. It is also not the trust thesis in [why AI-coded projects feel disposable](/blog/ai-coded-projects-feel-disposable) — that piece is about code quality after generation. Here the ICP is multi-agent fleets: they only help when the owned repo is the source of truth before the coordinator starts.

## What Projects actually ships

Cursor's launch post frames Projects as moving up a level of abstraction: you chat with a coordinator agent; it directs other agents that write code. Three capabilities make that workable for work that outlives a single chat ([Introducing Projects](https://cursor.com/blog/projects)):

1. **Cloud by default, local when needed.** The Project runs on its own computer so closing a laptop does not stop the fleet. Local agents spin up when something must run on your machine.
2. **Shared context.** Each Project maintains files that sync across cloud and local machines — research, artifacts, codebase notes, and how you prefer work done. If one agent learns how to test a service, later agents reuse those instructions.
3. **Subscriptions.** The coordinator can watch Slack, run on a schedule, or follow PRs — fixing CI and acting when PRs open or merge — without waiting for a fresh prompt.

Cursor reports using Projects for migrations of a few hundred PRs, design-system consistency, and shipping Projects itself. Their published productivity note: new users merge 30% more PRs; users who primarily use Projects merge six times as many. Treat those as vendor-reported outcomes, not your SLA.

The three in-house patterns they describe — feature work, migrations, and gardening — all assume the coordinator can read a durable product layout. Feature work starts with research recorded as shared context, then parallel implement-and-test agents. Migrations need a safe approach applied incrementally across the tree. Gardening watches PRs and Slack for recurring quality work. None of those patterns invent your domain nouns from scratch if the repo already encodes them.

## Why fleets invent disposable layout

Without a kit spine, parallel agents optimize for local completion, not for a product you can clone and ship next month. Common failure modes:

- **Layout by majority vote.** One agent puts API routes under `server/`, another under `apps/api/`, a third under `src/backend/`. Shared context records whichever path finished first. The next agent treats that accident as doctrine.
- **Schema by chat memory.** Tables appear as ad-hoc JSON blobs or one-off SQL files with no migration order. Seed data never matches the nouns the UI uses.
- **Deploy as a screenshot.** "It ran in the cloud agent" replaces a script you can re-run from CI. Promotion to your domain becomes a weekend archaeology project.
- **Handoff files written after the damage.** `CLAUDE.md` and `.cursorrules` get authored as summaries of what the fleet already did — not as constraints the fleet had to obey.

That is how a multi-agent week produces a demo that feels owned and a repository that is not. The disposable feeling is not mysterious; it is the absence of a source of truth the coordinator cannot override casually. The fix is chronological: put the kit structure in the repo **before** you hand Projects the wheel.

## What belongs in the repo before the coordinator

Treat the following as load-bearing artifacts under one git root you control. Kits such as OTF's SaaS Dashboard ship this shape on day 1 ([saas-dashboard](https://otf-kit.dev/templates/saas-dashboard), [kits overview](https://otf-kit.dev/docs/templates/overview)): client + API + Postgres migrations/seed + Stripe path + deploy script + agent handoff files (`CLAUDE.md`, `.cursorrules`, `AGENTS.md`) and tested prompts under `ai/prompts/`. You can start from a kit or assemble the same contract yourself — the point is that the contract exists before fleet work.

### 1. Agent handoff files (constraints, not memoirs)

Write short, version-controlled instructions the coordinator and subagents must read:

| File | Job |
|---|---|
| `CLAUDE.md` / `AGENTS.md` | Product nouns, forbidden areas, how to run tests, where secrets live |
| `.cursorrules` or `.cursor/rules/*.mdc` | Layout map, boundaries, examples to copy, verification checks |
| `ai/prompts/` | Named, reviewed asks ("add invite-by-email") — not blank "build the app" |

Keep rules scoped. A useful rules file maps the repository and the checks that prove a change belongs; it does not try to narrate every preference ([Cursor rules for app conventions](/blog/cursor-rules-nextjs)). For mobile trees, protect routing, data, and native boundaries the same way ([Cursor rules for mobile repos](/blog/cursor-rules-mobile-repo-production)).

Sketch of what "constraint, not memoir" looks like:

```md
# Agent handoff (excerpt)

## Product nouns
workspace, team, member, issue, notification — use these table names.

## Do not
- Add a second auth provider without a migration plan
- Put secrets in shared Project context files
- Invent a new top-level app folder; extend `apps/web` and `apps/api`

## Verify before claiming done
- `bun test`
- migration up + seed still boots a demo workspace
```

### 2. Schema and seed as the vocabulary

If day 1 has no migrations, every subagent invents shapes. If day 1 already has workspace / team / member / issue (or your domain equivalents) plus seed data, agents add columns against a known contract. Shared Project context should point at the migration folder — not paste a one-off `CREATE TABLE` into a chat artifact.

### 3. Deploy and environment contracts

Projects can run cloud agents and spin local agents for machine-specific tests. That does not replace your promotion path. Keep in the repo:

- A deploy script or documented pipeline that publishes under your domain
- Env templates (`.env.example`) with named variables — no live secrets in shared context
- Local run commands the coordinator can cite when it delegates "prove it boots"

### 4. CI as the fleet's stop condition

Subscriptions that fix CI are only useful if CI encodes your real gates. Wire the same checks you would require of a human PR: lint, typecheck, tests, migration dry-run. Then let the coordinator watch PRs. Do not ask the fleet to invent quality after the fact.

### 5. Review posture for early PRs

Cursor's migration pattern is explicit: early on you review each PR closely; as fixes hold up, you review less. Encode that as policy in the handoff files — which paths always need human approval (billing, auth, data deletion), which paths the coordinator may land after green CI. Pair that with hooks when you need hard blocks on risky commands ([Cursor hooks for production workflows](/blog/cursor-agent-hooks)).

![Kit spine before coordinator: handoff, schema, deploy, CI](https://cdn.otf-kit.dev/blog/cursor-projects-owned-repo/inbody-01-kit-spine-20260914a.jpg)

## How the coordinator should consume the spine

Shared context is an advantage only if it **extends** the kit, not if it replaces it. Practical rules:

1. **Source of truth order:** git kit files > Project shared context > chat memory. If shared context disagrees with `CLAUDE.md`, fix the file in git and tell the coordinator to re-read.
2. **Research goes into artifacts; contracts stay in the repo.** Let agents record how to test a service in Project files. Keep the product nouns and deploy path in the repository so a new Project or a human clone still works.
3. **Subscriptions need scopes.** Following all PRs is fine for gardening; following all Slack channels with write access to production is not. Mirror the same event-scoping discipline you would use for cloud agent subscriptions ([cloud agent subscriptions](/blog/cursor-cloud-agent-subscriptions)).
4. **Local agents are for verification, not ownership transfer.** When the coordinator starts a local agent to run the app on your machine, it should use your env and your deploy script — not create a parallel "works only here" path.
5. **One Project per durable body of work.** Features, migrations, and gardening can be separate Projects so shared context does not mix unrelated assumptions. The repo remains the shared spine across those Projects.

This is the same ownership split as other hosted harnesses: the platform may own session loop, subagents, and cloud machines; you still own skills, schema, deploy, and approvals ([OpenAI Agents API ownership](/blog/openai-agents-api-owned-repo)). Hosted shells and model routers change execution and deliberation; they do not invent your product policy ([OpenRouter hosted shell](/blog/openrouter-shell-owned-repo)).

## Pre-handoff sequence (do this before day-1 of a Project)

1. **Own a runnable monorepo.** Clone a kit or confirm your tree boots with seed data. Purchase path for OTF kits: Stripe checkout → license email with private GitHub invite → `git clone` → install → local dev → kit deploy when ready ([pricing](https://otf-kit.dev/pricing)).
2. **Commit agent handoff files** (`CLAUDE.md` / `AGENTS.md`, `.cursorrules` or `.cursor/rules`, `ai/prompts/`) that name nouns, boundaries, and verify commands.
3. **Confirm migrations + seed** explain the product in database nouns a human can click through.
4. **Confirm deploy + `.env.example`** — no secrets in the tree; promotion script documented.
5. **Turn CI green on a trivial PR** so subscriptions have a real signal.
6. **Write the Project brief** as "extend X under these constraints," not "build an app." Point the coordinator at the handoff files first.
7. **Start with one bounded feature or one migration slice.** Review every early PR. Widen autonomy only after the fleet stops inventing layout.
8. **Only then** enable Slack/PR subscriptions for gardening work that matches paths you already trust.

```bash
# Shape of a first Project ask (not a required CLI)
# 1) Read CLAUDE.md, .cursorrules, and apps/*/README
# 2) Add invite-by-email that creates team_member rows
# 3) Migration + seed update + tests
# 4) Open one PR; do not create a new top-level package
```

![Lock the owned repo as source of truth before the coordinator runs](https://cdn.otf-kit.dev/blog/cursor-projects-owned-repo/inbody-02-pre-handoff-20260914a.jpg)

## What ownership means once the fleet is running

Ownership is not "agents wrote a lot of files." Ownership is:

- **Source** — you can clone the repo without the Project UI
- **Data** — migrations and seed live in git, not only in shared context
- **Gates** — CI and human approval rules survive a new coordinator chat
- **Deploy** — a script or pipeline ships under your domain
- **Agent configs** — handoff files are reviewed like product code

When those are present, Projects' coordinator, shared context, and subscriptions amplify work that already has a center. When they are absent, the fleet manufactures a temporary center of its own — and you will recognize the result from [AI-coded projects that feel disposable](/blog/ai-coded-projects-feel-disposable): demos that do not survive a week of production review.

For builders who want the spine on day 1 instead of assembling it under fleet pressure, start from a kit that already includes agent handoff files and deploy docs — for example [saas-dashboard](https://otf-kit.dev/templates/saas-dashboard) or the full kit list on [otf-kit.dev](https://otf-kit.dev) — then open a Project against that clone. Cursor Projects is how you direct the fleet. The owned repo is still where the product lives.

## Sources

- [Introducing Projects (Cursor, September 10, 2026)](https://cursor.com/blog/projects)
- [OTF SaaS Dashboard kit](https://otf-kit.dev/templates/saas-dashboard)
- [OTF kits overview](https://otf-kit.dev/docs/templates/overview)
- [OTF pricing](https://otf-kit.dev/pricing)
- Related internal posts: [Cursor rules for app conventions](/blog/cursor-rules-nextjs), [Cursor rules for mobile repos](/blog/cursor-rules-mobile-repo-production), [Cursor agent best practices](/blog/cursor-agent-best-practices), [Cursor hooks](/blog/cursor-agent-hooks), [Cursor cloud agent subscriptions](/blog/cursor-cloud-agent-subscriptions), [Why AI-coded projects feel disposable](/blog/ai-coded-projects-feel-disposable), [OpenAI Agents API ownership](/blog/openai-agents-api-owned-repo), [OpenRouter hosted shell](/blog/openrouter-shell-owned-repo)