aif-rules
Skill261 starsChanged 2 months agoBSD-3-ClauseView on GitHub
Add project-specific rules and conventions to the configured RULES.md artifact. Each invocation appends new rules. These rules are automatically loaded by /aif-implement before execution. Use when user says "add rule", "remember this", "convention", or "always do X".
4 other projects use a version of this, 3 of them edited.
Adopted by
Most recently taken up by
- letuhao/lore-weaveword for word, first seen Oct 17, 2026
- lee-to/ai-factoryedited, first seen Sep 22, 2026
- maister-dev/maisteredited, first seen May 27, 2026
- hightemp/go_computer_use_mcp_serveredited, first seen Mar 21, 2026
Other versions4 projects use a version of this.
Word for word · 1
- letuhao/lore-weave★ 35100% same
Edited · 3
- lee-to/ai-factory★ 1.2k75% same
- maister-dev/maister★ 1099% same
- hightemp/go_computer_use_mcp_server★ 281% same
Wrote their own version · 0
None found.
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 repository36 other files it gives its agents.
- AGENTS.mdAGENTS.md
- aif-architectureSkill
- aif-archiveSkill
- aif-best-practicesSkill
- aif-build-automationSkill
- aif-ciSkill
- aif-commitSkill
- aif-docsSkill
- aif-evolveSkill
- aif-exploreSkill
- aif-fixSkill
- aif-groundedSkill
- aif-implementSkill
- aif-improveSkill
- aif-loopSkill
- aif-planSkill
- aif-qa-checkSkill
- aif-qaSkill
- aif-reviewSkill
- aif-roadmapSkill
- aif-rules-checkSkill
- aif-security-checklistSkill
- aif-skill-generatorSkill
- aifSkill
- aif-verifySkill
- golang-code-styleSkill
- golang-concurrencySkill
- golang-contextSkill
- golang-databaseSkill
- golang-design-patternsSkill
- golang-documentationSkill
- golang-error-handlingSkill
- golang-namingSkill
- golang-performanceSkill
- golang-securitySkill
- golang-testingSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
24 rules. 11 are common, 0 are distinctive, and 13 are very specific to this project.
11
Common
Most of the 3 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
13
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 11
Add short, actionable rules and conventions for the current project.
- Very specific: line 38
FIRST: Read .ai-factory/config.yaml if it exists to resolve:
- Very specific: line 42
If config.yaml doesn't exist, use defaults:
- Very specific: line 54
If technical_terms_policy is not one of keep, translate, or mixed, treat it as keep.
- Very specific: line 56
All AskUserQuestion prompts, progress updates, confirmations, and next-step guidance MUST be written in ui_language.
- Common: line 70
Treat them as project-level overrides for this skill's general instructions
- Very specific: line 71
When a skill-context rule conflicts with a general rule written in this SKILL.md,
- Very specific: line 73
When there is no conflict, apply both: general rules from SKILL.md + project rules from skill-context
- Common: line 74
Do NOT ignore skill-context rules even if they seem to contradict this skill's defaults - they exist because the project's experience …
- Common: line 81
Enforcement: After generating any output artifact, verify it against all skill-context rules.
- Common: line 82
If any rule is violated - fix the output before presenting it to the user.
- Very specific: line 175
Ensure rules.<area> points to the resolved area rules file path
- Very specific: line 176
If config.yaml does not exist yet, create a minimal config scaffold using defaults plus the new rules.<area> entry
- Common: line 189
Do not continue to Step 2 / Step 3 / Step 4 below.
- Very specific: line 225
Use Edit to append the new rule as a - list item at the end of the ## Rules section.
- Common: line 229
Keep rules short and actionable (one sentence)
- Common: line 230
No categories, headers, or sub-lists - flat list only
- Common: line 231
No duplicates - if rule already exists (same meaning), tell user and skip
- Common: line 232
If user provides multiple rules at once (separated by newlines or semicolons), add each as a separate line
- Very specific: line 233
Write generated rule text in artifact_language.
- Common: line 248
No categories: - keep it simple, no headers inside the rules section
- Common: line 249
No duplicates: - check for existing rules with the same meaning before adding
- Very specific: line 251
RULES.md location: - use the resolved paths.rules_file path (default: .ai-factory/RULES.md)
- Very specific: line 252
Area registration: - every area rules file must be mirrored in config.yaml as rules.<area>
“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
AI Factory Rules - Project Conventions
Add short, actionable rules and conventions for the current project. Rules are saved to the configured RULES.md artifact (default: .ai-factory/RULES.md) and automatically loaded by /aif-implement before task execution.
Rules Hierarchy
AI Factory supports a three-level rules hierarchy:
- RULES.md - Axioms (universal project rules)
- Managed by this skill (
/aif-rules) - Short, flat list of hard requirements
- Loaded by all skills
- Managed by this skill (
- rules/base.md - Project-specific base conventions
- Created by
/aifduring project setup - Naming conventions, module boundaries, error handling patterns
- Auto-detected from codebase analysis
- Created by
- rules.
<area>- Area-specific conventions- Created by this skill (Mode C)
- Registered in
.ai-factory/config.yamlas named keys such asrules.api - Area-specific patterns and constraints
Priority: More specific rules win. rules.<area> > rules/base.md > RULES.md
Workflow
Step 0: Load Config
FIRST: Read .ai-factory/config.yaml if it exists to resolve:
- Paths:
paths.rules_fileandpaths.rules - Language:
language.uifor prompts and summaries,language.artifactsfor rules artifacts, andlanguage.technical_termsfor human-readable technical terminology in rules
If config.yaml doesn't exist, use defaults:
- RULES.md:
.ai-factory/RULES.md - rules/:
.ai-factory/rules/ ui_language:enartifact_language:entechnical_terms_policy:keep
Resolved language values:
ui_language = language.ui || "en"artifact_language = language.artifacts || language.ui || "en"technical_terms_policy = language.technical_terms || "keep"
If technical_terms_policy is not one of keep, translate, or mixed, treat it as keep. Legacy values such as english also behave like keep.
All AskUserQuestion prompts, progress updates, confirmations, and next-step guidance MUST be written in ui_language.
Generated or updated rules artifacts under paths.rules_file and paths.rules/<area>.md MUST be written in artifact_language.
Templates and examples define structure, not fixed English output. If artifact_language is not en, translate human-readable headings, notes, rule text, labels, and confirmation prose before saving. Preserve markdown structure, paths, commands, config keys such as rules.<area>, area names, code identifiers, package names, API names, and raw errors unchanged. Apply technical_terms_policy to other human-readable terminology.
Step 0.1: Load Skill Context
Read .ai-factory/skill-context/aif-rules/SKILL.md - MANDATORY if the file exists.
This file contains project-specific rules accumulated by /aif-evolve from patches,
codebase conventions, and tech-stack analysis. These rules are tailored to the current project.
How to apply skill-context rules:
- Treat them as project-level overrides for this skill's general instructions
- When a skill-context rule conflicts with a general rule written in this SKILL.md, the skill-context rule wins (more specific context takes priority - same principle as nested CLAUDE.md files)
- When there is no conflict, apply both: general rules from SKILL.md + project rules from skill-context
- Do NOT ignore skill-context rules even if they seem to contradict this skill's defaults - they exist because the project's experience proved the default insufficient
- CRITICAL: skill-context rules apply to ALL outputs of this skill - including the RULES.md format and rule formulation. If a skill-context rule says "rules MUST follow format X" or "RULES.md MUST include section Y" - you MUST comply. Generating rules that violate skill-context is a bug.
Enforcement: After generating any output artifact, verify it against all skill-context rules. If any rule is violated - fix the output before presenting it to the user.
Step 1: Determine Mode
Check $ARGUMENTS:
- Starts with "area:" or "area "? -> Mode C: Area rules
- Has text? -> Mode A: Direct add
- No arguments? -> Mode B: InteractiveMode A: Direct Add
User provided rule text as argument:
/aif-rules Always use DTO classes instead of arraysSkip to Step 2 with the provided text as the rule.
Mode B: Interactive
No arguments provided:
/aif-rulesAsk via AskUserQuestion:
What rule or convention would you like to add?
Examples:
- Always use DTO classes instead of arrays for data transfer
- Routes must use kebab-case
- All database queries go through repository classes
- Never use raw SQL, always use the query builder
- Log every external API call with request/responseMode C: Area Rules
User wants to create or update area-specific rules:
/aif-rules area:api
/aif-rules area frontendWorkflow:
- Parse area name from argument (e.g.,
api,frontend,backend,database) - Resolve the area file path inside the configured rules directory.
Default:
.ai-factory/rules/<area>.md - Check if area file exists:
Glob: <resolved rules dir>/<area>.md If file does NOT exist -> create it with header:
# <Area> Rules > Area-specific conventions for <area>. Loaded after rules/base.md. ## Rules - [first rule]If file exists -> ask user what rule to add:
AskUserQuestion: What rule would you like to add to <area>.md? Current rules in <area>.md: - [existing rule 1] - [existing rule 2] Options: 1. Add new rule - specify below 2. View full file 3. Cancel- Append rule using
Editat the end of the## Rulessection. - Register the area in
.ai-factory/config.yaml:- Ensure
rules.<area>points to the resolved area rules file path - If
config.yamldoes not exist yet, create a minimal config scaffold using defaults plus the newrules.<area>entry - Preserve existing
rules.baseand any other namedrules.<other-area>entries
- Ensure
- Confirm:
Rule added to <resolved area rules file> and registered as `rules.<area>` in config.yaml: - [the rule] Total <area> rules: [count] - STOP after Mode C completes.
- Do not continue to Step 2 / Step 3 / Step 4 below.
- Those steps apply only to top-level axioms rules in the resolved
paths.rules_fileartifact. - Area rules belong only in
<resolved rules dir>/<area>.mdplus the matchingrules.<area>registration inconfig.yaml.
Common areas:
api- REST/GraphQL API conventionsfrontend- UI components, state managementbackend- Services, business logicdatabase- Queries, migrations, schemastesting- Test patterns, coveragesecurity- Auth, validation, sanitization
Step 2: Read or Create RULES.md
Check if the resolved RULES.md path exists:
Glob: <resolved RULES.md path>If file does NOT exist -> create it with the header and first rule:
# Project Rules
> Short, actionable rules and conventions for this project. Loaded automatically by /aif-implement.
## Rules
- [new rule here]If file exists -> read it, then append the new rule at the end of the rules list.
Step 3: Write Rule
Use Edit to append the new rule as a - list item at the end of the ## Rules section.
Formatting rules:
- Each rule is a single
-line - Keep rules short and actionable (one sentence)
- No categories, headers, or sub-lists - flat list only
- No duplicates - if rule already exists (same meaning), tell user and skip
- If user provides multiple rules at once (separated by newlines or semicolons), add each as a separate line
- Write generated rule text in
artifact_language; translate user-provided human-readable rule text when needed so the persisted artifact followslanguage.artifacts, while preserving stable technical tokens from Step 0.
Step 4: Confirm
Rule added to <resolved RULES.md path>:
- [the rule]
Total rules: [count]Rules
- One rule per line - flat list, no nesting
- No categories - keep it simple, no headers inside the rules section
- No duplicates - check for existing rules with the same meaning before adding
- Actionable language - rules should be clear directives ("Always...", "Never...", "Use...", "Routes must...")
- RULES.md location - use the resolved
paths.rules_filepath (default:.ai-factory/RULES.md) - Area registration - every area rules file must be mirrored in
config.yamlasrules.<area> - Ownership boundary - this command owns the configured RULES.md artifact and may update the
rules.*subset of.ai-factory/config.yaml; other context artifacts stay read-only unless explicitly requested by the user
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.

