rule-creator
Skill8 starsChanged 6 months agoMITView on GitHub
Interactive rule builder: guides the user through defining a new rule as a constraint doc, then generates the rule .md and installs it.
3 other projects use a version of this.
Adopted by
Most recently taken up by
- adeonir/agent-skillstheir own version, first seen Oct 13, 2026
- bazel-contrib/rules_pythontheir own version, first seen Oct 8, 2026
- aka-momo/claude-doctortheir own version, first seen Mar 6, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- bazel-contrib/rules_python★ 692same name
- adeonir/agent-skills★ 8same name
- aka-momo/claude-doctor★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository16 other files it gives its agents.
- .claude/rules/common/agents.mdAGENTS.md
- agent-creatorSkill
- architect-reviewSkill
- build-fixSkill
- code-reviewSkill
- deep-diveSkill
- docsSkill
- incident-debugSkill
- performance-reviewSkill
- planSkill
- qaSkill
- ralphSkill
- refactor-cleanSkill
- security-reviewSkill
- skill-creatorSkill
- tdd-workflowSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
18 rules. About 0 are common, 16 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈16
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
No args — ask the user what rule they want to create
- Distinctive: line 100
Read any rules that overlap with the user's intent.
- Very specific: line 112
If domain-specific (domain:<tech>), research the tech stack:
- Distinctive: line 113
Ask for key conventions (naming, file structure, macros, patterns)
- Distinctive: line 114
Ask for common mistakes to prevent
- Distinctive: line 115
Ask for framework-specific best practices
- Distinctive: line 123
Read 2-3 existing rules for tone and density reference:
- Distinctive: line 136
Use tables for do/don't comparisons
- Distinctive: line 137
Use bullet lists for directives
- Distinctive: line 138
Use code blocks for concrete examples
- Distinctive: line 139
Keep it scannable — Claude reads this every conversation
- Distinctive: line 143
If >150 lines: suggest splitting into multiple rules
- Distinctive: line 144
If <10 lines: may be too thin — suggest merging with an existing rule
- Distinctive: line 148
APPROVAL GATE: Wait for user to approve the structure.
- Distinctive: line 191
No filler — every line earns its place in the context window
- Distinctive: line 206
Create the directory if needed and write the file.
- Distinctive: line 208
If this is a new language/tech directory, ask:
- Very specific: line 211
If yes, also write to templates/rules/<tech>/<name>.md (if in toolkit repo).
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
/rule-creator
Build a new toolkit rule interactively. Rules are always-on constraints that shape Claude's behavior — coding conventions, patterns to follow, anti-patterns to avoid, and domain-specific guidelines.
Arguments: $ARGUMENTS
<rule-name>— name for the new rule (e.g.,/rule-creator unreal-cpp-conventions)domain:<tech>— create rules for a tech stack (e.g.,/rule-creator domain:unreal)- No args — ask the user what rule they want to create
Goal
Generate a production-ready rule .md file that Claude loads as always-on context, install it into the project's .claude/rules/ directory.
Dependencies
Tools
Read— read existing rules for pattern referenceWrite— create the rule .md fileGlob— find existing rules to study structure and avoid duplication
Connectors
- None required (fully local)
Context
Rules are constraint documents — they tell Claude what to do and what NOT to do, always. They're loaded into context at conversation start and apply to every response.
Rule structure:
# <Title>
<Brief purpose — one sentence>
## <Section>
- Directive 1
- Directive 2
## <Section>
| Pattern | Do This | Not This |
|---------|---------|----------|Key characteristics:
- Rules are prescriptive — "always do X", "never do Y"
- Rules use tables for quick scanning (do/don't, pattern/example)
- Rules are concise — Claude reads ALL rules every conversation, so brevity matters
- Rules don't have phases or gates — they're reference material, not procedures
Rule categories:
| Category | Location | Example |
| Common | .claude/rules/common/ | coding-style.md, testing.md, security.md |
| Language | .claude/rules/<lang>/ | golang/error-handling.md, typescript/types.md |
| Conditional | .claude/rules/conditional/ | read-only.md (only when flag set) |
Existing common rules (avoid duplicating these):
coding-style.md— naming, functions, files, readability, DRYtesting.md— TDD, test pyramid, test qualitysecurity.md— input validation, data access, secrets, OWASPperformance.md— DB queries, API, caching, frontendgit-workflow.md— commits, branches, PRssearch-strategy.md— LEANN, Grep, Glob priorityagents.md— when/how to use agentshooks.md— hook system behaviorpatterns.md— ECC patternsdevelopment-workflow.md— workflow phasescontext-efficiency.md— context window management
Process
Phase 1: Intake — Understand the Rule
- Parse
$ARGUMENTS. If empty, ask:"What rule do you want to create? Describe the conventions or constraints in 1-2 sentences."
- Scan existing rules to avoid duplication:
Read any rules that overlap with the user's intent. If overlap exists, suggest updating the existing rule instead.Glob: .claude/rules/**/*.md Ask the user:
Rule Definition Questionnaire:
- What should Claude always do? (3-10 directives)
- What should Claude never do? (anti-patterns)
- Is this for a specific tech stack? (determines location: common/ vs
<lang>/) - Can you give do/don't examples? (concrete patterns)
- Is this conditional? (only applies in certain modes/contexts)
- If domain-specific (
domain:<tech>), research the tech stack:- Ask for key conventions (naming, file structure, macros, patterns)
- Ask for common mistakes to prevent
- Ask for framework-specific best practices
APPROVAL GATE: Present the interpreted rule scope. Wait for confirmation.
Phase 2: Design — Structure the Rule
- Read 2-3 existing rules for tone and density reference:
Read: .claude/rules/common/coding-style.md Read: .claude/rules/common/security.md - Determine rule category and location:
- Universal convention →
.claude/rules/common/<name>.md - Language/framework specific →
.claude/rules/<tech>/<name>.md - Context-dependent →
.claude/rules/conditional/<name>.md
- Universal convention →
- Structure the rule sections:
- Group directives by topic (naming, structure, patterns, anti-patterns)
- Use tables for do/don't comparisons
- Use bullet lists for directives
- Use code blocks for concrete examples
- Keep it scannable — Claude reads this every conversation
- Estimate rule size:
- Target: 30-100 lines (rules should be concise)
- If >150 lines: suggest splitting into multiple rules
- If <10 lines: may be too thin — suggest merging with an existing rule
- Present the outline to the user.
APPROVAL GATE: Wait for user to approve the structure.
Phase 3: Generate — Write the Rule
Generate the rule .md following this pattern:
# <Title>
<One-sentence purpose>
## <Topic Section>
- Directive using imperative voice ("Use X", "Avoid Y", "Always Z")
- Directive with rationale where non-obvious
## <Patterns Section>
| Pattern | Do This | Not This |
|---------|---------|----------|
| <case> | `good example` | `bad example` |
## <Anti-Patterns Section>
- Never <anti-pattern> — <why>
- Avoid <anti-pattern> — <consequence>
## <Framework-Specific Section> (if domain rule)
### <Subsystem>
- Convention 1
- Convention 2
Writing principles:
- Imperative voice: "Use", "Avoid", "Always", "Never" — not "You should"
- One directive per bullet — scannable, not paragraph-dense
- Tables for comparisons — faster to parse than prose
- Code examples for anything non-obvious
- No filler — every line earns its place in the context window
Present the generated rule to the user.
APPROVAL GATE: User reviews the full rule. Accept edits before writing.
Phase 4: Install — Deploy the Rule
- Determine install path:
- Common:
.claude/rules/common/<name>.md - Language:
.claude/rules/<tech>/<name>.md - Conditional:
.claude/rules/conditional/<name>.md
- Common:
- Create the directory if needed and write the file.
If this is a new language/tech directory, ask:
"Want to add this to the toolkit templates so future projects get these rules automatically?"
If yes, also write to
templates/rules/<tech>/<name>.md(if in toolkit repo).- Verify:
Glob: .claude/rules/**/<name>.md - Report:
"Rule installed:
.claude/rules/<category>/<name>.md- Type: <common/language/conditional>
- Directives:
<count>
This rule is now active in every Claude session in this project."
Error Handling
| Situation | Action |
| Rule name already exists | Warn, offer to update or rename |
| Overlaps with existing rule | Show overlap, suggest merging |
| Rule too long (>150 lines) | Suggest splitting by topic |
| Rule too short (<10 lines) | Suggest merging with related rule |
| User gives vague conventions | Ask for concrete do/don't examples |
| Tech stack not in installer | Offer to add detection + rule templates |
Checklist (Internal — verify before completing)
- No duplication with existing rules
- Correct directory (common/ vs
<tech>/ vs conditional/) - Imperative voice throughout ("Use X" not "You should use X")
- Tables for do/don't comparisons
- Concise — 30-100 lines, every line earns its context window space
- Code examples for non-obvious patterns
- File written and verified
- Toolkit templates updated (if user requested)
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

