Menu
Select the right enforcement mechanism for agent behavior rules. Use when configuring agent constraints, writing AGENTS.md, designing skills, or deciding how to enforce a new rule.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Dispatch Codex to review all unreviewed repository work, then verify its correlated findings ticket or clean result. Use when requesting an independent Codex review, auditing all changes, checking work since the last review, or waiting for Codex findings. Trigger: dispatch codex review, independent review, review all changes, check codex findings, run review agent.
Always-on: when a project has tickets, work the frontier (first unblocked open ticket), mark done, update plan status.
Incremental and full-history repository review with resumable adoption batches. Use when reviewing new work, initializing review tracking, reviewing all work to date, resuming historical review, inspecting unreviewed commits, or reviewing changed tickets. Trigger: review new work, adopt repository, review all history, resume review, review marker, unreviewed commits.
End-of-session handoff that captures current state for the next session. Use when ending a work session, switching context, or before a long break.
Consolidate project artifacts — promote scratch to memory, deduplicate memory, process decisions, organize scripts, update steering/skills accuracy. Use periodically or when the project feels cluttered.
Run and interpret crew-research evals — run.sh flags, scores.jsonl fields, activation TPR/FPR verdicts, resuming interrupted runs. Use when running evals, reading eval results, diagnosing a failing definition, or resuming a dead run. Trigger: run the evals, eval results, scores.jsonl, activation test, TPR, delta threshold, resume the run, skip-completed, known gap.
| metadata | {"type":"reference","invocation":"both","practice":null} |
| name | enforcement-hierarchy |
| description | Select the right enforcement mechanism for agent behavior rules. Use when configuring agent constraints, writing AGENTS.md, designing skills, or deciding how to enforce a new rule. |
Never rely on a weaker mechanism when a stronger one is available.
Activate when:
Level 1: Tool Permissions → physically impossible to violate
Level 2: Automated Validation → caught automatically after the fact
Level 3: Verification Gate → independent judgment before completion
Level 4: Steering Guidance → shapes behavior, can be overridden
Catastrophic consequence (data loss, security breach, irreversible action): → Level 1. Use deniedCommands, deniedPaths, or don't grant the tool.
Clear programmatic definition (formatting, types, structure, naming): → Level 2. Use linters, type checkers, schema validators, pre-commit hooks.
Requires judgment to evaluate (correctness, completeness, quality, design): → Level 3. Use verifier agents, review commands, test suites, human review.
Preference or soft convention (style, approach, tone): → Level 4. Use steering files, AGENTS.md, skills, comments.
Promote critical rules. MUST NOT rely on Level 4 (steering) for rules where violation has serious consequences. If an agent should never push to main, use deniedCommands — not a prose instruction.
Match mechanism to rule type. MUST choose the strongest mechanism that fits the rule's nature. Mechanical rules get automation; judgment rules get verification; preferences get guidance.
Layer mechanisms. SHOULD use multiple levels for important rules. A rule can have Level 2 (lint catches obvious cases) AND Level 3 (reviewer catches subtle cases). Layers are additive.
Steering for critical rules. MUST NOT write "NEVER do X" in AGENTS.md when deniedCommands or deniedPaths can physically prevent X.
All rules at Level 4. MUST NOT put every rule in prose guidance. The agent's attention is finite — burying critical rules among preferences dilutes enforcement.
Automation for judgment calls. SHOULD NOT create lint rules for subjective style preferences. False positives from overly strict automation create friction without value.
| I want to prevent... | Use |
|---|---|
| Deleting production data | Level 1: deniedCommands |
| Modifying agent config | Level 1: deniedPaths |
| Shipping type errors | Level 2: CI type-check |
| Shipping broken tests | Level 2: CI test runner |
| Shipping incorrect logic | Level 3: verifier agent |
| Shipping bad prose | Level 3: editor agent |
| Using verbose variable names | Level 4: style skill |
| Preferring composition | Level 4: AGENTS.md |