install-rules

name	install-rules
description	Install rules from this project or a specified Git repo into Cursor or Trae IDE. Use when the user wants to add project/global rules to their editor from ai-cortex rules/ or another repository.
tags	["automation","infrastructure","eng-standards"]
version	1.2.0
license	MIT
related_skills	["discover-skills"]
recommended_scope	both
metadata	{"author":"ai-cortex"}

Skill: Install Rules

Purpose

Install rules (passive constraints for AI behavior) from a rules source into an editor’s rules destination. The primary source is this project’s rules/ directory, or a user-specified Git repository. Supported install targets: Cursor (.cursor/rules/) and Trae IDE (.trae/project_rules.md / .trae/user_rules.md).

Use Cases

• This project: Install all or selected rules from the current repo’s rules/ into the current project’s Cursor or Trae rules.
• Another Git repo: User provides owner/repo (and optionally branch/ref and subpath); list rules from that repo and install selected ones to Cursor or Trae.
• Bootstrap: After cloning ai-cortex or another rule-providing repo, install its rules so the Agent respects them in the user’s workspace.

Behavior

1. Resolve source:

   • This project: Use the repo’s rules/ directory. Treat rules/INDEX.md as the authoritative list; if present, parse the registry table to get rule names and file paths. Otherwise list all *.md files under rules/ (excluding INDEX.md).
   • Specified Git repo: User supplies owner/repo or full clone URL, and optionally branch/ref and subpath (e.g. rules or docs/rules). The Agent must have network access to clone or fetch; state this before proceeding. Discover rules by: (a) looking for an INDEX.md (or equivalent) in the subpath and parsing the registry, or (b) listing *.md files in that directory. If the repo or path does not exist or contains no rules, report clearly and do not write files.

2. List rules: Output a list of installable rules (name, short description or scope). Let the user choose “all” or a subset by name.

3. Analyze destination state (required):

   • Cursor: List existing ./.cursor/rules/*.mdc (project-level) or the user-level rules directory if selected. Identify which target filenames already exist.
   • Trae: Read the selected destination file (./.trae/project_rules.md or ./.trae/user_rules.md, or global user-level if selected) if it exists. Detect whether a managed block already exists (see step 6).

4. Build an install plan (required):

   • For each selected rule, decide one action: create, skip (identical), conflict (different), or update (explicit overwrite approved).
   • The default must be conservative:
     • Existing-but-different targets are conflict until the user explicitly approves overwrite.
     • Existing-and-identical targets are skip.
   • Output the plan before any write, including the intended target path(s) and per-rule actions.

5. Confirm before writing:

   • Do not create, modify, or overwrite any file under .cursor/rules/, , or any target path until the user explicitly confirms the plan.

Input & Output

Input

• Source: Default “this project” (current repo rules/). Or: Git repo owner/repo or URL, with optional branch/ref and subpath (e.g. rules, docs/rules).
• Target: One or both of Cursor, Trae. Both are supported.
• Scope: “All” rules or a subset (list of rule names).
• Destination: Project-level (.cursor/rules/ for Cursor, .trae/project_rules.md for Trae) or user-level; default project-level.
  • Conflict policy: Default is conservative (no overwrite). If the user requests overwrites, the plan must mark update for those targets and require explicit confirmation.

Output

• Before install: Rule list + destination analysis summary + install plan (create/skip/conflict/update) with target paths.
• After install: Executed actions, target path(s), and any errors or conversion notes (see Appendix: Output contract).

Restrictions

• No write without confirmation: Do not create or modify files under .cursor/rules/, .trae/, or any target path without explicit user confirmation of the plan.
• No overwrite without confirmation: If a target already exists and differs, do not overwrite unless the user explicitly agrees and the plan includes update for that target.
• Git and network: Installing from a Git repo requires clone/fetch; state that network (and optionally git) is required and confirm before running clone/fetch.
• Trae managed block only: When installing to Trae, only write within the managed block (<!-- ai-cortex:begin --> … <!-- ai-cortex:end -->). Do not modify content outside the block.

Self-Check

• Source resolved: Was the rules source (this repo rules/ or specified Git repo + path) read correctly? Was rules/INDEX.md or equivalent used when present?
• List shown: Was the user shown the list of rules to be installed before any write?
• Destination analyzed: Were existing Cursor/Trae destinations scanned and summarized before building a plan?
• Plan produced: Was an explicit plan (create/skip/conflict/update) shown before any write?
• Confirmation: Was explicit user confirmation obtained before creating/modifying/overwriting any file?
• Output contract: Does the post-install output include the plan, executed actions, target path(s), and any conversion or failure notes?
• Restrictions: Were overwrites only done with explicit consent? For Trae, was content outside the managed block left untouched?

Examples

Example 1: Install all rules from this project to Cursor

• Scenario: User says “install this project’s rules into Cursor.”
• Steps:
  1. Read rules/INDEX.md and build the list of rules from the registry table (or list rules/*.md excluding INDEX.md).
  2. Analyze existing .cursor/rules/*.mdc and build a plan (create/skip/conflict).
  3. Present the plan and ask for confirmation.
  4. After confirmation, execute the plan: write only create actions; do not overwrite conflicts unless explicitly approved.
  5. Output: created/updated/skipped/conflicts and path ./.cursor/rules/.

Example 2: Edge case — Git repo with no INDEX, custom subpath

• Scenario: User wants to install rules from other-org/repo, branch main, subpath docs/rules. That repo has no docs/rules/INDEX.md, only docs/rules/foo.md and docs/rules/bar.md.
• Steps:
  1. State that network access is needed to clone/fetch the repo; ask for confirmation.
  2. After confirmation, clone or fetch and list docs/rules/*.md (e.g. foo.md, bar.md). Do not assume an INDEX; use the directory listing as the rule list.
  3. Present the list (foo, bar) and target path; ask which rules to install (or “all”) and confirm before writing.
  4. If the user selects only "foo", install only the file derived from foo.md to .cursor/rules/foo.mdc and report: installed [foo], path ./.cursor/rules/, and that bar was skipped.

Example 3: Install rules to Trae

• Scenario: User says "install this project's rules into Trae" or "install to both Cursor and Trae".
• Steps:
  1. Read rules/INDEX.md and build the list of rules.
  2. Read .trae/project_rules.md if it exists and detect whether the managed block already exists.
  3. Build a plan (insert managed block, update managed block, or skip if identical) and present it for confirmation.
  4. After confirmation, render the managed block with ## Rule: <name> sections and insert/replace the block only.
  5. Output: created/updated/skipped and path ./.trae/project_rules.md, noting managed-block behavior.

---

Appendix: Output contract

After performing an install, the Agent must report:

Element	Requirement
Plan	Show the pre-write plan with per-rule actions (create/skip/conflict/update) and target path(s).
Executed actions	Summarize what was actually created/updated/skipped and list any conflicts left unresolved.
Installed rules	List of rule names (or filenames) that were written (subset of executed actions).
Target path	Absolute or repo-relative path (e.g. ./.cursor/rules/ for Cursor, ./.trae/project_rules.md for Trae).
Conversion notes	Brief note if source used a different format and how it was mapped (e.g. .md to Cursor .mdc, or .md concatenated to Trae project_rules.md).
Failures	Any rule that could not be installed (e.g. read error, write error) and reason.
Trae	If Trae was selected, note the managed block markers and confirm that content outside the block was not modified.