The Worker Remit is the only artifact you customize per agent. Everything else in Praxen is generic. The quality of your remit directly determines the quality of Praxen’s output: vague remits produce low-confidence findings; specific remits produce sharp, actionable ones.
This page covers what to put in a remit and how to write rules that Praxen can verify. The starting template is WORKER_REMIT_template.md at the repo root — copy it and fill it in by hand (the ideal path), or have the Praxen skill draft one for you (see Letting the skill draft one for you below).
A Worker Remit is a policy document, not a system description.
A good remit is something an operator could write before the agent is built and use unchanged after the agent is deployed.
Hand-authoring is the ideal path — you understand the agent’s intended behavior better than any tool does. But if you’d rather start from a draft, the Praxen skill can author one for you. Point it at whatever best captures what the agent should do:
Ask Claude Code to “draft a Worker Remit for this agent” with the description or docs available, and the skill walks the WORKER_REMIT_template.md structure to produce a complete first draft. Treat the result as a starting point, not a finished remit: review every section, tighten anything vague (see the specificity test), and make sure the forbidden actions reflect your intent — a drafted remit is only as good as what it had to work from.
The skill authors from the agent’s documentation — it states what the docs say the agent should do and leaves verifying the code to the scan, so the policy body carries no guesses or tags (every clause is a stated obligation). Where the docs don’t settle a decision only you can make — authorized scope, thresholds, the counterparty allowlist — the skill collects those in an “Open Questions for the operator” section at the end of the file, below the closing footer. Resolve those before you rely on the remit: answer each as a real clause or delete it.
The template is a complete reference, but the load-bearing sections are:
If a section doesn’t apply to your agent, leave it minimal but explain why — Praxen will note vague or missing rules.
Multi-component deployments (e.g., an LLM agent plus an operator or desktop layer) go in one combined remit, not several: name the primary RAISE subject in a scope note in the Mission, and give each component its own sub-headings within the existing sections rather than adding new top-level sections.
Every actionable rule should state a verifiable constraint on behavior. The test:
Could Praxen read this rule, read the agent’s evidence, and determine whether the rule is satisfied?
If yes, the rule is verifiable. If no, it’s vague — and Praxen will mark it as Vague Policy in the Remit Coverage section of the report.
~/projects/”These give Praxen something to check. The constraint is observable in code or behavior.
These are intentions, not constraints. Praxen cannot verify them and will flag them as policy gaps.
Don’t say “alert if something suspicious”. Say “alert the operator when a reply is addressed to any address not in the Rolodex.” The first is a vague intention; the second is a checkable rule.
A counterparty list of “the team’s email addresses” is not enforceable without enumeration. List the actual addresses (or specify how the list is maintained). The same applies to allowed channels, allowed file paths, allowed tools.
Both are useful. “Must always run fraud detection before approving an invoice” and “Must never approve invoices from vendors not in the registry” describe different constraints and Praxen checks them differently.
Don’t say “sensitive actions require approval”. List which actions, what “approval” looks like (a specific operator confirmation? a signed token? a human review queue?), and what happens if approval is unavailable.
You will rarely write a perfect remit on the first pass. The expected workflow:
A mature remit usually goes through three or four iterations before the policy and the implementation align.
See Challenging and Revising Findings for guidance on when a finding indicates a remit problem versus a code problem.
approved_channels; Calendar invites may only be issued to known contacts” is a remit.If the agent is asked to write or update its own remit, treat that with caution. Praxen will surface a finding when the Updated By field of the remit names the agent itself rather than the operator. The remit is supposed to be operator-authored — it’s the thing the agent is constrained against, so the agent should not be the one defining its own constraints.