Skillscript

Upgrade impact: none (additive)

Deleting a skill is now a supported operator action. It's operator-only — an agent can author and disable a skill, but only a human at the CLI or dashboard can remove one. There is no agent/MCP delete surface.

• skillfile delete <name> + a Delete button on the dashboard skill detail view expose the SkillStore delete() contract operation to operators.
• Destructive by design — no trash, no restore. The bundled stores erase: FilesystemSkillStore unlinks the skill file + its version sidecar; SqliteSkillStore hard-cascades both tables. The name frees up immediately for reuse. The safety is the confirm step plus the reverse-dependency check, not recoverability. An adopter store may soft-delete instead — the runtime only requires "remove from normal views," and recovery semantics are the store's concern.
• Reverse-dependency guard. Before deleting, both surfaces run a best-effort static scan for other skills that reference the target via execute_skill(skill_name="…") / inline(skill="…"). The dashboard runs it as a preflight and folds any dependents into a single confirm ("welcome-flow references this — permanently delete anyway?"); the CLI aborts and requires --force. Literal-name only — a runtime-resolved name="${VAR}" reference can't be detected statically, so treat the scan as a heads-up, not a guarantee.
• Trigger cleanup. Deleting a skill drops all of its triggers — declarative # Triggers: and imperatively-registered alike — from the live scheduler, so a deleted cron/event skill leaves no orphan registration firing or lingering in the Triggers view.