Rename KB export/summary/sync skills with ckb- prefix

Rename four cascade-KB skills to a consistent ckb- namespace:
- export-okf        -> ckb-export-okf
- export-starlight  -> ckb-export-starlight
- project-summary   -> ckb-project-summary
- sync-changes      -> ckb-sync-changes

Update the name: frontmatter in each SKILL.md and all cross-references
in README.md, AGENTS.md, cascade-kb-init, and export-starlight. Historical
wiki/log.md entries are left unchanged as a record of past actions.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

.agents/skills/cascade-kb-init/SKILL.md

@@ -60,8 +60,8 @@ The bare scaffold (directory structure + `AGENTS.md`/`CLAUDE.md` + empty
 `wiki/` templates) is always included, and so is the reusable KB skill set
 - these operate purely on the `wiki/` structure, so they carry over
 cleanly and are part of "the schema" as far as this skill is concerned:
-`export-okf`, `export-starlight`, `sync-changes`, `extract-transcript`,
-`project-summary`. Don't ask about these - just include them.
+`ckb-export-okf`, `ckb-export-starlight`, `ckb-sync-changes`, `extract-transcript`,
+`ckb-project-summary`. Don't ask about these - just include them.
 
 `ghost-writer` and `clouddrift-docx` are not part of the default set (a
 general writing tool and a brand-specific export skill respectively, not
@@ -132,7 +132,7 @@ same shape.
 ### Step 7 - Write `.gitignore`
 
 Base rules (always): `libs/`, `linked/`, `tmp/`, `.DS_Store`. Since
-`export-starlight` and `export-okf` are in the default skill set (Step 3),
+`ckb-export-starlight` and `ckb-export-okf` are in the default skill set (Step 3),
 also always add `outputs/starlight` and `outputs/okf` - both exist to be
 gitignored precisely because those two skills are present by default.
 

.agents/skills/ckb-export-okf/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: export-okf
+name: ckb-export-okf
 description: Export the local wiki/ knowledge base as an Open Knowledge Format (OKF) v0.1-conformant bundle at outputs/okf/, so any generic OKF tool can consume it. Use when the user asks to "export the wiki as OKF", "generate the OKF bundle", "export to OKF", "publish the OKF export", or "sync outputs/okf".
 ---
 

.agents/skills/ckb-export-starlight/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: export-starlight
+name: ckb-export-starlight
 description: Export the local wiki/ knowledge base into an Astro + Starlight-consumable form at outputs/starlight/, producing a human-readable documentation website. Use when the user asks to "export the wiki to Starlight", "generate the docs site", "export as Astro Starlight", "build a human-readable wiki site", or "publish the knowledge base as a website".
 ---
 
@@ -10,7 +10,7 @@ description: Export the local wiki/ knowledge base into an Astro + Starlight-con
 Regenerate `outputs/starlight/` from the current `wiki/` tree so it can be
 built and served as an Astro + Starlight documentation website — a
 human-readable, browsable version of this knowledge base (unlike
-`export-okf`, which targets machine/tool consumption). This is a one-way,
+`ckb-export-okf`, which targets machine/tool consumption). This is a one-way,
 on-demand export — `wiki/` stays the authoritative source; `outputs/starlight/`
 is always a derived artifact of it, never edited by hand and never fed back
 in.
@@ -143,5 +143,5 @@ The script prints, and you should summarize back to the user:
 - **A wiki page with no `tldr`:** `description` is simply omitted from
   that page's frontmatter — Starlight tolerates a missing description.
 - **A wiki page with no H1:** falls back to a slugified filename as the
-  title (e.g. `foo-bar.md` → "Foo Bar"), same fallback rule `export-okf`
+  title (e.g. `foo-bar.md` → "Foo Bar"), same fallback rule `ckb-export-okf`
   uses.

.agents/skills/ckb-project-summary/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: project-summary
+name: ckb-project-summary
 description: Generate or refresh a one-to-two-page project overview at the repo root, synthesized entirely from the current wiki/ contents — overview paragraph, project state, actions and their status, risks, and assumptions. Use when the user asks for "a project summary", "project overview", "give me the state of the project", "where do things stand", "summarize the project", or wants a quick top-level snapshot without reading the whole wiki.
 ---
 

.agents/skills/ckb-sync-changes/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: sync-changes
+name: ckb-sync-changes
 description: Reconcile this repo's git history with its origin remote — pull down remote commits, commit any local working-tree changes, resolve any conflicts with the user, then push. Use when the user asks to "sync changes", "sync with git", "sync with the remote", "sync with origin", "push and pull my changes", "reconcile git", or "sync the repo". This is a git-level operation, distinct from the content-level "Sync the wiki" / "Ingest" workflow in CLAUDE.md, which processes raw/inbox/ into structured wiki/ pages.
 ---
 
@@ -17,7 +17,7 @@ content, and never tries to semantically reconcile markdown or frontmatter —
 a conflicted file is just text with conflict markers until the user says
 otherwise.
 
-Unlike the `export-okf` skill, this skill **does** commit and push on its
+Unlike the `ckb-export-okf` skill, this skill **does** commit and push on its
 own once conflicts (if any) are resolved — that automation was explicitly
 requested for this skill.
 

AGENTS.md

@@ -115,7 +115,7 @@ retention: high|medium|low # How aggressively to deprioritize when old
 
 ## 3. INGESTION WORKFLOW (TRIGGERED ON DEMAND)
 
-When the user says "Ingest", "Sync the wiki", or "Update the Wiki" (for syncing this repo's own git history with its remote, see the sync-changes skill under `.claude/skills/` instead):
+When the user says "Ingest", "Sync the wiki", or "Update the Wiki" (for syncing this repo's own git history with its remote, see the ckb-sync-changes skill under `.claude/skills/` instead):
 
 1. **Process Inbox:** Scan `raw/inbox/` for new material. After ingesting, move each processed item to `raw/archive/<YYYY-MM-DD>/`, where the date is today's ingestion date (create the dated folder if it doesn't exist yet). If `raw/inbox/` is empty, scan `raw/` directly (excluding `raw/archive/`, which holds already-processed material).
 

README.md

@@ -180,7 +180,7 @@ v0.1-conformant bundle at `outputs/okf/`, consumable by any generic OKF tool
 (e.g. Google's reference graph visualizer) without disturbing the richer
 internal schema (`confidence`/`quality`/`retention`/`supersedes`/dual-linking)
 that OKF doesn't natively understand. Implemented as a Claude Code Skill —
-see `.claude/skills/export-okf/SKILL.md` — rather than baked into
+see `.claude/skills/ckb-export-okf/SKILL.md` — rather than baked into
 `CLAUDE.md`/`AGENTS.md`, so the mapping ruleset only loads into context when
 actually invoked.
 
@@ -190,7 +190,7 @@ demand: local changes get committed, remote changes get pulled and merged,
 any conflicts are presented to the user file-by-file to resolve, then the
 result is pushed automatically. Say "sync changes" to trigger it. Also
 implemented as a Claude Code Skill — see
-`.claude/skills/sync-changes/SKILL.md` — and deliberately distinct from the
+`.claude/skills/ckb-sync-changes/SKILL.md` — and deliberately distinct from the
 content-level "Sync the wiki" / "Ingest" workflow, which processes
 `raw/inbox/` into structured `wiki/` pages and has nothing to do with git.