AI coding tools are only as good as the context you give them. Without guardrails, they'll happily invent APIs, ignore your folder structure, or introduce patterns that don't fit your project. The fix? Custom rules files. These are plain-text instructions your AI assistant reads before writing code, giving it project-specific knowledge instantly.
In this tutorial, you'll create a rules file for your existing project and see a measurable improvement in generated code quality. We'll cover universal patterns that work across Cursor, GitHub Copilot, and similar tools.
Step 1: Find where your tool reads rules
Different tools have different conventions, but most support a project-level .cursor/rules directory (Cursor) or an AGENTS.md file (popularized by codeium/continue). If you're unsure, check your tool's docs or look for existing rules in your repo. For this tutorial, we'll use the .cursor/rules/ directory, which supports scoped rule files with glob patterns.
If you don't see this directory, create it manually. It won't break anything—your tool will simply start picking up the rules.
Step 2: Write a global rules file
Start with a 00-global.mdc (or GLOBAL.md in an AGENTS.md setup). This file applies to every conversation. Keep it general—kind of like a contractor onboarding document.
# Global Rules
- Always import React from 'react'
- Use TypeScript strict mode
- Prefer named exports over default exports
- Never use `any` unless absolutely necessary
- Follow existing code style: 2 spaces, single quotes, semicolons
- Check if a component already exists before creating a new one
- Only add comments for complex logic, not obvious code
These are the repeating instructions that fix your top 5 code review complaints.
Step 3: Add scoped rules with glob patterns
The real power comes from scoping. Create a file like components.mdc and set a glob pattern so the rules only apply when working in src/components. In Cursor, use the glob property in the frontmatter:
---
glob: src/components/**/*.{tsx,ts}
---
# Component Rules
- Components must be functional, not class-based
- Use `useState` and `useEffect` for hooks
- Do not use `localhost` in API calls
- If data fetching is needed, use the existing `api/client.ts` helper
- All props must be typed with an interface
- Export only the component, not the helper functions
Now when you ask Cursor to edit src/components/Button.tsx, it automatically knows to use the project's API client and prop typing style.
Don't overload scoped rules with too many instructions. The more you add, the more likely the AI will ignore or hallucinate them. Stick to 5–10 high-impact rules per scope.
Step 4: Test and iterate with a real task
Now, ask your AI assistant to implement a small feature—like a modal component that fetches data from your API. Observe the output:
With rules, you should see the AI correctly reuse your API client, follow your hook pattern, and avoid hardcoding URLs. Without rules, it often creates a parallel fetch logic and inconsistency.
Keep a log of mistakes the AI makes even with rules. For each one, add a new line to the relevant rule file. For example:
# Add this after seeing the AI use a fetch instead of your client
- Always use `api-client.ts` for any HTTP request—never use bare fetch or axios
A month of disciplined updates will give you a rule system that encodes your team's entire coding style.
Pro tips for maximum impact
- Put the most important rules at the top—AI pays more attention to earlier lines.
- Use a
template.mdcto scaffold new files (e.g., new components must have a test file). - Pair rules with your project's
README.mdandtsconfig.json—rules can reference them. - Buy-in: share the rules file with your team and review it like code (it is code).
Remember, rules files are a fallback, not a replacement for good code review. They reduce the noise so your review time is spent on real problems.
That's it—you've just built a custom context layer for your AI assistant. In less than 15 minutes, you've made every future code generation more aligned with your project's architecture. Start with three rules today, then grow them as you learn.
The scoping bit is key—I've seen rules leak all over the codebase. Do you split rules per folder or keep one global file with conditions?