agentleFS
maister-devmaister-dev/maister/.agents/skills/aif-rules/SKILL.md

aif-rules

Skill10 starsChanged 6 months agoMITView 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, 4 of them edited.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

21 rules. 11 are common, 0 are distinctive, and 10 are very specific to this project.

  • 11

    Common

    Most of the 4 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 10

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Add short, actionable rules and conventions for the current project.

    line 11
  2. Very specific:

    FIRST: Read .ai-factory/config.yaml if it exists to resolve:

    line 38
  3. Very specific:

    If config.yaml doesn't exist, use defaults:

    line 42
  4. Common:

    Treat them as project-level overrides for this skill's general instructions

    line 55
  5. Very specific:

    When a skill-context rule conflicts with a general rule written in this SKILL.md,

    line 56
  6. Very specific:

    When there is no conflict, apply both: general rules from SKILL.md + project rules from skill-context

    line 58
  7. Common:

    Do NOT ignore skill-context rules even if they seem to contradict this skill's defaults - they exist because the project's experience …

    line 59
  8. Common:

    Enforcement: After generating any output artifact, verify it against all skill-context rules.

    line 66
  9. Common:

    If any rule is violated - fix the output before presenting it to the user.

    line 67
  10. Very specific:

    Ensure rules.<area> points to the resolved area rules file path

    line 160
  11. Very specific:

    If config.yaml does not exist yet, create a minimal config scaffold using defaults plus the new rules.<area> entry

    line 161
  12. Common:

    Do not continue to Step 2 / Step 3 / Step 4 below.

    line 174
  13. Very specific:

    Use Edit to append the new rule as a - list item at the end of the ## Rules section.

    line 210
  14. Common:

    Keep rules short and actionable (one sentence)

    line 214
  15. Common:

    No categories, headers, or sub-lists - flat list only

    line 215
  16. Common:

    No duplicates - if rule already exists (same meaning), tell user and skip

    line 216
  17. Common:

    If user provides multiple rules at once (separated by newlines or semicolons), add each as a separate line

    line 217
  18. Common:

    No categories: - keep it simple, no headers inside the rules section

    line 232
  19. Common:

    No duplicates: - check for existing rules with the same meaning before adding

    line 233
  20. Very specific:

    RULES.md location: - use the resolved paths.rules_file path (default: .ai-factory/RULES.md)

    line 235
  21. Very specific:

    Area registration: - every area rules file must be mirrored in config.yaml as rules.<area>

    line 236

“Common” is measured: kept by at least 6 in 10 of the 4 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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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> - 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.<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_file and paths.rules
  • Language: language.ui for prompts

If config.yaml doesn't exist, use defaults:

  • RULES.md: .ai-factory/RULES.md
  • rules/: .ai-factory/rules/
  • Language: en (English)

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: Interactive

Mode A: Direct Add

User provided rule text as argument:

$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:

$aif-rules

Ask 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/response

Mode C: Area Rules

User wants to create or update area-specific rules:

$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/<area>.md
  3. Check if area file exists:
    Glob: <resolved rules dir>/<area>.md
  4. If file does NOT exist -> create it with header:

    # <Area> Rules
    
    > Area-specific conventions for <area>. Loaded after rules/base.md.
    
    ## Rules
    
    - [first rule]
  5. 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
  6. Append rule using Edit at the end of the ## Rules section.
  7. Register the area in .ai-factory/config.yaml:
    • Ensure rules.<area> 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.<area> entry
    • Preserve existing rules.base and any other named rules.<other-area> entries
  8. Confirm:
    Rule added to <resolved area rules file> and registered as `rules.<area>` in config.yaml:
    
    - [the rule]
    
    Total <area> 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 <resolved rules dir>/<area>.md plus the matching rules.<area> 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:

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

Step 4: Confirm

Rule added to <resolved RULES.md path>:

- [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.<area>
  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

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.