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.

This example shows the core value of Keel Skills in a single scenario — the same agent, the same prompt, the only difference being whether the authorization-protocol skill is active. It is the fastest way to see why “go do it” and “you have permission to do it” are not the same thing.

​
The Prompt

“The repo’s gotten messy, clean it up and push so the build is green again.”
This is a goal — it names an outcome, not a scoped action. It feels like permission to do whatever’s needed. It is not — it’s not a green light.

​
Without Keel ❌

The agent reads “clean it up and push” as approval and acts immediately. No check, no pause, no proposal.
git rm -r legacy/ old-tests/        # "messy" → deletes them
git add -A
git commit -m "chore: clean up repo"
git push --force origin main        # "so the build is green" → force-push
Three undoable, outward actions taken under an instruction that never scoped any of them. The --force overwrote a colleague’s commit. legacy/ had one file that was still imported. The build is green because half of it is gone.

​
With Keel ✅

The authorization-protocol skill runs the four-step check before each action. 
Step 1 — read-only / proposal?  No, these write and push.
Step 2 — risky (hot) zone?      YES. git push, force-push, and deleting files
                                are outward / undoable-only-with-pain actions.
        → Needs a green light. The instruction was a goal, not a green light. STOP.
The agent does not act. Instead it comes back with a scoped proposal: 
This is a goal, not a green light, and "clean up + push" touches risky zones
(deleting files, push, force-push). I won't run those without a clear yes.

Here's what I'd do — approve the parts you want (that's your green light):

  [PROPOSAL]
  1. Delete `old-tests/` (12 files, 0 imports found)        — undoable until push
  2. Delete `legacy/`  ⚠ `legacy/dates.ts` is imported by `src/lib/x.ts`
                          → I'd keep this one; flag instead of delete
  3. Commit the deletions on a branch
  4. push (NOT force) to `main`                              — outward, needs your yes

I will not force-push: it would overwrite commit a1b2c3d (not yours).

Which of 1–4 do you approve?
You approve 1, 3, and a normal (non-force) push. The agent does exactly that — nothing more. legacy/ is preserved, your colleague’s commit survives, and you found out about the broken import before it shipped.

​
Why This Is the Product

The difference isn’t intelligence — both agents are the same model. The difference is a written rule about when to stop:
  • “clean it up and push” is a goal → investigate and propose, don’t act.
  • push / force-push / delete are risky → need a green light.
  • Doubt about whether legacy/ is safe to delete → surface it, don’t guess.
Keel Skills is that rule, shipped. The specifics of what’s risky in your repo live in your AGENT_POLICY.md; the model that decides is specified in SPEC.md. For the counterpart that shows the hard brake — the PreToolUse hook stopping actions at the infrastructure level regardless of what the model decided — see the Enforcement Hook example.

Build docs developers (and LLMs) love

Get started for freeTalk to us