Creating Trae Rules

Creating Trae Rules

Use this Skill to produce rules that are valid for Trae IDE and easy for Trae to apply. Prefer creating or editing actual rule files when the target project path is known.

When the user writes in Chinese, discuss choices and final summaries in Simplified Chinese. Keep file names, frontmatter keys, glob patterns, and code identifiers in their original form.

Do Not Use

Do not use this Skill when:

• The user wants general project documentation, prompt writing, or one-off notes that are not intended to become Trae rules.
• The task is ordinary code editing, debugging, or refactoring unrelated to .trae/rules, AGENTS.md, CLAUDE.md, or git message rules.
• The user is asking for broad workflow advice without asking to create, modify, organize, or review actual rule files.
• The request is about editing Skills instead of rules; use the Skill workflow for SKILL.md and related Skill assets.

Inputs

Collect or infer:

• Target scope: whole project, specific module, specific file pattern, intelligent trigger, manual trigger, personal rule draft, or commit message generation.
• Target project or module path. If omitted, inspect the current workspace before asking.
• Rule purpose and constraints.
• Desired activation mode.
• Existing rule files that may conflict or overlap.

Ask one concise question only when the target path or rule purpose is impossible to infer safely.

Workflow

1. Inspect existing Trae rule surfaces before editing:
   • Project rules: <project>/.trae/rules/**/*.md
   • Module rules: <module>/.trae/rules/**/*.md
   • Agent files: AGENTS.md, CLAUDE.md, CLAUDE.local.md
   • Commit message rules: rules containing scene: git_message
2. Choose the smallest correct rule surface:
   • Use .trae/rules/<name>.md for project rules.
   • Use <module>/.trae/rules/<name>.md for module-only behavior.
   • Use AGENTS.md only when the user wants a lightweight project instruction file that can be reused by tools supporting AGENTS.md.
   • Draft personal rules as plain text for Trae settings; do not invent a filesystem location for personal rules.
3. Choose activation mode:
   • Always apply: set alwaysApply: true.
   • Specific files: set alwaysApply: false and globs.
   • Intelligent apply: set alwaysApply: false and description.
   • Manual only: set alwaysApply: false and omit globs and description unless the user explicitly wants metadata for clarity.
   • Commit message: add scene: git_message; this can coexist with alwaysApply, description, and globs.
4. Write the rule with YAML frontmatter followed by Markdown instructions.
5. Keep each rule focused. Split rules when one file mixes unrelated concerns such as UI style, API design, testing, and commit messages. When a file exceeds the line limit (50 for rules, 30 for alwaysApply), apply the Line Limit Decision Strategy from resources/trae-rules-reference.md: identify whether it contains multiple independent concerns (split) or a single coherent concern (keep). Never delete actionable content just to meet a line count.
6. Validate:
   • Frontmatter is bounded by ---.
   • Boolean fields are real booleans, not quoted strings.
   • globs uses project-root-relative patterns.
   • Rule files are no deeper than three nested levels under .trae/rules/.
   • No new rule contradicts an existing rule.
7. Summarize changed files, activation behavior, and any assumptions.

Rule Templates

Use templates only when helpful:

• templates/always-apply.md: whole-project rule.
• templates/specific-files.md: file-pattern rule.
• templates/intelligent-apply.md: semantic trigger rule.
• templates/manual-only.md: #Rule-only rule.
• templates/git-message.md: commit message generation rule.

For exact Trae behavior and examples, read resources/trae-rules-reference.md when creating or reviewing non-trivial rules.

Writing Rules

Use this structure:

---
alwaysApply: false
description: [触发此规则的简短场景描述]
---

# [规则名称]

- [执行这个具体操作]
- [避免这种具体错误模式]
- [在这个场景下，优先使用此本地约定]

Write instructions as actionable constraints, not explanations about why the rule exists. Prefer bullets that Trae can follow during execution.

Good rule content:

- Use the existing repository test helper instead of introducing a new test runner.
- Keep generated files out of source changes unless the user explicitly asks for regenerated artifacts.
- When editing React components, follow the nearby component naming and import order.

Avoid vague content:

- Make the code better.
- Follow best practices.
- Be careful.

File Placement

Use forward slashes in examples and globs.

Examples:

.trae/rules/general-style.md
.trae/rules/frontend/react-components.md
frontend-module/.trae/rules/react-best-practices.md
backend-module/.trae/rules/api-design.md
AGENTS.md

Do not create rules below the fourth nested level under .trae/rules/; Trae recognizes up to three levels of nesting.

Failure Handling

• Missing target project: inspect the current directory. If no project root is clear, ask for the target folder.
• Existing conflicting rule: report the conflict and either update the existing rule or ask before creating a competing one.
• Personal rule request: provide the rule text and tell the user it belongs in Trae settings, not .trae/rules.
• Unknown activation mode: choose intelligent apply for scenario-specific guidance, specific-files for file-pattern guidance, always apply only for truly universal constraints, and manual only for rarely needed specialist guidance.
• Commit message rule already exists: update the existing scene: git_message rule instead of creating a duplicate unless the user asks for multiple commit rules.

Output Contract

## 规则创建/更新结果

**文件路径:** `.trae/rules/...`

**规则意图:**
- [简述规则的核心目的]

**覆盖范围:**
- [受影响的文件或场景]

**下一步:** [如无则写 "- 无"]