Feature Request: Three-tier Rules System for Development Guidelines

What feature would you like to see?

Summary

I propose implementing a three-tier Rules system for Kimi Code CLI that allows users to define and manage development guidelines across global, user, and project levels. This feature would bring Kimi closer to feature parity with Claude Code's .claude/CLAUDE.md system while adding more flexibility.

Motivation

Currently, Kimi Code CLI supports AGENTS.md for project-specific context, but lacks a dedicated system for managing development rules (coding standards, testing guidelines, security practices, etc.) that can:

1. Be shared across projects (global/user-level rules)
2. Be overridden at the project level when needed
3. Be easily toggled on/off without modifying files

As a developer working with multiple projects, I often find myself:

• Repeating the same coding style requests in different projects
• Forgetting to mention specific testing requirements
• Wanting to temporarily disable certain guidelines without deleting them

Reference: Prior Art

Claude Code's Approach

Claude Code supports ~/.claude/CLAUDE.md for global rules and .claude/CLAUDE.md for project-level rules. This is widely used by developers to maintain consistent coding standards.

Cursor's Approach

Cursor uses .cursor/rules/ directory with multiple rule files categorized by language or domain.

Proposed Design

Three-tier Hierarchy

Priority (high → low):

1. Project Rules (.agents/rules/ or .kimi/rules/)
2. User Rules (~/.config/agents/rules/)
3. Built-in Rules (distributed with CLI)

File Structure

~/.config/agents/rules/ # User-level rules
├── common/
│ ├── coding-style.md
│ └── testing.md
└── python/
└── coding-style.md

/.agents/rules/ # Project-level rules
├── backend-api.md
└── frontend-guidelines.md

Rule Format (YAML Frontmatter)

---
name: "Python Coding Style"
description: "Python-specific coding conventions"
paths: ["**/*.py", "**/*.pyi"]  # Auto-apply to matching files
priority: 100                   # Lower = higher priority
---
# Rule content in Markdown
- Follow PEP 8 conventions
- Use type annotations on all function signatures

### CLI Commands

/rules list         # List enabled rules
/rules list --all   # Show all rules (including disabled)
/rules show <id>    # View rule content
/rules on <id>      # Enable a rule
/rules off <id>     # Disable a rule
/rules reset        # Reset to defaults

Configuration

# ~/.kimi/config.toml
[rules]
enabled = true
auto_enable_by_path = true   # Auto-enable rules matching file paths
max_active_rules = 10
max_total_size = 32768       # Size limit for rules in system prompt

Benefits

1. Consistency: Developers can maintain consistent standards across projects
2. Flexibility: Rules can be overridden per-project when language idioms differ
3. Discoverability: New team members can see active rules via /rules list
4. Ecosystem: Community can share rule sets (e.g., "Python Best Practices")
5. Non-intrusive: Fully optional, backward compatible with existing AGENTS.md

Implementation Notes

• Uses existing ~/.config/agents/ directory (same as skills) for consistency
• Rules are injected into system prompt via ${KIMI_ACTIVE_RULES} template variable
• State persisted to rules.state.toml (user and project levels)
• upports file path matching for automatic rule activation

Backward Compatibility

• Fully backward compatible
• Existing AGENTS.md files continue to work unchanged
• Rules system is opt-in via config (enabled by default but harmless if no rules exist)

Additional information

No response

Start by reviewing the existing AGENTS.md handling and ~/.config/agents/ directory conventions, then trace how rules would reach the system prompt through ${KIMI_ACTIVE_RULES}. Done means defining the three-tier precedence, rule state, configuration, path matching, CLI commands, and backward compatibility described in the proposal.