local_skill_managementlisted

# local_skill_management — fork-specific skills that survive Fork-specific skills live in the DB and persist via `.sc-state/content.sql` (the snapshot). The asset file under `.super-coder/assets/skills/<name>/` is the **authoring source only** — it sits in gitignored engine territory, and that is safe: the engine/local boundary is the seed migration (0001, upstream-owned in a fork), not asset-file presence. The snapshot serializes your skill to content.sql whether or not the asset file is kept, and `sc update` neither manifests it nor heals over its DB row. **content.sql = the durable form; the asset file = your editor.** The path: **file -> seed -> grant -> snapshot -> commit**. ## Creating a fork-specific skill 1. **Write the skill file** at `.super-coder/assets/skills/<name>/SKILL.md`. Required frontmatter: ```yaml --- name: skill_name description: One-line summary — shown in boot, catalogue, and the GUI Skills tab category: substrate # or craft; omit for default --- ``` Body: markdown procedure the shell will follow. Imperative, compressed — this boots into context. 2. **Seed into the live DB:** ```bash sc seed-skills ``` UPSERTs every asset skill by name (id-stable) and reports what landed. In a fork it deliberately does NOT regenerate the seed migration — that file is upstream-owned engine territory. DB skills with no asset file = other local skills, left intact. 3. **Grant to the target pack** — name a shell b