Kilo Code and Trae AI: Their Rules File Conventions Explained (2026)

Kilo Code and Trae AI are two of the less-documented entrants in the AI coding agent space — Kilo (the open-source agent formerly branded “Kilo Code”) and Trae AI (ByteDance’s AI-native code editor) both ship their own rules-file conventions, and neither gets much coverage next to Cursor, Claude Code, or Windsurf. This guide verifies both conventions directly against official documentation: exact file paths, config syntax, activation modes, and how each tool relates to the emerging AGENTS.md standard.

Kilo uses a .kilo/rules/ directory wired through a kilo.jsonc config file, while Trae AI uses a .trae/rules/ directory with per-rule “Application Modes” set via a UI — and both tools also read AGENTS.md natively, on top of their own formats.

Quick Answer

Kilo (Formerly “Kilo Code”): the .kilo/rules/ Convention

First, a naming note that matters for anyone searching: Kilo Code rebranded to “Kilo” sometime before mid-2026. The old domain kilocode.ai now 308-redirects every docs URL to kilo.ai, and the docs consistently refer to the product as “Kilo.” The GitHub organization and repo are still named Kilo-Org/kilocode, which is why searches for “Kilo Code rules” and “Kilo rules” turn up the same project under two names.

File location and kilo.jsonc

