agent-stack-template / rules
Cursor rule31 starsChanged 3 months agoMITView on GitHub
Product, stack and layer contract. Always applies.
- Reads credentials
Where files are headingNew Cursor rule files have more rules about planning and tracking tasks, and fewer about code style.
Of the Cursor rule files we read, the 4,187 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository20 other files it gives its agents.
- AGENTS.mdAGENTS.md
- .agents/skills/react-hook-form/AGENTS.mdAGENTS.md
- .agents/skills/vercel-react-best-practices/AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .cursor/rules/git-flow.mdcCursor rule
- .cursor/rules/performance.mdcCursor rule
- .cursor/rules/prisma-schema.mdcCursor rule
- .cursor/rules/server-actions.mdcCursor rule
- .cursor/rules/tdd-domain.mdcCursor rule
- .cursor/rules/ui-design-system.mdcCursor rule
- better-auth-best-practicesSkill
- better-auth-security-best-practicesSkill
- changelog-automationSkill
- frontend-designSkill
- interface-designSkill
- marketing-psychologySkill
- organization-best-practicesSkill
- react-hook-formSkill
- shadcnSkill
- vercel-react-best-practicesSkill
The file
We split this project.mdc into the rules it gives an agent
5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 22
If a feature spec is Draft, do not write product code.
- Distinctive: line 27
When they conflict, this order wins.
- Distinctive: line 35
If a spec lacks the detail you need, update the spec before writing code.
- Very specific: line 61
Every business row carries workspaceId.
- Distinctive: line 64
Commit only when the user asks.
≈ “Common” is an estimate: at least 1 in 5 of the 6,668 Cursor rule files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
--- description: Product, stack and layer contract. Always applies. alwaysApply: true --- # Project contract Full guide: `AGENTS.md`. This rule is the always-loaded summary; do not duplicate detail here, point to the document that owns it. ## Work type Classify first (`AGENTS.md` → "Every turn"). Open **that** guide only. - New behaviour **with** a domain rule → spec **Accepted** or **Shipped**, then `docs/guides/new-feature.md` - New behaviour **without** a domain rule → same guide; skip tests and `domain/`. Do not invent a function to TDD - Wrong current behaviour → `docs/guides/bugfix.md` - Same behaviour, new shape → `docs/guides/refactor.md` - Tooling / deps / CI / docs-only → `docs/guides/chore.md` - Problem without a spec → `product-manager`, no product code If a feature spec is Draft, do not write product code. TDD applies only when the change adds or breaks a domain rule — `AGENTS.md` → "Definition of Done". ## Sources of truth When they conflict, this order wins. Open a file only if this turn needs it. 1. `docs/specs/<feature>.md` — business rules. Never invent one. 2. `docs/architecture.md` — when a layer, auth, data or performance boundary moves 3. `docs/stack.md` — when adding or substituting a dependency 4. `docs/adr/` — accepted decisions, when that decision is in play 5. `DESIGN.md` — UI only If a spec lacks the detail you need, update the spec before writing code. ## Stack (do not substitute without an ADR) Next.js App Router · React · TypeScript strict · Better Auth · Prisma + PostgreSQL · Zod + React Hook Form · TanStack Query · Zustand (UI state only) · Tailwind + shadcn/ui · Vitest. Next.js in this repo may differ from your training data. Check `node_modules/next/dist/docs/` before using an API you are unsure about. ## Layers New behaviour **with** a domain rule (not every turn): `spec → domain tests → domain → services → actions → UI` - `src/domain/**`, `src/features/*/domain/**` — pure. No Next, React, Prisma or ambient clock. - `src/features/*/services/**` — the only place Prisma is called. - `src/features/*/actions/**` — `defineAction` / `defineWorkspaceAction` only. - `src/app/**` — thin routes: compose, do not compute. - `src/lib/env.ts` — the only reader of `process.env`. ## Hard rules - Business logic in `domain/`, never in a component, action or service. - Every business row carries `workspaceId`; every query filters by it. - Server Actions are public endpoints: authenticate and authorise inside them. - Semantic Tailwind tokens only; mobile-first. - Commit only when the user asks.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.