One agent per model: control which skills load in Kilo

Build one agent per model and switch model, prompt, and skill policy in one keystroke.

A user asked in our Discord: can Kilo automatically enable or disable skills based on the model you’re using? For open-weight models like GLM5 or DeepSeek v4, a skill like superpowers adds real structure to multi-step work. For frontier models like GPT-5.6 or Fable 5, loading the same skill just burns context and slows them down.

There’s no per-model skill toggle in Kilo today. Skills load into one shared pool, and the agent decides which one to use based on each skill’s description. But there’s a setup that gets you the same result with one keystroke: custom agents. An agent bundles a model, a system prompt, and tool permissions into a single profile. Create one agent per model, give each a skill policy, and switching agents switches both at once.

How skills load

Quick recap of the mechanics, because they explain why this works:

1. On session start, Kilo scans your skill directories and reads only each skill’s metadata (name, description, path).

2. That metadata goes into the system prompt. This part is cheap — a few lines per skill.

3. When the agent decides a task matches a skill’s description, it calls the skill tool, which loads the full SKILL.md into context. This is the expensive part, and the part you want to control per model.

So there are two levers, both of which live on the agent:

• Prompt. The agent’s system prompt can tell the model when to reach for a skill and when to skip it.

• Permission. The skill tool obeys the same allow/ask/deny rules as bash or edit. Deny it and the full skill can’t load, no matter what the model decides.

The recipe

We’ll build two agents:

• deep-work — pinned to GLM 5.2, told to lean on superpowers for multi-step tasks.

• fable-lean — pinned to Fable 5, told to skip superpowers, with a permission rule that blocks it outright.

Switching between them is one action: the agent picker in VS Code, or Tab in the CLI. Model IDs below are examples — run kilo models (or open the model picker) to get the exact provider/model-id strings for your setup.

Build the agents in VS Code

Option A: ask Kilo

The fastest path. Paste this into the chat:

Create a new primary agent called "fable-lean".
Use the exact model ID "openai/gpt-5.6".
Its system prompt should instruct it to:
- Plan and execute multi-step work directly.
- Never load the "superpowers" skill, even if it becomes available.
- Load an available skill only when the task clearly matches its description.
Add a permission rule that denies the skill named "superpowers".
Save the agent as .kilo/agent/fable-lean.md using valid YAML
frontmatter.

Then the counterpart:

Create a new primary agent called "deep-work".
Use the exact model ID "kilo/z-ai/glm-5.2".
Its system prompt should instruct it to:
- For any multi-step implementation task, establish context and create
  a concrete task list before writing code.
- Execute the work step by step, keeping exactly one task in progress.
- Verify the result and persist until the task is complete.
- Load an available skill only when the task clearly matches its
  description.
- Never depend on an unavailable skill.
Save the agent as .kilo/agent/deep-work.md using valid YAML frontmatter.

Kilo writes the agent files into your project. Review them before committing, especially the complete provider/model IDs. Use the canonical .kilo/agent/ directory rather than .kilo/agents/.¹

Verify the resolved configurations:

kilo debug agent fable-lean

kilo debug agent deep-work

You can also confirm which skills Kilo actually discovered:

kilo debug skill

Option B: the Settings UI

Open Settings → Agent Behaviour → Agents. You can create and edit agents here: prompt, model, permissions, color. Changes land in the same config files the CLI reads.

Option C: write the files yourself

Agents are markdown files with YAML frontmatter. The filename becomes the agent name, and the markdown body becomes the system prompt. Put them in .kilo/agent/ for the project, or ~/.config/kilo/agent/ to make them available everywhere.

.kilo/agent/fable-lean.md:

---
description: Frontier-model profile. Fast, minimal skill loading.
mode: primary
model: openai/gpt-5.6
color: "#3B82F6"
permission:
  skill:
    "*": allow
    "superpowers": deny
---

You are the lean profile for frontier models.

Skill policy:
- Do not load the superpowers skill. Plan and execute multi-step work directly.
- Only load a skill when the task clearly matches its description and you
  can't proceed correctly without it.

.kilo/agents/deep-work.md:

---
description: Open-weight model profile. Uses structured workflows.
mode: primary
model: zai/glm-5
color: “#10B981”
---

You are the deep-work profile for open-weight models.

Skill policy:
- For any multi-step implementation task, load the superpowers skill first
  and follow its workflow before writing code.
- When a loaded skill matches the task, prefer it over improvising.

Start a new session (or /reload) and both agents show up in the picker.

Build the agents in the CLI

The CLI reads the same files, so anything you created above already works in the terminal. Three more ways to get there:

kilo agent create

Interactive:

kilo agent create

It asks where to save the agent, what it should do, generates a prompt, and lets you pick tools and the agent mode. Or skip the questions:

kilo agent create \
  --path .kilo \
  --description "Frontier-model profile, skips heavyweight skills" \
  --mode primary

Then open the generated file and add the model and permission fields from the examples above.

Edit kilo.jsonc

If you’d rather keep everything in one config file — project-level kilo.jsonc (or .kilo/kilo.jsonc), global ~/.config/kilo/kilo.jsonc:

{
  "$schema": "https://app.kilo.ai/config.json",
  "agent": {
    "fable-lean": {
      "description": "Frontier-model profile. Fast, minimal skill loading.",
      "mode": "primary",
      "model": "openai/gpt-5.6",
      "prompt": "{file:./prompts/fable-lean.md}",
      "permission": {
        "skill": { "*": "allow", "superpowers": "deny" }
      }
    },
    "deep-work": {
      "description": "Open-weight model profile. Uses structured workflows.",
      "mode": "primary",
      "model": "zai/glm-5",
      "prompt": "{file:./prompts/deep-work.md}"
    }
  }
}

The {file:./path} syntax keeps long prompts out of the JSON. Paths resolve relative to the config file, so it works in both global and project configs.

Soft steering vs. hard blocking

The prompt lever and the permission lever fail differently, so use both when it matters.

The prompt (”do not load superpowers”) is usually enough for a frontier model — that’s the whole premise, it doesn’t need the skill and won’t fight to load it. But it’s advisory. If you want a guarantee, the permission rule is the enforcement: “superpowers”: deny blocks that one skill’s tool call while leaving other skills loadable, and skill: deny blocks skill loading entirely for that agent. Permission rules are last-match-wins, so keep the “*” fallback first and the exception after it.

One honest caveat: denying the skill doesn’t remove its metadata from the system prompt. The name and description still appear — a few lines, not the multi-thousand-token instruction file. If you need a skill fully out of the prompt, keep it out of the shared directories and load it via skills.paths in your kilo.jsonc only for the projects that want it. That’s a per-project switch, not per-model, but it composes with the agent setup.

Verify it works

• Ask the agent directly: “What skills do you have available?” It answers from what’s actually loaded.

• Give deep-work a multi-step task and look for the skill tool call in the conversation — that’s the full skill loading.

• Give fable-lean the same task and confirm no skill call fires (or that it’s denied if the model tries).

• After editing skills or agent files, use /reload or start a new session.

1. Why .kilo/agent/ (singular), for two reasons:

1. When you ask Kilo to create an agent, it writes the file to .kilo/agent/ itself — what the tool generates is the best signal of the canonical path.

2. Kilo CLI is built on OpenCode, where agent/ singular is the original convention; the plural forms are compatibility aliases.