建议: .agents/rules/ 的规则格式标准化

Related: #71 I work at NVIDIA, here different teams use different coding agents -- Claude Code, Cursor, Codex, and so on. We keep running into the same problem: the same coding conventions end up copied into .Claude/rules/, .Cursor/rules/ and other tool-specific directories. I believe this overhead or nuance is more prevalent in the 开源 community where tools differ widely. The formats are close, but not quite the same: | Tool | Rules Location | Path-Scoping Field | | Claude Code | .Claude/rules/*.md | paths: | | Cursor | .Cursor/rules/*.mdc | globs: | | Windsurf | .windsurf/rules/*.md | globs: | | GitHub Copilot | .GitHub/instructions/*.instructions.md | applyTo: | | Cline | .clinerules/*.md | paths: | | JetBrains AI Assistant | .aiassistant/rules/*.md | (IDE-managed) | | Amazon Q | .amazonq/rules/*.md | (none) | Bridging tools like Rulesync exist to generate all of these from a single source, which is useful, but also a sign that the underlying problem is real. AGENTS.md already handles the "here's how this project works" layer. Agent Skills handles reusable capabilities. But for path-scoped rules specifically -- "when touching API files, follow these conventions" -- there's nothing shared. Every tool rolled their own. What I'm proposing A shared file format for .agents/rules/. Not a new standard to compete with AGENTS.md, more a companion spec for the structured bits that don't belong in a freeform markdown file. Cursor already reads from .agents/skills/, so the directory has some cross-tool precedent. The format is markdown with optional YAML frontmatter -- the same general shape several tools already use for project rules, just with standardized field names: markdown --- description: Backend API conventions -- only loaded when touching API files trigger: auto paths: - "src/api/" - "src/routes/" --- - Validate all request bodies with zod schemas before processing - Return errors as { error: string, code: number } -- no free-form messages - Use requireAuth middleware, don't check tokens manually - Every new endpoint needs an integration test in tests/api/ The core frontmatter fields (name, description, trigger, paths) are meant to capture the common subset that already exists across tools. I'm also proposing keywords, priority, and tags as additions that seem useful in practice: | Field | Type | Description | | name | string | Kebab-case identifier (default: filename stem) | | description | string | What this rule covers | | trigger | always | auto | manual | When the rule loads (default: always) | | paths | string[] | Glob patterns for file-scoped activation | | keywords | string[] | Prompt keywords for activation | | priority | integer | Conflict resolution -- higher wins | | tags | …