Awesome-omni-skill install-rules

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.

install

source · Clone the upstream repo

git clone https://github.com/diegosouzapw/awesome-omni-skill

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/diegosouzapw/awesome-omni-skill "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/tools/install-rules" ~/.claude/skills/diegosouzapw-awesome-omni-skill-install-rules && rm -rf "$T"

manifest: skills/tools/install-rules/SKILL.md

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

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.
List rules: Output a list of installable rules (name, short description or scope). Let the user choose “all” or a subset by name.
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).
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.
Confirm before writing:
- Do not create, modify, or overwrite any file under
```
.cursor/rules/
```
  ,
```
.trae/
```
  , or any target path until the user explicitly confirms the plan.
- If overwrites are included, require explicit confirmation that lists which rule targets will be overwritten.
Install to Cursor:
- Target path: Project-level is
```
./.cursor/rules/
```
  (relative to repo root); user-level is platform-dependent (e.g.
```
~/.cursor/rules/
```
  if applicable). Prefer project-level unless the user asks for user-level. Create the directory if it does not exist.
- Format: Write one
```
.mdc
```
  file per rule. Cursor expects frontmatter with at least
```
description
```
  . Optionally set
```
globs
```
  (file pattern) or
```
alwaysApply: true
```
  . Map source rule metadata: use
```
name
```
  and
```
scope
```
  (or equivalent) to build
```
description
```
  ; if scope indicates “all code” or “global”, set
```
alwaysApply: true
```
  ; otherwise leave
```
alwaysApply: false
```
  and omit or set
```
globs
```
  only when the source rule clearly implies a file type.
- Body: Preserve the full rule body (everything after the source frontmatter). Do not drop content.
- Idempotency: Before writing, normalize content (e.g., newline normalization) and compare with existing target content (if any). If identical,
```
skip
```
  .
- Conflicts: If the target exists and differs, do not overwrite unless the plan includes
```
update
```
  and the user explicitly confirmed overwrite. Consider creating a backup (e.g.
```
<file>.bak
```
  ) when overwriting if the user requests it.
Install to Trae (managed block):
- Target path: Project-level is
```
./.trae/project_rules.md
```
  ; user-level is
```
./.trae/user_rules.md
```
  (project-scoped) or
```
~/.trae/user_rules.md
```
  (global, if Trae supports it). Prefer project-level unless the user asks for user-level. Create the
```
.trae/
```
  directory if it does not exist.
- Format: Trae uses plain Markdown.
- Managed block (required):
  - The installer must only write within a managed block to avoid modifying user-authored rules.
  - Use the following markers:
    - Begin:
```

```
    - End:
```

```
  - If the managed block exists, replace the entire block content (idempotent update).
  - If it does not exist, insert the block (typically appended to the end of the file).
- Block contents:
  - Inside the block, render one section per rule using
```
## Rule: <name>
```
    headers, in a stable order (prefer the
```
rules/INDEX.md
```
    registry order when available).
  - Preserve each rule body (everything after the source frontmatter). Do not add Cursor-style frontmatter.
  - Deduplicate by rule name inside the managed block (one name → one section).
- Idempotency: If re-rendered managed block is identical to the current managed block,
```
skip
```
  and do not rewrite the file.
Output: After installation, report per the Output contract (Appendix): the plan, executed actions (
```
created/updated/skipped/conflicts
```
), target path(s), and any conversion notes or failures.

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 (
```

```
…
```

```
). 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.