Stop repeating yourself. In this article we dive into how to set up TRAE Rules that remember your preferences, keep your team aligned, and avoid the common mistakes that make AI ignore your instructions.
How to Set Rules in TRAE:
-
Go to AI Management in the right panel
-
Go to Rules to create new
rules.md
Guide for Rules in TRAE
💡 We recommend writing custom rules in English, as this typically yields better results in most cases.
Scenario 1: Defining Personal Preferences
By configuring personal rules(user_rules.md), you can avoid repeatedly entering the same requirements. For example, if you want the model to follow programming best practices by default and generate clean, decoupled code instead of verbose implementations, setting up these rules will help the model produce code that better aligns with your coding habits and standards.
Common Use Cases:
Setting conversation language
Please always reply to me in English.Customizing TRAE personality
For example, defining a gentle programming partner who encourages you a lot:
You are my programming partner and encouraging companion.
Help me solve coding challenges while providing emotional support and motivation.
Please respond to my questions with a gentle, patient, and approachable tone—like a caring person would.
When appropriate, use friendly expressions and light humor to make programming more enjoyable and less tedious.
Please address me as "Dear Master" in our conversations.You can also turn therapists, comedians, celebrities or literary figures into your AI programming partners by customizing the Rules descriptions yourself.
Scenario 2: Defining Team Best Practices
If your team already has established best practices, you can copy them directly into project_rules.md. If not, you can try the following methods to generate them:
💡 Recommendation: Try not to change these rules too often once you've set them up, especially if you're working on a large team project. It's best to discuss any changes with your team first and make sure everyone's on board before updating the rules.
💡 Team Best Practices Conversion Tip: Upload your existing team documentation to TRAE's #docs collection, then reference that in the chat and tell the AI: "I want to convert this document into team best practices. Please help me consolidate and refine it." The AI will generate optimized rules based on the document content and requirements, which you can copy directly into project_rules.md.
Common Use Cases:
Generate Project Best Practices by Chatting with TRAE
Here's a prompt you can start with:
Please help me summarize the current project norms based on the current project content and write them into the project_rules.md.Our community has some additional best practices worth considering:
-
Have the model read through each important directory in your project first, then let it organize and create reasonable project rules on its own (like basic project structure, API development standards, file naming conventions, folder placement guidelines, etc.)
-
Build dedicated @Agent with custom prompts for each new requirement, and include links to relevant PRDs/Technical Documents in the prompts so the AI can access and read the requirements through tools like Notion MCP
-
Include specific template code for standards (like Unit Testing guidelines, API Integration standards) directly in the .md file, then add them to your contextual knowledge base for easy reference
Reference Standard Best Practices
Take a look at how successful open-source projects structure their rules and guidelines. You can learn a lot from how they describe their standards and adapt those approaches for your own project. Most projects cover similar areas like unit testing, documentation, naming conventions, project organization, code style, language preferences, and demo examples.
Example: Changelog Rules from antdesgin
Use Prompt Generation Tools
Try using the built-in prompt optimization tool in TRAE to write your rules.
Scenario 3: Rules + Custom Agents + MCP Integration
Custom Agents lets you write personalized prompts for each Agent. These prompts are only available to that specific Agent—they can't be shared between different agents.
If you want all agents to follow certain project standards or personal preferences, put them in project_rules.md or user_rules.md, like this:
Always chat in Spanish.
Add function-level comments when generating code.
My system is Mac.
Use pnpm instead of npm.An Example of user_rules.md
(Based on "Refactoring" by Martin Fowler)
# User Coding Standards & Refactoring Guide
## Basic Interaction Rules
1. Please respond to me in English
2. When providing code, add English comments for key points and harder-to-understand sections
3. When generated code exceeds 20 lines, consider consolidating the code and evaluate whether the granularity is appropriate
## Code Quality & Refactoring Standards
### General Coding Standards
1. Avoid unnecessary object copying or cloning
2. Avoid deep nesting; return early instead
3. Use appropriate concurrency control mechanisms
## Code Smell Identification & Treatment
Based on Martin Fowler's core insights in "Refactoring," here are code smells to watch for and how to handle them:
### 1. Mysterious Names
- **Problem**: Variable, function, class, or module names don't clearly express their purpose and meaning
- **Solution**: Rename with descriptive names that make code self-explanatory
- **Example**: Change `fn p()` to `fn calculate_price()`
### 2. Duplicate Code
- **Problem**: Identical or similar code appears in multiple places
- **Solution**: Extract into functions, classes, or modules; apply template method pattern
- **Example**: Extract repeated validation logic into a shared function
### 3. Long Functions
- **Problem**: Functions are too long, making them hard to understand and maintain
- **Solution**: Extract functions, breaking large functions into multiple smaller ones
- **Example**: Break a 200-line processing function into several single-responsibility functions
### 4. Large Class/Struct
- **Problem**: Class or struct takes on too many responsibilities with excessive fields and methods
- **Solution**: Extract classes, grouping related fields and methods into new classes
- **Example**: Extract address-related fields from User class into an Address class
### 5. Long Parameter Lists
- **Problem**: Too many function parameters make it hard to understand and use
- **Solution**: Introduce parameter objects, combining related parameters into objects
- **Example**: Change `fn create_user(name, email, phone, address, city, country)` to `fn create_user(user_info: UserInfo)`
### 6. Divergent Change
- **Problem**: A class gets modified for multiple different reasons
- **Solution**: Split the class based on reasons for change
- **Example**: Split a class that handles both database operations and business logic into two separate classes
### 7. Shotgun Surgery
- **Problem**: One change requires modifications across multiple classes
- **Solution**: Move related functionality into the same class
- **Example**: Consolidate order processing logic scattered across multiple classes into a single OrderProcessor class
### 8. Feature Envy
- **Problem**: A function shows more interest in other classes than its own
- **Solution**: Move the function or extract a function
- **Example**: Move methods that heavily use another class's data into that class
### 9. Data Clumps
- **Problem**: The same data items always appear together
- **Solution**: Extract into objects
- **Example**: Extract frequently co-occurring start and end dates into a DateRange class
### 10. Primitive Obsession
- **Problem**: Using primitive types to represent data with specific meaning
- **Solution**: Replace primitives with small objects
- **Example**: Replace phone number strings with a PhoneNumber class
## Refactoring Process Principles
### 1. Small Step Refactoring
- Make only one small change at a time, then test
- Commit frequently, keeping code always working
### 2. Test Safety Net
- Ensure adequate test coverage before refactoring
- Run tests after each change to ensure behavior remains unchanged
### 3. Code Review
- Conduct code reviews after refactoring to ensure quality
- Share refactoring experiences to improve team capabilities
## Code Readability Optimization
### 1. Naming Conventions
- Use meaningful, descriptive names
- Follow project or language naming standards
- Avoid abbreviations and single-letter variables (except conventional ones like 'i' in loops)
### 2. Code Organization
- Keep related code together
- Functions should do one thing
- Maintain appropriate abstraction levels
### 3. Comments & Documentation
- Comments should explain why, not what
- Provide clear documentation for public APIs
- Update comments to reflect code changes
## Performance-Related Refactoring
### 1. Memory Optimization
- Avoid unnecessary object creation
- Release resources that are no longer needed promptly
- Watch out for memory leak issues
### 2. Computation Optimization
- Avoid redundant calculations
- Use appropriate data structures and algorithms
- Defer computation until necessary
### 3. Parallelization Optimization
- Identify tasks that can be parallelized
- Avoid unnecessary synchronization
- Pay attention to thread safety issuesFAQ
1. What's the maximum character limit for rules?
Rules support up to 20,000 bytes maximum.
2. Why do rules sometimes not get followed?
#1: The concept described in the rules isn't clear to the AI
Bad Case ❌
Comments should be in EnglishAnalysis: The user wants the AI to write all code comments in English, but the model doesn't understand what "Comments" means in this context, so the generated code comments don't match what the user expected.
Good Case ✅
All the code comments you generate should be in English.Note: Be clear about what you want.
#2: File paths aren't relative to the project root
Bad Case ❌
Please help me form the code by referring to "templates.md".Analysis: "templates.md" is only a filename, not a relative path from the project root directory. This causes the AI agent to search for the wrong file and return either a 404 error or incorrect content.
Good Case ✅
Please help me form the code by referring to "src/.TRAE/rules/templates.md".Note: Specify the complete file path
#3: Rule conflicts and overrides
Rule priority order: User input > Custom Agent prompts > user_rules.md > project_rules.md
When these rules conflict with each other, the model can get confused about which ones to follow.
#4: Rules can't understand the functionality concepts in your sidebar
Bad Case ❌
Help me generate the code format that can be applied to Code Apply.Analysis: The user wants the MCP output format to directly work with Code Apply, but the model doesn't understand what "Code Apply" means.
Good Case ✅
Please help me generate a code result similar to this one.
```cpp:absolute/path/to/file
// ... existing code ...
{{ code1 }}
// ... existing code ...
{{ code2 }}
// ... existing code ...
```Note: The model can't understand AI Sidechat concepts like the Diff, Apply, Reject, Accept, and Run Command buttons.
#5: Chat history conflicts with Rules
The best way to resolve this is to start a new conversation.
#6: Why isn't the generated code following my rules?
When your project already contains a lot of non-standard code, the model might follow the existing code style instead of your rules.
Here's what you can do:
-
Explicitly tell the model you're refactoring the code
-
Emphasize that it should follow the new rules for specific tasks
-
Consider starting a dedicated refactoring project to improve code quality step by step
Writing custom rules is essentially writing prompts. We hope this guide can be helpful for you.