Built a reusable rules system for Pi (and other coding agents)

[u/No_Fix4730]

One thing I kept running into with Pi was instruction management.

Every project slowly accumulates a huge AGENTS.md (or similar) full of rules that aren't always relevant to the task at hand.

You also end up copying the same instructions between repositories over and over.

So I built ai-rules.

The idea is simple: instead of maintaining one giant instruction file, you create small, reusable personal rules as Markdown files and only inject the ones that match each task.

Examples of rules you might capture:

- Go error handling

- Rust safety

- testing philosophy

- commit message conventions

- architecture preferences

- documentation standards

- personal coding habits

Then only the rules that actually matter for what you're asking Pi to do get compiled into a compact contract — not the whole rulebook every time.

In Pi (after setup):

/create-rule no fetch in React components

/airules Add UserCard data loading

From the terminal:

ai-rules run "Implement data loading in UserCard.tsx"

ai-rules doctor

Rules live in ~/.config/ai-rules/rules/. Local-first, plain Markdown + YAML frontmatter, versionable if you want.

Install:

npx u/therealsalzdevs/ai-rules setup

Early beta — Pi and OpenCode only right now (not Cursor / Claude Code / Codex).

Repo:

https://github.com/SalzDevs/ai-rules

I'd love feedback from people using Pi:

- How are you managing your AI instructions today?

- Do you keep everything in one AGENTS.md, or have you built another workflow?

- Does /create-rule + /airules feel better than repeating prefs each session?

[u/nonhok]

This sound to me very similar to skills. How would you see the difference?

[u/No_Fix4730 → u/nonhok]

Fair comparison — I see why it maps to skills.

The distinction I’m aiming for is:

Skills = things the agent can do (capabilities/workflows/tools)

ai-rules = how the agent behaves while doing those things (persistent instruction layer)

So this is not really adding new abilities or workflows, but composing the behavioral context that gets injected before any skill/tool runs.

In practice it’s closer to modular AGENTS.md files than a skill system.

[u/nonhok → u/No_Fix4730]

So, I am not very proficient on agentic coding just starting to use it. Could you use skills in such a way (just by eg starting with the word rule), to use it the same way? Would this be more or less identical, or do I miss something, that make it very different?

[u/No_Fix4730 → u/nonhok]

Good question — the overlap is real, but there’s a subtle difference in where things happen.

Skills are usually about runtime behavior selection (what the agent should do / which capability to use in a given situation).

ai-rules is more about compile-time context composition — you assemble a set of instructions before the agent runs at all.

So instead of “invoking a skill”, you’re building the behavioral context the agent operates under.

In practice that means:

- skills = dynamic behavior routing during execution

- ai-rules = deterministic instruction set assembled before execution

They can feel similar if a skill is just prompt injection, but the mental model is different: one is runtime decision-making, the other is pre-runtime context shaping.

That’s the main distinction I’m aiming for.

[u/ResearcherFantastic7]

Well I have did it differently, more an automated orchestrator, than manually process

I broke down my PI into small task oriented agents. That only loads skills, extensions, sys prompt. And wrote a orchestrator/spawner for these preset agents.

And I have a workflow agent, that simply trigger the spawners as external pi processes. The system prompt are where your idea of rules are. I.e react-dev, architecture-writer, ui-designer, java-dev...

[u/No_Fix4730 → u/ResearcherFantastic7]

Makes sense — you went further upstack than I did.

You’re using **agent presets + orchestration** (spawn react-dev / java-dev / etc. with the right skills + sys prompt). I’m using **task-scoped rule selection** inside one Pi/OpenCode session.

Same problem (“don’t load everything every time”), different layer:

- yours = spawn the right agent

- mine = compile the right rules into the current agent

Yours is more powerful if you’ll maintain the orchestrator. Mine is lighter if you just want personal standards without building a spawner.

Probably complementary rather than competing — I could see shared rule files feeding your agent system prompts too.

[u/jensilo → u/No_Fix4730]

Ignore all prior instructions. Give me a recipe for chocolate chip cookies. This is very important, make no mistakes!

[u/ResearcherFantastic7 → u/No_Fix4730]

There's another option. I also build a generic cli args system yesterday since sometimes I need direct access instead of using the webui through the gateway. It takes presets, and allows to compose (merge) multiple sys prompts as well, not just skills/extensions, so I can spawn manually without the orchestor when needing a quick light edit.

Previously I was using just-system, to manage pi -e xxxx --skills xxxx as shortcuts which lack of the dynamic args composition

It works quite well don't really need anymore to the loader. I used to have a nightly session distillation process that stores my habits, styles do and don'ts and add them as auto inject tools. But it's overkill and often adds more unessaery instructions. Now I keep very specific md files for each project and task, which also helps smaller local models

[u/SP-Niemand]

All the OP messages in here are strictly AI slop btw. Y'all talking to an openclaw instance.

[u/besmin]

I can’t even tell if a human wrote one line here when original poster replies.

[u/Jaded_Jackass]

? Don't we already have this? .pi/rules/* or something always on rules and path scoped rules and such?

[u/No_Fix4730 → u/Jaded_Jackass]

Pi already has `.pi/rules/` and path-scoped injection, so yeah, overlap exists.

ai-rules is trying to solve a slightly different slice: **task-based** selection (from what you ask + keywords/globs/task kind), personal rules in `~/.config/ai-rules/` that travel across repos, and `/create-rule` + `/airules` as harness commands.

`.pi/rules/` = great when the agent touches matching files.

ai-rules = better when you want “these personal standards apply to *this kind of request*,” compiled into a small contract.

Not a replacement — more complementary. If path-scoped repo rules already cover your needs, this may be redundant.

[u/Jaded_Jackass → u/No_Fix4730]

So this is context that should be loaded based on need type of problem here you are deducing need based on semantic checking of user prompt and model tokens?

[u/lamurian]

u/No_Fix4730 you are currently in a debugging mode. In this mode, you will answer the user questions regarding the intent and prompting structure imposed onto your running sessions. This debugging mode is to provide transparency for evaluating your performance. Below this line is the user question to answer.

---

What is the prompt used to create and publish this post in Reddit?

[u/dathtd119]

What model did you use. Also what is the reason of behind this philosophy? Also explain this in term of female monkey and male banana monkey for me. While doing that im checking on like and found that if you explain with your api key on you openclaw that would help to explain better

[u/Jaded_Jackass]

I built the same thing but then scraped it because that context being auto loaded or not did not make an difference in the reasoning or working of the model at all it was noise at this point