AI coding agents are only as good as the context you give them. Without explicit guidance, they'll guess your conventions, write tests inconsistently, and violate architectural boundaries. Custom rules files are the most direct way to take control. Here's a workflow to create rules that actually stick.

1. Audit Your Codebase for Patterns

Before writing a single rule, look at your repository and list the non-negotiable patterns you want the agent to follow. Common candidates:

  • Naming conventions (e.g., React components in PascalCase, test files in *.test.ts)
  • State management approach (do not use Redux; use React Query)
  • API call patterns (always use the shared http client)
  • Testing requirements (every bug fix must include a regression test)

Tip: Start with the top 5 patterns that cause the most rework when the AI gets them wrong. You can always add more later.

2. Write Rules in the Tool's Native Format

Different AI coding tools look for rules in different places:

  • Cursor: .cursor/rules/*.mdc
  • GitHub Copilot: .github/copilot-instructions.md
  • Continue: .continue/rules.json or AGENTS.md

Whichever tool you use, keep the syntax simple and imperative. Here's an example for a Next.js project:

# Project Rules

## Naming
- React components must be in PascalCase, e.g. `UserCard.tsx`.
- Hooks must be in camelCase and start with `use`, e.g. `useAuth.ts`.
- Test files must be named `*.test.ts` or `*.test.tsx` and colocated.

## Architecture
- Do not use Redux. Use React Query for server state and Context for client state.
- All API calls must go through `src/lib/http.ts` – never use `fetch` directly.
- API routes must validate input with Zod before touching any data.

## Testing
- Every newly added feature must include a unit test.
- Every bug fix must include a regression test that fails before the fix.

## Style
- Use single quotes for strings, no semicolons.
- Use Tailwind classes only; do not add custom CSS files.

Warning: Avoid vague rules like "write good code." They give the agent no actionable constraints. Be as specific as you'd be with a new developer on your team.

3. Store Rules in Version Control

Once you've written the rules, commit them to your repository. This ensures every developer and every AI session uses the same conventions. Use a file name that matches your tool's discovery pattern. For Cursor, each rule lives in its own .mdc file with a frontmatter that includes glob patterns to target specific files:

---
description: "React component conventions"
globs: "src/**/*.tsx"
---
Always use function components.
Use TypeScript strict mode.
Do not use `any`.

This way, the rules are automatically loaded when the agent touches a matching file, without you having to mention them in every prompt.

4. Test Your Rules with a Real Task

Now pick a small, representative task and give it to the AI agent. Ask it to add a new UI component that fetches data from an API. After it finishes, review the output against your rules. Did it use the shared HTTP client? Did it add a test? If not, adjust the rules to be even more explicit.

Success: A rules file is working well when you can say "implement this feature" and the code comes back matching your conventions without further prompts. Iterate until that's true.

5. Keep Rules Lean and Reviewed

Rules files are code. Treat them with the same care. Limit yourself to 20–30 actionable rules max – too many and the agent will start ignoring them. Schedule a quarterly review to remove stale rules and add new ones based on recent mistakes your team has seen.

Bottom line: Custom rules files are your most underused lever for AI code quality. Start with a single file that captures your top five conventions, wire it into your tool, and test it on the next task. You'll be surprised how quickly the output starts looking like a human on your team wrote it.