# Reflexes: how companions encode standards

> The behavioral layer you can inspect and edit — golden rules, best practices, forbidden commands, and reminders. It works in two tiers: prompt-level judgment and hook-level enforcement. Choosing the right tier is the whole game.

Every companion carries a set of **reflexes**: persistent rules that shape how it works, independent of any single conversation. They exist to answer two different needs — **judgment** (rules the companion has to apply with context) and **enforcement** (rules that must hold mechanically, every time). The two needs map to two tiers, and putting a rule in the wrong tier is the most common mistake.

## Two tiers: judgment vs. enforcement

| Reflex | Tier | When it fires | Nature |
|--------|------|---------------|--------|
| **Golden rules** | Prompt | Injected into every session | Persistent judgment — the companion treats it as non-negotiable, but it is still a prompt |
| **Best practices** | Prompt | Injected when your request matches a pattern | Contextual advice for a kind of task |
| **Forbidden commands** | Hook | Checked *before* a command runs | Mechanical block (or a confirmation prompt) |
| **Reminders** | Hook | Fire before and/or after a matching command | Contextual nudge — informs, never blocks |

The distinction that matters: **prompt-tier reflexes guide a judgment the companion still has to make.** They can be reasoned about — and on a bad day, a model can rationalize its way around one. **Hook-tier reflexes don't rely on persuasion**: they intercept the action itself, whether or not the model was paying attention. So the rule of thumb is simple — anything that *must never happen* belongs in a hook; anything that *needs context to decide* belongs in a prompt rule.

## Golden rules — persistent, non-negotiable judgment

A golden rule is a short constraint (a sentence or two) injected into **every** session, so the companion never loses it to a context reset. They are how you encode company standards that require reading the situation:

- "Never commit secrets to GitHub."
- "Always open a branch and a PR before merging."
- "Fix all review feedback in the same PR."

Golden rules can be set per agent or workspace-wide, and are best established early — they are harder to retrofit than to set from day one. Because they live at the prompt tier, they are strongest for behavior that genuinely needs judgment; for something binary and dangerous, prefer a forbidden command (below). See [Companions](companions.md) for how a companion accumulates them over its life.

## Best practices — advice that fires on the right request

A best practice is guidance injected when your request **matches a pattern by meaning** (not by keyword). Ask a companion to "run a project analysis" and it can be reminded to inspect the database schema before querying, without you spelling that out. Best practices are softer than golden rules: they are advice surfaced at the relevant moment, not a constraint the companion defends.

## Forbidden commands — hard blocks before execution

A forbidden command is a pattern checked **before a shell command runs**. A match is either blocked outright or held for your explicit confirmation, depending on how dangerous it is. This is the mechanical tier: the command is stopped regardless of whether the companion "remembered" a rule about it.

Use it for the truly irreversible:

- `git reset --hard` on a branch with un-pushed work
- `rm -rf` on a path outside the working directory
- force-pushing to `main`

If a rule can be phrased as "the command *X* must not run", it belongs here — enforcement beats persuasion. Each forbidden command carries the correct approach to use instead, so the companion is redirected, not just stopped.

## Reminders — contextual nudges on a command

A reminder fires when a command matches — before it runs, after it runs, or both — and **informs rather than blocks**. It uses the same hook machinery as forbidden commands, without the veto:

- Before `gh pr merge`: "Check that no other PR targets this branch first."
- After a failing test command: "Load the testing skill before interpreting results."

Reminders are for knowledge you want resurfaced at exactly the right moment, where blocking would be too heavy-handed.

## Which reflex should I use?

- It **must never happen**, mechanically → **forbidden command** (hook).
- It should be **resurfaced around a specific command** → **reminder** (hook).
- It's **persistent behavior that needs judgment** → **golden rule** (prompt).
- It's **advice relevant to a kind of request** → **best practice** (prompt).

The failure mode to avoid is encoding a hard, binary constraint as a golden rule and trusting the model to honor it every time. If it can be stated as a command pattern, put it in a hook. Reserve the prompt tier for the rules that actually require the companion to weigh context — "is this a defect I fix now, or a nice-to-have for the backlog?" is a judgment; "never force-push to main" is not.

## Where to manage them

In the **desktop app**, the **Reflexes** panel (Settings) lets you inspect and edit all four types, per agent or for everyone. From the **[Claude Code CLI](claude-code-cli.md)**, the same reflexes are exposed through the tamag0 tool server, and session hooks prime them at the right moment: golden rules and matched best practices at prompt time, forbidden commands before a command executes, reminders around the commands they match.

For how reflexes shape day-to-day development — the refining → implement → review flow — see [Best practices for development](best-practices.md).