Rules and guidelines for your agents

Overview

Natural language rules in your agents’ context are the best place to start. But as your projects get more complex and the tasks you give to your agents grow, you need something more structured. Rules in plain markdown files are simply steering. There’s nothing making the agent adhere to them. gjalla helps you turn rules into deterministic guardrails wherever possible, and requires your agent to report its rule adherence on commit. We’ve seen this approach prove successful in greatly raising the level of rule adherence across numerous codebases and teams.

Rule types

Every rule carries one of five types. The type decides how gjalla treats it:

• process: how work should move (spec, implement, review, commit). Compiles into milestone gates enforced at commit.
• check: a validation with a machine-evaluable config. Evaluated deterministically on demand.
• constraint: a hard boundary. Evaluable like a check when it has a config; otherwise treated like a principle until you give it one.
• principle: a guideline agents should follow. Steering, plus adherence reporting.
• ADR: a decision and the reasoning behind it, so agents stop relitigating it.

What gets compiled into determinism

Today, process rules are the ones that become deterministic gates. A process rule compiles into deterministic checks that are applied via agent hooks. This makes them actual guardrails for agents rather than simply natural language steering, and results in much stronger rule adherence.

Example: the seeded rm protection

Every project starts with a small set of platform process rules derived from real coding-agent incidents. One of them, no-rm-root-or-home, exists because agents have wiped home directories in the wild. The rule is plain language plus two compiled fields:

name: no-rm-root-or-home
type: process
enforcement: block        # or "ask" to require confirmation
command_pattern: rm aimed at /, ~, or $HOME

On gjalla sync, the pattern is installed into your agent’s native hook machinery. Before the agent runs any shell command, the hook matches it against the pattern: block rules stop the command outright, ask rules (like confirm-recursive-force-rm) pause for your confirmation. The agent never gets a vote, and the check runs the same way under every agent.

Check-type rules with a machine-evaluable config (like diff_must_not_contain or max_file_lines) can also be evaluated deterministically on demand with gjalla rules check. Rules without an evaluable config are reported as unevaluated, never silently counted as passing.

How the rest are treated

Rules that can’t be reduced to a deterministic check still do real work, in three places:

• In context: gjalla sync distributes them into each agent’s native instruction files, so every agent starts from the same boundaries.
• At commit: the agent reviews its diff against the rules and reports adherence in the commit record. The record is validated by the pre-commit hook and checked externally, so the report is accountable, not free-form.
• At PR review: gjalla’s review evaluates the change against these rules and flags violations on the pull request.

Context

Context is the set of instructions your agents receive when working in your project. It tells them how to behave: coding conventions, architectural constraints, preferred patterns, and team agreements. Context is organized into three layers that merge together.

Editing your instructions

Go to Guardrails → Context and click Edit on “Your Instructions.” Write anything your agents should know: coding style, naming conventions, architectural patterns, technology preferences, or team agreements.

We use event-driven patterns for service communication.
Always check gjalla rules before committing.
Prefer composition over inheritance.
Use Drizzle ORM for all database access, no raw SQL.

Agent memories

When any agent saves a memory, it becomes available to every other agent on the next gjalla sync. If Claude Code learns that your API uses a specific error format, Cursor inherits it. View and manage memories in the Context tab, and see the Memories guide for scopes and skills.

Skills

Skills are the other thing your agents share: reusable playbooks like “write a spec before a risky change” or “verify before marking complete.” Every project ships with a curated platform set, and you can add your own. They are checked for whether they are safe for an agent to execute before they are shared.

Toggle them in Guardrails → Skills; on the next gjalla sync the enabled set is installed as native files each agent discovers on its own (SKILL.md for Claude Code and OpenCode, the matching format for Codex, Gemini, Cursor, and Windsurf). Browse the resolved set with gjalla skills show.

Rules, skills, context and memories all resolve through the same three layers. See layering.

Source badges

Throughout the Guardrails section, badges indicate where content comes from:

• gjalla logo: platform content (managed by gjalla)
• “System” badge: system-level content (shared across projects)
• No badge: your custom project content

CLI & agent integration

Everything in Guardrails reaches your agents through gjalla sync: rules, context, skills, and memories are installed as native files each agent discovers on its own. Claude Code auto-syncs via the SessionStart hook; for other tools, run gjalla sync at session start. Check the active rule set anytime with gjalla rules show.