Kilo supports two rule types: Project Rules (scoped to the current workspace) and Global Rules (applied across every project). Both are wired through the same mechanism — a JSONC config file (JSON with // comments) and an instructions array that points to files or glob patterns.

Project rules live in a kilo.jsonc file at the project root:

// kilo.jsonc
{
  "instructions": [".kilo/rules/formatting.md", ".kilo/rules/*.md"]
}

The referenced files are plain Markdown, conventionally stored in .kilo/rules/:

project/
├── .kilo/
│   └── rules/
│       ├── formatting.md
│       ├── restricted_files.md
│       └── naming_conventions.md
├── kilo.jsonc
├── src/
└── ...

Global rules use the identical instructions key, but in a config file outside the project: ~/.config/kilo/kilo.jsonc.

Loading order and precedence

Per the official docs, Kilo loads rules in this order:

1. Global instructions from ~/.config/kilo/kilo.jsonc
2. Project instructions from the project’s kilo.jsonc

Files matched by a glob pattern load in filesystem order, and project-level instructions take precedence over global instructions when directives conflict.

Disabling a rule without deleting it

Because kilo.jsonc supports // comments, you can toggle a rule off without removing the file:

// kilo.jsonc
{
  "instructions": [
    ".kilo/rules/formatting.md",
    // ".kilo/rules/experimental.md" -- temporarily disabled
    ".kilo/rules/naming_conventions.md"
  ]
}

Backward compatibility with .kilocode/rules/

If your project already has a .kilocode/rules/ directory from before the rebrand, Kilo auto-includes its contents for backward compatibility — no kilo.jsonc entry required. The docs recommend migrating to the kilo.jsonc + .kilo/rules/ pattern going forward, but existing .kilocode/rules/ setups keep working unmodified.

Memory Bank is deprecated — AGENTS.md is the replacement

Kilo previously shipped a “Memory Bank” feature that persisted project context in .kilocode/rules/memory-bank/. As of the current docs, Memory Bank is deprecated in favor of AGENTS.md. Existing memory-bank rules continue to work, but the migration path is explicit: read the contents of .kilocode/rules/memory-bank/, then move that content into your project’s AGENTS.md (or ask Kilo to do it for you). This makes Kilo one of the tools where AGENTS.md isn’t just supported — it’s the officially recommended replacement for a previously proprietary format.

Format and troubleshooting

Rules can be plain text, but Markdown is recommended — headers to group rules, lists for discrete constraints, code blocks for examples. If a rule isn’t being followed, Kilo’s own troubleshooting steps are: confirm the file path in instructions is correct, verify the file is valid Markdown, and start a new chat session (config changes apply on the next interaction, not mid-session).

Trae AI: the .trae/rules/ Convention

Trae AI, ByteDance’s AI-native code editor, uses a directory-based convention similar in spirit to Cursor’s .cursor/rules/, but with its own activation model.

Two rule types: User Rules and Project Rules

Trae distinguishes User Rules (global, personal preferences, applied in every project you open) from Project Rules (created inside a specific project, only effective there). User Rules are managed entirely through the Settings UI — enter the rule text in a rule input box and click Save — rather than as a file you can inspect directly. Project Rules, by contrast, are real files: creating one through the UI has Trae “automatically create a .trae/rules folder in the project’s directory” and open the new .md file for editing.

Frontmatter fields and the four Application Modes

Every project rule carries three properties — alwaysApply, description, and globs — but you rarely set them by hand. Instead, you pick an Application Mode in the UI and Trae writes the corresponding frontmatter automatically:

Manually-scoped rules are pulled into a conversation with #Rule in the chat input — and per the docs, #Rule has the highest priority among all referencing methods, overriding whatever automatic matching an “Apply to Specific Files” or “Apply Intelligently” rule would otherwise use.

Nested and module-scoped rules

Beyond the root .trae/rules/ directory, Trae reads a .trae/rules/ folder placed in any subdirectory of the project, with recursive subfolder support up to three levels of nesting. This is aimed squarely at monorepos: instead of dumping every rule into the project root (where a frontend rule can leak into backend context), you scope rules to the module they apply to:

.trae/rules/
├── general-rules.md          # General rules
├── frontend/
│   ├── react-conventions.md
│   └── styling.md
└── backend/
    └── api-conventions.md

The docs are explicit about the reasoning: keeping module-specific rules in the project root “is not only difficult to maintain but may also cause exclusive rules for one module to interfere with other modules.”

Git commit message rules

Trae has a dedicated path for AI-generated commit messages. There are two ways to set them: add commit-message instructions to an existing rule file, or let Trae auto-generate a git-commit-message.md file inside .trae/rules/. That file supports a scene: git_message frontmatter field, which the docs note “is compatible with existing fields such as alwaysApply, description, and globs” — so a commit-message rule can also be scoped by Application Mode like any other rule.

AGENTS.md, CLAUDE.md, and CLAUDE.local.md — natively, at the module level too

This is the most notable finding in Trae’s docs: Trae reads AGENTS.md, CLAUDE.md, and CLAUDE.local.md directly, on top of its own .trae/rules/ system. The docs describe AGENTS.md as “a lightweight markdown file located in the project’s root directory, used to provide behavioral guidance to AI agents,” and are explicit about portability: “An AGENTS.md file created in TRAE can be reused in other IDEs that support AGENTS.md, and vice versa.”

Trae goes further than most AGENTS.md-supporting tools by extending it to subdirectories with the same module-scoping logic as .trae/rules/:

project/
└── frontend-module/
    └── AGENTS.md    # Takes effect only when files related to
                      # frontend-module are read or mentioned

One catch: this support isn’t on by default. In Settings → Import Settings, you have to toggle “Include AGENTS.md in the context” and “Include CLAUDE.md in context” separately — if a teammate says Trae is “ignoring” their AGENTS.md, this toggle is the first thing to check.

Kilo vs Trae vs AGENTS.md: Full Comparison

Setting Up Your First Rule

Kilo:

1. Create kilo.jsonc in your project root if it doesn’t exist.
2. Create a .kilo/rules/ directory (or any directory name you prefer).
3. Write a Markdown rule file, e.g. .kilo/rules/style.md.
4. Add the path to the instructions array in kilo.jsonc.
5. Start a new chat session — rules apply on the next interaction, not retroactively.

Trae AI:

1. Open Settings → Rules.
2. Click “Create Project Rule,” name it — Trae creates .trae/rules/<name>.md and opens it.
3. Write the rule body in Markdown.
4. Set the Application Mode (Always Apply / Apply to Specific Files / Apply Intelligently / Apply Manually).
5. For module-scoped rules, create .trae/rules/ inside the relevant subdirectory instead of the root.

FAQ

Does Kilo Code still exist, or has it been replaced by “Kilo”?

Same project, new name. Kilo Code rebranded to “Kilo” — the old kilocode.ai domain now redirects to kilo.ai, and current docs refer to the product as Kilo throughout. The GitHub repository is still Kilo-Org/kilocode, so both names point to the same tool.

Where do Kilo’s project rules live, and how do I activate them?

In a .kilo/rules/ directory as Markdown files, referenced by path or glob pattern in the instructions array of a kilo.jsonc config file at the project root. Rules aren’t picked up automatically from the directory alone — they need an entry in kilo.jsonc (unless they’re in the legacy .kilocode/rules/ path, which is auto-included for backward compatibility).

Does Kilo support AGENTS.md?

Yes, and it’s the recommended path forward: Kilo’s older “Memory Bank” feature (which stored context in .kilocode/rules/memory-bank/) is deprecated in favor of AGENTS.md. The official migration guidance is to move memory-bank content into your project’s AGENTS.md file.

What are Trae AI’s four “Application Modes” for rules?

Always Apply (loads in every chat), Apply to Specific Files (matches a glob/File Pattern), Apply Intelligently (the agent judges relevance from the rule’s description), and Apply Manually (only loads when you reference it with #Rule in chat). Each mode maps to a specific combination of the alwaysApply, description, and globs frontmatter fields.

Can Trae AI scope rules to a specific module in a monorepo?

Yes. Trae reads a .trae/rules/ folder in any subdirectory of the project, not just the root, with recursive nesting up to three levels. AGENTS.md gets the same treatment — a module-level AGENTS.md (e.g. frontend-module/AGENTS.md) only takes effect when files related to that module are read or mentioned.

Why isn’t Trae AI reading my AGENTS.md or CLAUDE.md file?

Check Settings → Import Settings for the “Include AGENTS.md in the context” and “Include CLAUDE.md in context” toggles. Trae supports both formats natively, but they’re opt-in switches, not enabled by default.

Do Kilo and Trae’s own rule formats work in other AI coding tools?

No — .kilo/rules/ and .trae/rules/ are proprietary to their respective tools. If portability across tools matters, put your shared instructions in AGENTS.md, which both Kilo and Trae read natively alongside their own formats, and use the tool-specific directories only for behavior you want scoped to that one editor.

Secrets Management for New AI Coding Tools

Every AI coding agent you add — Kilo, Trae, or the next one — is another surface that can read your .env files, API keys, and database credentials if a rule file doesn’t explicitly fence them off (see the “Restricted Files” pattern in Kilo’s own docs above). Store secrets in a proper vault instead of plaintext config, and share access across your team without pasting keys into Slack.

Try 1Password for secure secrets management →

Related Articles

• AGENTS.md vs CLAUDE.md vs .cursor/rules: Three-Way Comparison
• AGENTS.md vs CLAUDE.md vs GEMINI.md: The Complete 2026 Comparison
• Kiro Steering vs AGENTS.md vs CLAUDE.md (2026)
• .cursorrules vs .mdc Format Guide (2026)
• AGENTS.md × Windsurf Setup Guide (2026)
• Browse 165+ Real AI Coding Rules

External References

• Kilo Custom Rules documentation
• Kilo Memory Bank documentation
• Kilo Custom Modes / Agents documentation
• Kilo-Org/kilocode on GitHub
• Trae AI Rules documentation