Write a Project Rules File
You get a concise, ready-to-save rules file that tells an AI coding assistant how your project works. Short, testable rules are easier for the assistant to follow than long, vague guidance.
Partly workedIt met the format and the 25-rule cap, and it put money and dates first. But it skipped step 5. It kept a duplicate pair (the Prisma-in-server rule and the never-import-Prisma rule) and several rules the details don't back (named exports, `Pence`/`At` naming, no CSS files, strict typing, DST edge cases). The named-exports rule's exception wording is also garbled.
The prompt
You are a senior software engineer who writes clear, practical instructions for AI coding assistants.
Task: Turn the project details below into a short rules file that keeps an assistant's code consistent with our standards.
Project: {project_description}
Tech stack: {tech_stack}
Team habits: {team_conventions}
Steps:
1. Read the details and list the decisions an assistant would otherwise guess, such as naming, file structure, testing and error handling.
2. Write each decision as a short, testable rule in the imperative, for example "Use named exports only".
3. Group the rules under clear headings and put the rules most often broken first.
4. Add a "Never do" section covering risky actions specific to this stack.
5. Delete any rule that is vague, duplicated or not backed by the details given.
Output: One Markdown file with headings and bullet points, no more than 25 rules in total. Finish with a single line listing any assumptions you made.
Change the parts in curly braces. Use it when you start a new codebase, or when an AI coding assistant keeps ignoring your team's conventions.
What happened when we ran it
We sent
You are a senior software engineer who writes clear, practical instructions for AI coding assistants. Task: Turn the project details below into a short rules file that keeps an assistant's code consistent with our standards. Project: A booking app for independent hair salons. Customers pick a stylist and a time slot, pay a deposit, and get a confirmation email. Salon owners manage their calendar and staff rota from a dashboard. We have about 40 paying salons and a team of three developers. Tech stack: TypeScript, Next.js 14 with the app router, PostgreSQL via Prisma, Stripe for payments, Tailwind CSS, Vitest for unit tests, deployed on Vercel. Team habits: We use functional components only and keep files under 200 lines. Database access happens only in the server folder, never in components. Every new feature needs a Vitest test and a short note in the changelog. Money is always stored as integer pence, and dates are stored in UTC. Steps: 1. Read the details and list the decisions an assistant would otherwise guess, such as naming, file structure, testing and error handling. 2. Write each decision as a short, testable rule in the imperative, for example "Use named exports only". 3. Group the rules under clear headings and put the rules most often broken first. 4. Add a "Never do" section covering risky actions specific to this stack. 5. Delete any rule that is vague, duplicated or not backed by the details given. Output: One Markdown file with headings and bullet points, no more than 25 rules in total. Finish with a single line listing any assumptions you made.
The model replied
```markdown
# AGENTS.md — Salon Booking App
## Data and Money (most often broken)
- Store all money as integer pence; never use floats or decimal strings for amounts.
- Convert pence to a display string (e.g. £12.50) only at the UI edge, using one shared formatter.
- Store and transmit all dates in UTC; convert to the salon's local time only when rendering.
- Name money fields with a `Pence` suffix (e.g. `depositPence`) and date fields with an `At` suffix (e.g. `startsAt`).
## Architecture
- Put all database access (Prisma calls) in the `server/` folder only.
- Never import Prisma or `server/` db modules into components or client code.
- Use the App Router (`app/`) only; do not add `pages/` routes.
- Use functional components only; do not write class components.
- Keep every file under 200 lines; split into smaller modules when approaching the limit.
- Mark a component `"use client"` only when it needs state, effects or browser APIs.
## Testing and Changelog
- Add a Vitest test for every new feature, placed next to the code as `*.test.ts(x)`.
- Add a short changelog entry for every new feature in the same change.
- Test money and date logic with at least one edge case (e.g. zero pence, a DST boundary).
- Mock Stripe and email in unit tests; never call live services.
## Code Style
- Write TypeScript with `strict` typing; do not use `any` (use `unknown` and narrow).
- Use named exports only, except for files that Next.js requires a default export for (`page`, `layout`, `route` handlers excepted).
- Style with Tailwind utility classes; do not add CSS files or inline styles.
## Error Handling
- Validate all external input (forms, API bodies, webhooks) with a schema before use.
- Return typed errors from server functions; do not swallow exceptions with empty `catch` blocks.
- Show users a plain-language error message; never expose stack traces or raw database errors.
## Never Do
- Never hard-code or commit secrets, Stripe keys or database URLs; read them from environment variables.
- Never trust the client for prices or deposit amounts; calculate them on the server.
- Never process a Stripe webhook without verifying its signature.
- Never edit an existing Prisma migration; create a new one for every schema change.
- Never run `prisma migrate reset` or `db push --force-reset` against a shared or production database.
*Assumptions: Validation uses a schema library such as Zod, tests sit beside source files, the server folder is `server/` at the project root, and the changelog is a `CHANGELOG.md` file.*
```
Run on Claude Sonnet 5.5, 01 Nov 2026. Automatic check: 3 out of 5.
Mentioned for
Cursor, GitHub Copilot, Windsurf, Cline, Zed
Where it came from
Found on GitHub, shared by instructa: instructa/ai-prompts.
This is our own version of the idea, written and tested by us. The original may differ.