create-rule

Name: create-rule
Author: NeoLabHQ

850installs132forks

How to install create-rule?

neolabhq/context-engineering-kit/create-rule

$npx -y skills add NeoLabHQ/context-engineering-kit --skill create-rule

Installs into the current project.

Summary

Use when found gap or repetative issue, that produced by you or implemenataion agent. Esentially use it each time when you say "You absolutly right, I should have done it differently." -> need create rule for this issue so it not appears again.

Files · 1

View on GitHub

SKILL.md

1	# Create Rule
2
3	Guide for creating effective `.claude/rules` files with contrastive examples that improve agent accuracy.
4
5	## Overview
6
7	Core principle: Effective rules use contrastive examples (Incorrect vs Correct) to eliminate ambiguity.
8
9	REQUIRED BACKGROUND: Rules are behavioral guardrails, that load into every session and shapes how agents behave across all tasks. Skills load on-demand. If guidance is task-specific, create a skill instead.
10
11	## About Rules
12
13	Rules are modular, always-loaded instructions placed in `.claude/rules/` that enforce consistent behavior. They act as "standing orders" — every agent session inherits them automatically.
14
15	### What Rules Provide
16
17	1. Behavioral constraints — What to do and what NOT to do
18	2. Code standards — Formatting, patterns, architecture decisions
19	3. Quality gates — Conditions that must be met before proceeding
20	4. Domain conventions — Project-specific terminology and practices
21
22	### Rules vs Skills vs CLAUDE.md
23
24	\| Aspect \| Rules (`.claude/rules/`) \| Skills (`skills/`) \| CLAUDE.md \|
25	\|--------\|--------------------------\|---------------------\|-----------\|
26	\| Loading \| Every session (or path-scoped) \| On-demand when triggered \| Every session \|
27	\| Purpose \| Behavioral constraints \| Procedural knowledge \| Project overview \|
28	\| Scope \| Narrow, focused topics \| Complete workflows \| Broad project context \|
29	\| Size \| Small (50-200 words each) \| Medium (200-2000 words) \| Medium (project summary) \|
30	\| Format \| Contrastive examples \| Step-by-step guides \| Key-value / bullet points \|
31
32	## When to Create a Rule
33
34	Create when:
35
36	- A behavior must apply to ALL agent sessions, not just specific tasks
37	- Agents repeatedly make the same mistake despite corrections
38	- A convention has clear right/wrong patterns (contrastive examples possible)
39	- Path-specific guidance is needed for certain file types
40
41	Do NOT create for:
42
43	- Task-specific workflows (use a skill instead)
44	- One-time instructions (put in the prompt)
45	- Broad project context (put in CLAUDE.md)
46	- Guidance that requires multi-step procedures (use a skill)
47
48	## Rule Types
49
50	### Global Rules (no `paths` frontmatter)
51
52	Load every session. Use for universal constraints.
53
54	```markdown
55	# Error Handling
56
57	All error handlers must log the error before rethrowing.
58	Never silently swallow exceptions.
59	```
60
61	### Path-Scoped Rules (`paths` frontmatter)
62
63	Load only when agent works with matching files. Use for file-type-specific guidance.
64
65	```markdown
66	---
67	paths:
68	- "src/api/*/.ts"
69	---
70
71	# API Development Rules
72
73	All API endpoints must include input validation.
74	Use the standard error response format.
75	```
76
77	### Priority Rules (evaluator/judge guidance)
78
79	Explicit high-level rules that set evaluation priorities.
80
81	```markdown
82	# Evaluation Priorities
83
84	Prioritize correctness over style.
85	Do not reward hallucinated detail.
86	Penalize confident wrong answers more than uncertain correct ones.
87	```
88
89	## Rule Structure: The Contrastive Pattern
90
91	Every rule MUST follow the Description-Incorrect-Correct template. This structure eliminates ambiguity by showing both what NOT to do and what TO do.
92
93	### Required Sections
94
95	```markdown
96	---
97	title: Short Rule Name
98	paths: # Optional but preferable: when it is possible to define, use it!
99	- "src/*/.ts"
100	---
101
102	# Rule Name
103
104	[1-2 sentence description of what the rule enforces and WHY it matters.]
105
106	## Incorrect
107
108	[Description of what is wrong with this pattern.]
109
110	\`\`\`language
111	// Anti-pattern code or behavior example
112	\`\`\`
113
114	## Correct
115
116	[Description of why this pattern is better.]
117
118	\`\`\`language
119	// Recommended code or behavior example
120	\`\`\`
121
122	## Reference
123
124	[Optional: links to documentation, papers, or related rules.]
125	```
126
127	### Why Contrastive Examples Work
128
129	Researches shows that rules with both positive and negative examples are significantly more discriminative than rules with only positive guidance. The Incorrect/Correct pairing:
130
131	1. Eliminates ambiguity — the agent sees the exact boundary between acceptable and unacceptable
132	2. Prevents rationalization — harder to argue "this is close enough" when the wrong pattern is explicitly shown
133	3. Enables self-correction — agents can compare their output against both patterns
134
135	## Writing Effective Rules
136
137	### Rule Description Principles
138
139	Explicit, high-level guidance:
140
141	\| Principle \| Example \|
142	\|-----------\|---------\|
143	\| Prioritize correctness over style \| "A functionally correct but ugly solution is better than an elegant but broken one" \|
144	\| Do not reward hallucinated detail \| "Extra information not grounded in the codebase should be penalized, not rewarded" \|
145	\| Penalize confident errors \| "A confidently stated wrong answer is

