---
name: aif-rules
description: 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".
argument-hint: "[rule text or topic]"
allowed-tools: Read Write Edit Glob Grep AskUserQuestion Questions
disable-model-invocation: true
---
# 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:
1. **RULES.md** - Axioms (universal project rules)
- Managed by this skill (`/aif-rules`)
- Short, flat list of hard requirements
- Loaded by all skills
2. **rules/base.md** - Project-specific base conventions
- Created by `/aif` during project setup
- Naming conventions, module boundaries, error handling patterns
- Auto-detected from codebase analysis
3. **rules.** - Area-specific conventions
- Created by this skill (Mode C)
- Registered in `.ai-factory/config.yaml` as named keys such as `rules.api`
- Area-specific patterns and constraints
**Priority:** More specific rules win. `rules.` > `rules/base.md` > `RULES.md`
## Workflow
### Step 0: Load Config
**FIRST:** Read `.ai-factory/config.yaml` if it exists to resolve:
- **Paths:** `paths.rules_file` and `paths.rules`
- **Language:** `language.ui` for prompts and summaries, `language.artifacts` for rules artifacts, and `language.technical_terms` for 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`: `en`
- `artifact_language`: `en`
- `technical_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/.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 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
```text
Check $ARGUMENTS:
- Starts with "area:" or "area "? -> Mode C: Area rules
- Has text? -> Mode A: Direct add
- No arguments? -> Mode B: Interactive
```
### Mode A: Direct Add
User provided rule text as argument:
```text
/aif-rules Always use DTO classes instead of arrays
```
Skip to Step 2 with the provided text as the rule.
### Mode B: Interactive
No arguments provided:
```text
/aif-rules
```
Ask via AskUserQuestion:
```text
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/response
```
### Mode C: Area Rules
User wants to create or update area-specific rules:
```text
/aif-rules area:api
/aif-rules area frontend
```
**Workflow:**
1. **Parse area name** from argument (e.g., `api`, `frontend`, `backend`, `database`)
2. **Resolve the area file path** inside the configured rules directory.
Default: `.ai-factory/rules/.md`
3. **Check if area file exists:**
```text
Glob: /.md
```
4. **If file does NOT exist** -> create it with header:
```markdown
# Rules
> Area-specific conventions for . Loaded after rules/base.md.
## Rules
- [first rule]
```
5. **If file exists** -> ask user what rule to add:
```text
AskUserQuestion: What rule would you like to add to .md?
Current rules in .md:
- [existing rule 1]
- [existing rule 2]
Options:
1. Add new rule - specify below
2. View full file
3. Cancel
```
6. **Append rule** using `Edit` at the end of the `## Rules` section.
7. **Register the area in `.ai-factory/config.yaml`:**
- Ensure `rules.` points to the resolved area rules file path
- If `config.yaml` does not exist yet, create a minimal config scaffold using defaults plus the new `rules.` entry
- Preserve existing `rules.base` and any other named `rules.` entries
8. **Confirm:**
```text
Rule added to and registered as `rules.` in config.yaml:
- [the rule]
Total rules: [count]
```
9. **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_file` artifact.
- Area rules belong only in `/.md` plus the matching `rules.` registration in `config.yaml`.
**Common areas:**
- `api` - REST/GraphQL API conventions
- `frontend` - UI components, state management
- `backend` - Services, business logic
- `database` - Queries, migrations, schemas
- `testing` - Test patterns, coverage
- `security` - Auth, validation, sanitization
### Step 2: Read or Create RULES.md
**Check if the resolved RULES.md path exists:**
```text
Glob:
```
**If file does NOT exist** -> create it with the header and first rule:
```markdown
# 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 follows `language.artifacts`, while preserving stable technical tokens from Step 0.
### Step 4: Confirm
```text
Rule added to :
- [the rule]
Total rules: [count]
```
## Rules
1. **One rule per line** - flat list, no nesting
2. **No categories** - keep it simple, no headers inside the rules section
3. **No duplicates** - check for existing rules with the same meaning before adding
4. **Actionable language** - rules should be clear directives ("Always...", "Never...", "Use...", "Routes must...")
5. **RULES.md location** - use the resolved `paths.rules_file` path (default: `.ai-factory/RULES.md`)
6. **Area registration** - every area rules file must be mirrored in `config.yaml` as `rules.`
7. **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