rules

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.

what are rules?

Rules tell the agent how you want to work:

  • Coding standards and style preferences
  • Project-specific patterns to follow
  • Technologies and libraries to use
  • What to avoid or exclude

Rules persist across conversations, so you don't need to repeat yourself.

when to use rules

start simple

Don't create rules upfront. Work with the agent first, and add rules when you notice patterns:

Add a rule when:

  • The agent makes the same mistake repeatedly
  • You find yourself giving the same instruction in multiple conversations
  • There's a project convention the agent should always follow

Don't add a rule for:

  • One-off requirements
  • Things that vary by task
  • Preferences that might change

example scenario

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.

types of rules

project rules

Shared with your team, version-controlled in your repository.

Use for:

  • Code style standards
  • Architectural patterns
  • Technology choices
  • Testing requirements

Project rules ensure everyone (human and AI) follows the same conventions.

personal rules

Just for you, not shared with the team.

Use for:

  • Your preferred explanation style
  • Workflow preferences
  • Keyboard shortcuts you want mentioned
  • Personal coding habits

creating effective rules

be specific

❌ Vague: "write good code" ✅ Specific: "Use async/await syntax instead of Promise chains. Always include error handling with try/catch blocks."

keep them focused

Each rule should address one clear concern.

Instead of a giant style guide, create separate rules for:

  • Error handling
  • API call patterns
  • Component structure
  • Testing approach

reference, don't copy

❌ 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.

make them actionable

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"

rule examples

error handling

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)

api patterns

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

testing

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

documentation

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

managing rules

start with one

Create a single rule for your most common pain point. See how it works before adding more.

review and refine

Rules should evolve:

  • Remove rules that are no longer relevant
  • Update rules when patterns change
  • Split rules that try to do too much

avoid rule overload

Too many rules can confuse the agent about priorities. Aim for 5-10 clear rules rather than 50 vague ones.

how rules work

When you send a message, the agent sees:

  1. Your project's rules (if any)
  2. Your personal rules (if any)
  3. Your actual message

Rules provide context, but your message takes priority. You can override a rule in any specific conversation.

best practices

Do:

  • Start simple, add rules when patterns emerge
  • Be specific and actionable
  • Reference examples in your codebase
  • Keep rules focused on one concern
  • Review and update rules periodically

Don't:

  • Create rules before you need them
  • Copy/paste entire documentation into rules
  • Write vague or ambiguous rules
  • Let rules accumulate without reviewing them

related pages