docs/solutions/workflow-issues/2026-03-28-skiller-requires-canonical-agent-ids-in-skiller-toml.md
The repo's root prepare script runs bun x skiller@latest apply. That started failing because .claude/skiller.toml still used the old Claude agent id claude.
That broke any workflow that relied on a normal install, including the Next upgrade flow.
skiller hard-cut its public config surface to canonical agent ids. claude is no longer accepted; claude-code is the valid id.
The important wrinkle: the generated .claude/.skiller.json can still contain sourceType: "claude" for project-managed items. That internal metadata is not the config surface skiller validates on startup.
Update .claude/skiller.toml to use canonical ids only:
default_agents = ["claude-code", "codex"]
[agents.claude-code]
enabled = true
Do not patch .claude/.skiller.json by hand. It is generated state, not source of truth.
After the config change, rerun:
bun x skiller@latest apply
skiller validates default_agents and [agents.<id>] against its canonical agent catalog before applying anything else.
Once skiller.toml uses claude-code, the config matches the catalog and apply succeeds. The generated .skiller.json does not block the run because it tracks synced items, not the validated agent config surface.
.claude/skiller.toml as the only source of truth for agent ids.skiller rejects an agent name, check the current skiller docs or changelog before touching generated files.bun x skiller@latest apply starts failing during install, rerun it directly first. The error message is specific enough to point at the broken id.