Create, edit, version, and assign system prompts to any project, agent, or feature. Your Rules library is the policy layer that governs every AI interaction on the platform — prompt-as-config, with full version history and import/export.
Rules are named, versioned system prompt records stored in the SQLite database. Create a rule with a name, description, and prompt text. Edit it, preview the change, save as a new version. The rule library is browsable and searchable from the RulesPage UI and from llx rules list in the terminal.
Assign any rule to a project, an agent configuration, or a specific feature. Assigned rules are prepended to the system prompt automatically — no manual copy-paste before each chat. A client project can have a confidentiality rule; the code assistant agent can have a code-focused rule; the outreach loop can have its persona rule. Assignment is many-to-many: one rule can be assigned to multiple contexts simultaneously.
Export individual rules or the entire library as JSON or YAML. Import rules from a file to bootstrap a new instance with your standard prompt library. The export format is human-readable and diff-friendly, so you can version your rules library in git alongside your project documentation and track prompt evolution over time.
The backend/rule_utils.py module provides the programmatic API for rule injection used throughout the platform. Every chat endpoint, agent executor, and outreach pipeline calls rule_utils to fetch and prepend the applicable rules for the current context. Changes to a rule take effect immediately for all future requests — no restart required.
System prompts are the primary mechanism for shaping LLM behaviour. Without a management layer, they're scattered across chat sessions, hardcoded in application code, or copy-pasted from notes. Guaardvark's Rules feature treats system prompts as first-class managed configuration: they live in the database, have names and versions, can be assigned to specific contexts, and are surfaced in a dedicated management UI. This turns "the prompt" from an ad-hoc string into a versioned, auditable, reusable policy artefact.
The Rule SQLAlchemy model in backend/models.py stores each rule with its name, description, prompt text, version number, creation date, and modification date. The rules_api.py Flask blueprint exposes full CRUD at /api/rules/, plus export and import endpoints. backend/rule_utils.py provides the get_rules_for_context(project_id, agent_id, feature) function that all platform components call to retrieve the applicable rules for a given execution context. This function queries the assignment tables, retrieves the relevant rule texts, and returns them as a concatenated system block ready for prepending to any LLM call.
The CLI provides complete rule management: llx rules list shows the full library, llx rules create "Name" "prompt text" creates a new rule, llx rules export dumps the library to stdout as JSON or YAML (specify with --format), and llx rules import file.json imports a rules file. This makes rules manageable from CI/CD pipelines: a git repository can contain a rules.yaml that's imported on deployment to ensure the platform always has the current approved prompt library loaded.
Rule storage and assignment. The Rule model has a direct relationship to Agent (via a foreign key) and an indirect relationship to Project (via an assignment join table). The rules_api.py blueprint handles GET /api/rules (list), POST /api/rules (create), PUT /api/rules/<id> (update), DELETE /api/rules/<id> (delete), POST /api/rules/<id>/assign (assign to context), GET /api/rules/export (export library), and POST /api/rules/import (import). The Settings page exposes a Rules section with import/export UI using these endpoints. The RulesPage provides a full management interface with create, edit, preview, assign, and delete operations.
Rule injection pipeline. backend/rule_utils.py is the single point of rule injection in the platform. It accepts a context specification (project_id, agent_id, feature name), queries the assignment tables, fetches the applicable rules in priority order (feature-level rules take precedence over agent-level, which take precedence over project-level), and concatenates their prompt texts with a separator. The resulting string is prepended to the system prompt before any LLM call. This happens in enhanced_chat_api.py, agent_chat_api.py, and unified_chat_engine.py. The prompt_utils.py utility handles the concatenation formatting and ensures the combined system block doesn't exceed the model's context window.
# Terminal rule management
llx rules list
llx rules create "Technical Writer" "You are a precise technical writer..."
llx rules export --format yaml > rules_backup.yaml
llx rules import rules_backup.yaml
# Assign a rule to a project via API
curl -X POST http://localhost:5000/api/rules/rule_abc/assign -H "Content-Type: application/json" -d '{"project_id": "proj_xyz", "priority": 1}'
# Rules show up in agent context automatically once assignedCreate a rule per client that specifies their tone preferences, prohibited topics, required disclaimers, and confidentiality requirements. Assign the rule to the client's project. Every chat session in that project automatically operates under those constraints without requiring manual system prompt management. When the client's requirements change, edit the rule once and every future session in the project reflects the change.
The code assistant agent, the research agent, and the outreach loop each have distinct behavioural requirements. Assign specialised rules to each agent configuration: the code assistant rule enforces code-only output formats and prohibits hallucinated API calls; the research agent rule instructs citation behaviour and uncertainty acknowledgement; the outreach rule enforces the persona and quality standards. Changing a rule updates the agent's behaviour platform-wide.
Maintain a git repository containing a rules.yaml file with your team's approved prompt library. On each Guaardvark deployment, run llx rules import rules.yaml to ensure the instance has the current approved rules. When a rule is improved, commit the change to git, deploy, and import. Every instance in the team's infrastructure runs the same rule set from the same source of truth, with a full git history of every change.
Setting a system prompt manually for each chat session is error-prone: it's easy to forget, easy to inconsistently apply, and impossible to update retroactively across many sessions. Guaardvark Rules store prompts as database records, assigned at the context level (project, agent, feature) rather than the session level. A rule assigned to a project applies to every session in that project, past and future, without any per-session action. Version history means you can see how a prompt evolved over time and roll back to a previous version if a change produced undesirable behaviour. Import/export means your prompt library can be backed up, shared, and version-controlled alongside your other configuration.
Yes. Multiple rules can be assigned to a project, each with a priority value. Rules are concatenated in priority order by rule_utils.py, so higher-priority rules appear earlier in the system block. A common pattern is to have a company-wide base rule (low priority) and a project-specific override rule (high priority) that refines or constrains the base.
Yes. Rules are prepended to the system prompt and consume tokens from the context window. Very long rules (thousands of words) can crowd out document context and conversation history. Guaardvark's prompt_utils.py monitors the combined system block length and logs a warning when it exceeds 20% of the model's context window. Keep individual rules focused and concise to avoid this issue.
Yes. The RulesPage includes a preview mode where you can compose a test message and see the combined system prompt (base + all assigned rules) alongside the LLM's response before committing the rule assignment. This lets you verify that a new rule produces the expected behaviour without affecting any live project sessions.
Each edit to a rule increments its version number, and the previous version is preserved in the database. The version history is accessible from the rule's detail panel in the RulesPage. You can view the diff between any two versions and restore a previous version as the active version. Version history is included in the export format so it survives import/export cycles.
Yes. The Social Outreach feature's OUTWARD_FACING_SYSTEM_BLOCK is implemented as a rule that is assigned to the outreach agent. You can edit it from the RulesPage like any other rule — changing the persona wording, adjusting the tone instructions, or adding platform-specific guidance. The change takes effect on the next outreach task execution without any code changes.