Give Cursor a team that remembers why

Cursor chats forget. Close the tab and the next one does not know why you picked Neon over Mongo. Worse, a UI chat will quietly edit the API because nothing told it that Backend owns that folder.

I packaged the setup I actually use into cursor-agent-kit (source).

Install

npx cursor-agent-kit init

Run it at the repo root. It drops in the agent files, rules, and STATE templates. After that, you work in named chats instead of one endless thread.

The three pieces

Router — you describe the task in plain language. It returns a numbered chat plan: whom to @, Plan vs Agent mode, and a copy-paste prompt for each chat. You do not have to remember the specialist roster. The Router does.

Specialists — Master, Backend, Frontend, DevOps, plus any you add. Each one owns a directory. They do not wander into someone else's code. A Frontend chat should not rewrite the API. A Backend chat should not restyle the homepage.

STATE — the memory. Decisions live in files with IDs like D-BE-003. The next chat cites the ID instead of re-asking last Tuesday.

How STATE works

Each agent keeps a STATE.md. Think of it as a brain snapshot, not a changelog of every token the model emitted.

• Hot sections overwrite when something changes — the current focus, the active decision, the thing that would be wrong if it went stale.
• Cold sections append — history you might need later, not the live answer.
• Master compacts weekly so the files do not rot into a novel.

Agents are supposed to cite IDs. “We picked Neon because of D-BE-003” is cheaper than re-litigating the same database thread.

Handoffs are contracts

When work crosses a boundary, it is written down.

Backend writes what Frontend can call: routes, shapes, env names. Frontend loops back when the UI is wired, or when the contract is wrong. That loop is the point. A specialist that never reports back is just a silo with extra files.

The Router’s plan is how you start. The handoff is how you finish.

Why not “just better rules”

Rules describe how to work. They do not remember why you chose something.

A rule can say “don’t invent pricing numbers.” It cannot say “we rejected Mongo because of X, and the connection string lives here.” That is STATE.

STATE remembers the why. That is the difference between a pile of prompts and a team that still knows the port, the env pattern, and the rejected alternative.

After init

1. Open the repo root in Cursor so .cursor/rules/ and .cursor/skills/ apply.
2. Edit .cursor/rules/project-overview.mdc with the real product, URLs, and invariants.
3. Chat @router-agent plus the task. Do not ask it to implement. Ask it for the plan.
4. Open new chats from the Router’s prompts — one specialist per chat.
5. Let each specialist update its STATE.md before you close the tab.

Source: github.com/mdzyaan/cursor-agent-kit.