Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/quitohooded/keel-skills/llms.txt

Use this file to discover all available pages before exploring further.

/keel-skills:policy-init is a Claude Code slash command that scaffolds a project-specific AGENT_POLICY.md by interviewing you about your hot zones, source-of-truth files, and model-tier overrides. This is what keeps the Keel Skills framework generic — the skills and hooks ship with sensible defaults, but all project-specific data lives in the file this command generates. Run it once per project to give the agent the context it needs to make good decisions for that codebase.

Running the command

/keel-skills:policy-init
Run this in each project where you want Keel to know the specifics. If an AGENT_POLICY.md already exists at the project root, the command reads it and offers to review or extend it rather than overwriting it.

What the command does

1

Check for an existing policy

The command checks whether an AGENT_POLICY.md already exists at the project root. If it does, the command reads it and shifts into review/extend mode instead of starting fresh.
2

Read the policy template

The command reads AGENT_POLICY.template.md from the plugin’s templates directory to recall the full structure it should produce.
3

Briefly explore the project

Before asking you anything, the command takes a quick look at the project: top-level layout, build and deploy configuration, and any existing decision docs. It uses what it can infer from the repo to make better suggestions and to avoid asking about things it can already see.
4

Ask for what it cannot infer

The command asks concisely for the parts it genuinely cannot determine from the repo:
  • Which surfaces are client- or external-facing?
  • What counts as production, data, or infra for this project?
  • Which outward or irreversible actions matter here (push, deploy, send, charge)?
  • Where does the source of truth live, and where should decisions and state be recorded?
  • Any model-tier overrides or project-specific definitions you want to lock in?
5

Write the AGENT_POLICY.md

The command writes a filled-in AGENT_POLICY.md at the project root. It aims to be short and concrete — every hot zone is a real path or a real action, not a vague category.
6

Confirm before treating as authoritative

The command shows you the result and waits for confirmation before treating the file as the live policy. This is the moment to correct anything the exploration got wrong or that your answers didn’t capture precisely.

The generated file’s structure

The AGENT_POLICY.md produced by the command follows the structure defined in the Keel specification. It has six sections:
#SectionRequiredPurpose
1Hot zonesYesConcrete paths, surfaces, and actions that need a green light before the agent acts
2Source-of-truth filesYesFiles where only following-through on an existing decision runs without a new green light
3Where state and decisions get recordedYesDecisions log path, project-state file path, per-task notes convention
4Model tier overridesNoProject-specific overrides of the default model delegation tiers
5Definitions for this projectNoPin down what “undoable,” “internal,” “release,” etc. mean in this codebase
6Standing approvalsNoWritten decisions that grant a green light in advance for a defined scope — each must state that scope explicitly
The file also supports an optional keel-policy fenced block (inside the same file) for the machine-readable policy data that the PreToolUse enforcement hook reads directly. See Hooks for the block format.
Creating AGENT_POLICY.md is a low-impact, reversible action. But the content defines what the agent will treat as hot, so the command always shows you the result and asks for confirmation before treating it as authoritative.
For the full AGENT_POLICY.md reference — including how the machine-readable block works and how standing approvals carry over to following-through — see AGENT_POLICY.md Reference.

Build docs developers (and LLMs) love