Skip to main content

Skill Settings

This page lists every config key that controls skill and skill-pack on/off state, skill-pack registration, and the SageOx and Deft integrations. For the on/off model itself, see Skills and Skill Packs. For what makes a repository a valid pack, see Authoring a skill pack. No schema validates any of these keys — each reader parses its own file by hand, and a malformed value is simply ignored rather than rejected. Prefer the CLI (pan skills set, pan skills pack …) to hand-editing these files; a hand edit that breaks the YAML is read as if the file were empty for most reads, silently — pan skills set against a broken global config.yaml is the exception and exits 1 with cannot parse <path>.

Where settings live

Precedence, narrowest first: conversation > issue > project > global > default. A native skill with no value anywhere defaults to on. A pack skill with no value anywhere defaults to off. See Turning skills on and off for the full resolution walk-through, including pack skills.

skills.packs.<id> (global)

The pack registry, in ~/.overdeck/config.yaml:
A malformed entry is ignored, and a config.yaml that fails to parse yields no packs at all. pan skills pack sync re-fetches a pack but never moves its commit.

skills.pack_overrides and skills.overrides (global)

skills.pack_overrides.<id>: true turns a pack on globally; it is two-state, so off is stored as no key at all. skills.overrides.<skill>: false turns a skill off globally; on is stored as no key. A <pack>/<skill> key under overrides stores only a difference from that skill’s resting state (on by default, or off when it is opt-in). Core skills cannot be set at any level. Writers: pan skills set and the dashboard (PUT /api/skills/overrides).

Project keys (~/.overdeck/projects.yaml, under projects.<key>)

The issue file

<planHome>/.pan/skill-overrides/<ISSUE>.yaml:
Every write is committed in the plan home on its checked-out branch (normally main) as chore(workspace): skill overrides for <ISSUE> (or chore(workspace): pipeline for <ISSUE>) and pushed to that branch’s upstream. When the push fails, the commit stays local and pan skills set prints push pending: <reason>. An issue file whose YAML fails to parse is read as empty, and the next pan skills set --issue rewrites the whole file with only the new value — it does not merge with whatever was unparseable. That is the current behavior; a follow-up issue tracks fixing it. Writers: pan skills set … --issue, the dashboard, and pan skills deft use|back.