Cursor for Web Developers.

You don't need 12 hours of setup. You need three things in the right place: an AGENTS.md, the right model in the model picker, and a sane .cursorignore.

# Project — short name

## What this is
One-paragraph description of the app and stack.
Mention build tool, framework, package manager, deploy target.

## File map
- `src/app/`        — routes and pages
- `src/components/` — shared UI
- `src/lib/`        — server-side utilities
- `tests/e2e/`      — Playwright suites

## Conventions
- Components use BEM class naming.
- No utility CSS frameworks; design tokens live in `src/styles/tokens.css`.
- Server actions go in `*.action.ts`, not inside components.
- All copy is editable via `src/copy/` JSON files.

## Do not touch
- `legacy/` — being decommissioned, do not extend.
- `vendor/`, `dist/`, `.next/` — generated.

## Commands
- `pnpm dev` — local server
- `pnpm test` — full suite
- `pnpm lint --fix` — before commit

# build output and bloat
dist/
build/
.next/
out/
node_modules/
.turbo/
coverage/

# lockfiles confuse more than they help
package-lock.json
pnpm-lock.yaml
yarn.lock

# sensitive
.env
.env.*
*.pem

# big binary assets
public/**/*.{jpg,png,mp4,webm}

The .cursorignore matters more than it looks. If the agent thinks node_modules/ is fair game it will happily read 500MB looking for an answer.

Cursor's model picker isn't a "favorite." It's a per-task choice. The Sonnet rule from the cost guide applies: most coding work is happily Sonnet-sized.

Custom modes are saved prompt-plus-tools-plus-model combos you can switch into. The built-in Ask, Agent, and Plan modes cover most work, but four custom modes are worth defining for web dev.

Tip: the trick with modes is constraining tools, not just the prompt. A read-only Review mode that physically can't write files is more reliable than one with the instruction "don't write files."

They look similar. They're not. Pick the right shape for the kind of guidance you're encoding.

The 80/20: one AGENTS.md, three or four globbed rules for must-have-every-turn conventions, then a stack of Skills for everything else. We publish a bunch of installable Skills at /skills/ built for this exact pattern.

Hooks run on agent events (pre-tool-call, post-edit, on-stop). Three are worth setting up for web dev:

• Format on save — run Prettier after every write so the diff stays clean.
• Lint on agent stop — run eslint --fix on edited files when the agent finishes a turn.
• Test on stop, scoped — run only the tests affected by edited files (use vitest --related $(git diff --name-only)).

The trap is running too much in hooks. If your post-edit hook takes 12 seconds, the agent stalls 12 seconds every turn. Keep hook output under 2 seconds or move it to a CI step.

Every MCP server you add ships its tool definitions in every prompt. The slot is not free. Five MCPs that pull their weight for web devs:

1. Playwright MCP — drive a real browser from the agent. Game-changer for E2E test generation.
2. Browser MCP (lightweight) — inspect DOM, take screenshots, debug layout from chat. Cheaper than spinning up Playwright if you just need a snapshot.
3. Postgres / SQLite MCP — query your dev database without leaving the editor. Particularly good for "what does this query return?" loops.
4. Linear or GitHub MCP — only if you live in one of them. Lets the agent read tickets and update status as work lands.
5. Sentry / AppSignal MCP — surface real production errors as context. Pair with the observability section of the deploy guide.

Resist installing every shiny one. Two or three well-used MCPs beat a graveyard of unused ones with their tool descriptions burning context every turn.

Three execution modes, three intents:

Cloud agents are surprisingly cheap for what they do — Cursor amortizes the heavy lifting. Use them for: dependency upgrades, deleting dead code across a repo, scaffolding entire test suites, mechanical migrations. Don't use them for taste-heavy work (UI polish, copywriting) — you want to be in the loop for those.