trae-rules-writer（交易规则编写者）

Trae Rules Writer

Create rules that solve specific problems — not generic rules. Analyzes a project's structure and conventions, then designs a rule to constrain AI behavior. Always confirms with the user via AskUserQuestion before generating any files.

Core Principle: Understand the problem first, analyze the project second, design the rule third, generate only after user confirms.

When to Use

Invoke when:

• User says "create a rule", "create rules for...", "set up code style"
• User says "make AI always...", "enforce naming convention", "configure AI behavior"
• User references .trae/rules/... or uses #RuleName syntax
• User wants to constrain AI behavior for a specific project or file pattern

Do NOT invoke when:

• User wants to create a skill → delegate to project-skill-writer
• User wants to create an agent → delegate to project-agent-writer
• User wants to install an existing skill → delegate to project-skill-installer
• User is asking about Trae rules documentation (answer directly, no generation needed)

Prerequisites

• Node.js >= 18
• Trae IDE (with .trae/rules/ support)

Workflow

[L1: Problem Understanding]
         ↓
[L2: Project Analysis]  ← parallel sub-agents
         ↓
[L3: Rule Design]
         ↓
[L4: Confirmation]  ← AskUserQuestion (MUST confirm)
         ↓
[L5: Generation & Verification]

L1: Problem Understanding

Extract what the user needs — do NOT ask "what rule do you want?" Instead, infer from their problem:

Problem Classification

Extract Rule Specifications

From the user's problem, extract:

• Problem: What the AI is doing wrong (or should start doing)
• Scope: Which files or contexts the rule applies to
• Behavior: What the AI should do differently
• Exceptions: Any cases where the rule should NOT apply

L2: Project Analysis

Scan the project to understand context. Launch these agents in parallel via the Task tool:

Detection Targets

Analysis Output

Project: {name}
Languages: {detected languages}
Existing Rules: {list with application modes, or "none"}
Code Style Tools: {linters, formatters}
Conventions: {naming, imports, architecture patterns}
Conflicts: {any existing rules that overlap with the proposed rule}

L3: Rule Design

Based on Problem (L1) + Analysis (L2), design the rule:

Application Mode Selection

Refer to Application Modes and Rule Types for detailed guidance.

Design Spec

Rule: {name}
Problem: {user's problem in their words}
Application Mode: {Always|File-Specific|Intelligent|Manual}
Scope: {which files/contexts}

Content Summary:
- {constraint 1}
- {constraint 2}

Frontmatter:
  description: {when this rule applies}
  globs: {file patterns, if applicable}
  alwaysApply: {true|false}

File to create:
  - .trae/rules/{rule-name}.md

Design Principles

1. Single Problem — one rule = one problem solved
2. Convention-Aligned — use project's existing style tools as the source of truth
3. Minimal Scope — apply rule to the narrowest file set that covers the problem
4. No Conflicts — verify the new rule does not contradict existing rules

Critical Format Rules

L4: Confirmation (MUST USE AskUserQuestion)

CRITICAL: Before generating ANY files, present the design via AskUserQuestion.

AskUserQuestion Call

Use AskUserQuestion with:

{
  "questions": [{
    "question": "I've designed this rule based on your project. Should I create it?",
    "header": "Rule",
    "multiSelect": false,
    "options": [
      {
        "label": "Create {rule-name} (Recommended)",
        "description": "{application-mode} rule — {1-sentence behavior}. Output: .trae/rules/{rule-name}.md"
      },
      {
        "label": "Adjust design",
        "description": "Let me refine the rule design before generating"
      },
      {
        "label": "Skip",
        "description": "Don't create a rule right now"
      }
    ]
  }]
}

Rules:

• Always show the designed rule name and application mode
• Include the output path so user knows where the file goes
• If multiple application modes are valid, offer alternatives:

{
  "questions": [{
    "question": "This rule could work in different modes. Which fits best?",
    "header": "Application mode",
    "multiSelect": false,
    "options": [
      {
        "label": "Always-on rule (Recommended)",
        "description": "alwaysApply: true — active in every AI interaction"
      },
      {
        "label": "File-specific rule",
        "description": "globs: *.tsx — only active when matching files are open"
      },
      {
        "label": "Skip",
        "description": "Don't create a rule right now"
      }
    ]
  }]
}

• Never generate files without user confirmation
• If user says "Adjust design", loop back to L3 with feedback

L5: Generation & Verification

After user confirms:

Generation

1. Determine output path: .trae/rules/ in the target project root
2. Create rule file using scripts/init_rule.cjs or rule.md.template
3. Fill in frontmatter (description, globs, alwaysApply) from L3 design
4. Write rule content — actionable constraints, not vague guidelines
5. Ensure all paths in rule content are project-relative, never absolute

Generation Command

node scripts/init_rule.cjs \
  --skill-dir <this-skill-dir> \
  --name <rule-name> \
  --description "<when-this-rule-applies>" \
  --output-dir <project>/.trae/rules/

Fallback: If init_rule.cjs fails or the template doesn't fit, write the .md file directly following the template structure.

Verification

Run Quality Validator against the generated rule.

Minimum checks before delivery:

• globs format: comma-separated, no quotes, no arrays
• No absolute paths anywhere in the rule
• description is present and describes when the rule applies
• alwaysApply and globs are not both active simultaneously
• No conflicts with existing rules (from L2 analysis)
• Rule content is actionable (specific constraints, not vague advice)
• Content is in English

Delivery Report

Created rule:
  Name: {rule-name}
  Mode: {Always|File-Specific|Intelligent|Manual}
  Path: {project-relative path}

Frontmatter:
  description: {value}
  globs: {value, if applicable}
  alwaysApply: {value}

To use: {instructions based on application mode}

Error Handling

Boundary Enforcement

This skill ONLY handles:

• Analyzing project for rule design context
• Designing rules based on user problems
• Confirming design via AskUserQuestion
• Generating .trae/rules/*.md files to project-relative paths
• Verifying generated rules against quality gates

This skill does NOT handle:

• Creating skills → project-skill-writer
• Creating agents → project-agent-writer
• Installing skills → project-skill-installer
• Global rule installation (always project-scoped)
• Editing Trae IDE settings or configuration files

Agents

• Project Scanner: Structure, existing rules, and pattern analysis
• Convention Detector: Naming, style, and convention extraction
• Quality Validator: Post-generation rule validation

References

• Rule Types: Choose rule type based on problem
• Application Modes: All mode examples with frontmatter
• Rule Template: Scaffold for new rules
• Trae Rules Docs: Official documentation snapshot