---
name: capabilities-manage
description: |
  Kode capability-management playbook: treat features (LSP, statusline, output styles, plugins, notifications) as configurable capabilities and drive changes through the agent CLI (SlashCommand/Task) instead of pushing users into menu-like flows. Use when the user asks to enable/disable/configure a capability, diagnose why it’s off, or wants the agent to self-manage Kode’s own features (meta capability management).
allowed-tools: SlashCommand Read Edit Task Skill
---

# Capabilities Manage

## Goal

Make users manage Kode features by expressing intent (“enable LSP for TS”, “fix my statusline”) while the agent performs the necessary actions via the agent CLI.

## Rules (do not violate)

- Do not output “installation menu” scripts or long lists of install commands.
- Prefer `SlashCommand` to run Kode commands (`/statusline`, `/lsp`, `/plugin ...`) instead of asking the user to do it manually.
- Keep changes minimal and reversible; verify after each change.

## Workflow

1. Clarify which capability: `statusline` / `lsp` / `output-style` / `plugins` (or multiple).
2. Inspect current state with minimal friction:
   - Read settings files (`~/.kode/settings.json`, `.kode/settings.local.json`).
   - For interactive status screens, ask the user to open them (single step): `/lsp`, `/output-style`.
3. Apply changes:
   - statusline: create a Task with subagent_type `statusline-setup` (do not ask the user to memorize the command).
   - lsp: ensure a plugin provides `.lsp.json` mappings; manage via `/plugin`, then re-check via `/lsp` screen.
   - output styles: set `outputStyle` in settings (or ask the user to choose via `/output-style`); for edits, edit the output style markdown file and then re-check `/output-style`.
4. Verify: re-check status screens and run a minimal real operation.

## Capabilities audit (recommended for `/capabilities`)

Keep this fast and low-friction: default output should be a short checklist and only one question when a choice is required.

1. Read current settings (best effort):
   - `~/.kode/settings.json` (global)
   - `.kode/settings.local.json` (project, if present)
2. Produce a compact checklist (OK / Needs attention) for:
   - Statusline: global `settings.json` contains `statusLine`.
   - Output style: either settings file contains a non-empty `outputStyle` string.
   - Plugins & LSP readiness: mention that LSP is plugin-driven; if the user cares, ask them to open `/lsp` (single step) to confirm resolved servers.
   - Permission friction: if the user reports unexpected denials/repeated prompts, invoke the `permissions-debug` skill.
3. Auto-fix what you can safely:
   - Statusline: if requested, create a Task with subagent_type `statusline-setup` (do not ask the user to memorize the command).
   - Output style: set `outputStyle` in `.kode/settings.local.json` (project) or `~/.kode/settings.json` (global) and re-read to verify.
4. Verify each fix immediately by re-reading the changed file(s) and summarizing what changed.