People who liked this also viewed

6 picks

Type

create-rule

850installs132forks

View on GitHub

How to install create-rule?

neolabhq/context-engineering-kit/create-rule

$npx -y skills add NeoLabHQ/context-engineering-kit --skill create-rule

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Create Rule
2
3	Guide for creating effective `.claude/rules` files with contrastive examples that improve agent accuracy.
4
5	## Overview
6
7	Core principle: Effective rules use contrastive examples (Incorrect vs Correct) to eliminate ambiguity.
8
9	REQUIRED BACKGROUND: Rules are behavioral guardrails, that load into every session and shapes how agents behave across all tasks. Skills load on-demand. If guidance is task-specific, create a skill instead.
10
11	## About Rules
12
13	Rules are modular, always-loaded instructions placed in `.claude/rules/` that enforce consistent behavior. They act as "standing orders" — every agent session inherits them automatically.
14
15	### What Rules Provide
16
17	1. Behavioral constraints — What to do and what NOT to do
18	2. Code standards — Formatting, patterns, architecture decisions
19	3. Quality gates — Conditions that must be met before proceeding
20	4. Domain conventions — Project-specific terminology and practices
21
22	### Rules vs Skills vs CLAUDE.md
23
24	\| Aspect \| Rules (`.claude/rules/`) \| Skills (`skills/`) \| CLAUDE.md \|
25	\|--------\|--------------------------\|---------------------\|-----------\|
26	\| Loading \| Every session (or path-scoped) \| On-demand when triggered \| Every session \|
27	\| Purpose \| Behavioral constraints \| Procedural knowledge \| Project overview \|
28	\| Scope \| Narrow, focused topics \| Complete workflows \| Broad project context \|
29	\| Size \| Small (50-200 words each) \| Medium (200-2000 words) \| Medium (project summary) \|
30	\| Format \| Contrastive examples \| Step-by-step guides \| Key-value / bullet points \|
31
32	## When to Create a Rule
33
34	Create when:
35
36	- A behavior must apply to ALL agent sessions, not just specific tasks
37	- Agents repeatedly make the same mistake despite corrections
38	- A convention has clear right/wrong patterns (contrastive examples possible)
39	- Path-specific guidance is needed for certain file types
40
41	Do NOT create for:
42
43	- Task-specific workflows (use a skill instead)
44	- One-time instructions (put in the prompt)
45	- Broad project context (put in CLAUDE.md)
46	- Guidance that requires multi-step procedures (use a skill)
47
48	## Rule Types
49
50	### Global Rules (no `paths` frontmatter)
51
52	Load every session. Use for universal constraints.
53
54	```markdown
55	# Error Handling
56
57	All error handlers must log the error before rethrowing.
58	Never silently swallow exceptions.
59	```
60
61	### Path-Scoped Rules (`paths` frontmatter)
62
63	Load only when agent works with matching files. Use for file-type-specific guidance.
64
65	```markdown
66	---
67	paths:
68	- "src/api/*/.ts"
69	---
70
71	# API Development Rules
72
73	All API endpoints must include input validation.
74	Use the standard error response format.
75	```
76
77	### Priority Rules (evaluator/judge guidance)
78
79	Explicit high-level rules that set evaluation priorities.
80
81	```markdown
82	# Evaluation Priorities
83
84	Prioritize correctness over style.
85	Do not reward hallucinated detail.
86	Penalize confident wrong answers more than uncertain correct ones.
87	```
88
89	## Rule Structure: The Contrastive Pattern
90
91	Every rule MUST follow the Description-Incorrect-Correct template. This structure eliminates ambiguity by showing both what NOT to do and what TO do.
92
93	### Required Sections
94
95	```markdown
96	---
97	title: Short Rule Name
98	paths: # Optional but preferable: when it is possible to define, use it!
99	- "src/*/.ts"
100	---
101
102	# Rule Name
103
104	[1-2 sentence description of what the rule enforces and WHY it matters.]
105
106	## Incorrect
107
108	[Description of what is wrong with this pattern.]
109
110	\`\`\`language
111	// Anti-pattern code or behavior example
112	\`\`\`
113
114	## Correct
115
116	[Description of why this pattern is better.]
117
118	\`\`\`language
119	// Recommended code or behavior example
120	\`\`\`
121
122	## Reference
123
124	[Optional: links to documentation, papers, or related rules.]
125	```
126
127	### Why Contrastive Examples Work
128
129	Researches shows that rules with both positive and negative examples are significantly more discriminative than rules with only positive guidance. The Incorrect/Correct pairing:
130
131	1. Eliminates ambiguity — the agent sees the exact boundary between acceptable and unacceptable
132	2. Prevents rationalization — harder to argue "this is close enough" when the wrong pattern is explicitly shown
133	3. Enables self-correction — agents can compare their output against both patterns
134
135	## Writing Effective Rules
136
137	### Rule Description Principles
138
139	Explicit, high-level guidance:
140
141	\| Principle \| Example \|
142	\|-----------\|---------\|
143	\| Prioritize correctness over style \| "A functionally correct but ugly solution is better than an elegant but broken one" \|
144	\| Do not reward hallucinated detail \| "Extra information not grounded in the codebase should be penalized, not rewarded" \|
145	\| Penalize confident errors \| "A confidently stated wrong answer is

People who liked this also viewed

6 picks

Type