Rules are persistent instructions that guide the agent's behavior across conversations. Instead of repeating preferences every time, you encode them once and the agent follows them automatically.
Rules tell the agent how you want to work:
Rules persist across conversations, so you don't need to repeat yourself.
Don't create rules upfront. Work with the agent first, and add rules when you notice patterns:
Add a rule when:
Don't add a rule for:
You notice the agent often uses console.log for errors, but your project uses a custom logger.
Without a rule: You have to say "use our errorLogger utility instead of console.log" in every conversation.
With a rule: You create a rule once, and the agent automatically uses the error logger.
Shared with your team, version-controlled in your repository.
Use for:
Project rules ensure everyone (human and AI) follows the same conventions.
Just for you, not shared with the team.
Use for:
ā Vague: "write good code" ā Specific: "Use async/await syntax instead of Promise chains. Always include error handling with try/catch blocks."
Each rule should address one clear concern.
Instead of a giant style guide, create separate rules for:
ā Copying: paste your entire style guide into a rule ā Referencing: "Follow the error handling patterns in src/utils/errors.ts"
The agent can read files, so point it to examples rather than duplicating content.
Rules should describe what to do, not just what to avoid.
ā "Don't write messy code" ā "Organize components with hooks at the top, event handlers in the middle, and the return statement at the end"
when adding error handling:
- use try/catch for async operations
- import and use our errorLogger from src/utils/logger.ts
- never use console.log or console.error for production errors
- include context in error messages (user id, operation name)
for api calls:
- use the apiClient from src/lib/api.ts
- all endpoints should return { success: boolean, data?: any, error?: string }
- implement retry logic for network failures (up to 3 attempts)
- add loading and error states to components that make api calls
when writing tests:
- place test files adjacent to the code they test (Component.test.tsx next to Component.tsx)
- use descriptive test names: "it should reject invalid email formats"
- test both happy path and error cases
- prefer integration tests over unit tests for components
for new functions:
- add a brief comment above explaining the purpose
- document parameters and return types in typescript
- skip comments for obvious operations (getters, setters)
- link to related functions or documentation when relevant
Create a single rule for your most common pain point. See how it works before adding more.
Rules should evolve:
Too many rules can confuse the agent about priorities. Aim for 5-10 clear rules rather than 50 vague ones.
When you send a message, the agent sees:
Rules provide context, but your message takes priority. You can override a rule in any specific conversation.
Do:
Don't: