Configure
AGENT_POLICY.md
The skills describe the pattern. This file describes your project. It's the only place your specifics live — so the framework ships clean, with none of your data inside.
A single Markdown file at your project root. The skills read it to learn what's hot here, where your source of truth lives, and what standing approvals exist. Generate it with /keel-skills:policy-init, or copy the template below. Keep it short and concrete.
The sections#
| # | Section | Required | Purpose |
|---|---|---|---|
| 1 | Hot zones | Yes | Concrete paths / surfaces / actions that require L3. |
| 2 | Source-of-truth artifacts | Yes | Files where only mechanical propagation runs without L3. |
| 3 | Where state & decisions get recorded | Yes | Decisions log, project-state file, per-task notes. |
| 4 | Model tier overrides | No | Project-specific overrides of the delegation defaults. |
| 5 | Definitions for this project | No | Pin down “reversible”, “internal”, “release”, etc. |
| 6 | Standing approvals | No | Recorded decisions granting L3 in advance for a defined scope. |
Rules that keep it honest#
- Hot zones must be concrete — a real path or a real action. Vague hot zones get ignored.
- Anything not listed is treated as potentially hot only when the four-step test says so; under doubt, the implementation escalates to L3.
- A standing approval that does not state its scope explicitly is not a valid L3 source — the implementation must not infer the scope.
Don't gut the defaults
A project may refine the specifics of a hot-zone category, but must not remove a category wholesale. The defaults are the floor.
The template#
Copy this to your project root and fill it in:
AGENT_POLICY.md
# AGENT_POLICY.md — project configuration for the Keel Skills framework
## 1. Hot zones (require explicit L3 approval before any change)
- **Client/external-facing surfaces:**
- <e.g. src/pages, content/, public API routes>
- **Production / data / infra:**
- <e.g. database, schema/migrations, settings, CI/CD, deploy config, hooks>
- **Outward / irreversible actions:**
- <e.g. git push, deploy, sending email, charging, deleting data>
- **Anything else this project treats as hot:**
- <...>
## 2. Source-of-truth artifacts
- <e.g. docs/decisions.md, the canonical spec, the master copy doc>
## 3. Where state and decisions get recorded
- **Decisions log:** <path>
- **Project state / status file:** <path>
- **Per-task notes:** <path or convention>
## 4. Model tier overrides (optional)
- Mechanical work → <default: cheapest tier>
- Research / synthesis → <default: mid tier>
- Planning / architecture / cross-cutting → <default: top tier>
## 5. Definitions for this project (optional)
- "Reversible" here means: <...>
- "Internal" here means: <...>
- A "release" here means: <...>
## 6. Standing approvals (optional)
- [APPROVED <date>] <action + exact scope it covers>Prefer to start from something closer to your stack? See policy packs for ready-made starters.