create-rule

Files (5)

• SKILL.md
• evals.json · evals/
• trigger-eval.json · evals/
• memory-hierarchy.md · references/
• rule-examples.md · references/

SKILL.md (first lines)

# Create Rule

Generate a new memory rule (a project instruction, coding standard, or workflow
guideline) in whatever format the project's AI tooling actually reads.

This creates **memory rules**, not skills or commands (use `create-skill`) and not a
search for existing skills to install (use `find-skills`).

- Tool conventions, OS-specific paths, and frontmatter formats: [references/memory-hierarchy.md](references/memory-hierarchy.md)
- Worked templates per tool and scope: [references/rule-examples.md](references/rule-examples.md)
- Claude Code memory docs: https://code.claude.com/docs/en/memory

## Anti-hallucination guidelines

- Verify existing patterns first: check the actual codebase, don't assume conventions.
- Base rules on real code found in the project, not invented standards.
- If no convention exists, ask the user rather than making one up.
- Check existing CLAUDE.md / AGENTS.md / `.claude/rules/*.md` / `.cursor/rules/*.mdc` for conflicts before adding a new rule.
- Only use `paths` frontmatter on `.claude/rules/*.md` (Claude Code) or `globs` on `.cursor/rules/*.mdc` (Cursor), never on CLAUDE.md or AGENTS.md, which have no frontmatter.

## Steps

1. **Parse arguments**: rule name from `$1` (or the first word of the arguments),
   description from the rest: ask the user if either is missing.
2. **Detect the tool convention** by checking what's already in the repo:
   - `CLAUDE.md` or `.claude/rules/*.md` present → Claude Code.
   - `AGENTS.md` present (with no Claude-specific files) → Codex/Cursor/Copilot/Gemini-CLI-style tool. This repo's own `AGENTS.md` + `CLAUDE.md` pair is a live example of the pattern.
   - `.cursor/rules/*.mdc` present → Cursor's native format.
   - More than one convention present → ask which the user wants updated (or write to more than one, if the user says so).
   - None present → ask the user which tool/format they use before writing anything.
3. **Decide type and scope** for the detected tool (details and templates in the reference):
   - Claude Code: modular `.claude/rules/<name>.md` for a focused single topic vs. a `CLAUDE.md` entry for a short cross-cutting instruction; project (`.claude/rules/`, git-shared) vs. user (`~/.claude/rules/`, personal): ask if unclear from context; path-specific rules need `paths` frontmatter.
   - AGENTS.md-style tools: append a new section to the single root `AGENTS.md`, this format has no per-topic file split or frontmatter.
   - Cursor: `.cursor/rules/<name>.mdc` with `description`/`globs`/`alwaysApply` frontmatter; scope by directory nesting for path-specific rules.
4. **Write the rule**, following the matching template in [references/rule-examples.md](references/rule-examples.md): imperative language, specific expectations, one topic per file, code examples where useful.

## Examples

- `/create-rule api-errors "Standard error handling for API routes"` in a Claude Code repo → writes `.claude/rules/api-errors.md` with `paths: src/api/**/*.ts` frontmatter and concrete guidelines.
- `/create-rule formatting "2-space indentation, single quotes"` in a Claude Code repo, no path scope needed → writes `.claude/rules/formatting.md` with no frontmatter.
- `/create-rule --user preferences "Prefer functional patterns, async/await over raw promises"` → writes `~/.claude/rules/preferences.md` (personal, not git-shared).
- `/create-rule testing "Use table-driven tests and no test interdependence"` in a repo with only `AGENTS.md` → appends a `## Testing` section to `AGENTS.md` instead of creating a new file.
- `/create-rule react-components "Function components only, props typed with interfaces"` in a Cursor repo → writes `.cursor/rules/react-components.mdc` with `globs: ["**/*.tsx"]` frontmatter.

From mgiovani/cc-arsenal, MIT.

More from mgiovani/cc-arsenal