--- name: ckb-init description: Bootstrap a brand-new Cascade Knowledge Base - the same directory structure, AGENTS.md/CLAUDE.md system prompt, and empty wiki/ scaffold as this project - inside a target folder (typically empty, or a new project that doesn't have one yet). Use when the user asks to "set up a new wiki like this one", "initialize a new cascade KB", "bootstrap a wiki here", "create a knowledge base with this schema", or calls it a "wiki initializer". Do not confuse with a generic `init` skill that documents an existing codebase - this one creates the Cascade KB pattern itself, empty, ready for its first ingest. --- # Cascade KB init skill ## Purpose Copy this project's Cascade Knowledge Base *schema* - not its content - into a new target folder: the directory structure, the `AGENTS.md`/`CLAUDE.md` system prompt that defines how the KB behaves, and the empty `wiki/` scaffold (routing table, overview, log, error book, entity/graph indexes). The result is a new, empty KB that behaves exactly like this one, ready for its first `raw/inbox/` drop and "Ingest." This is a one-way copy from this repo's own `AGENTS.md`/`wiki/` template files into a different folder. It never reads or writes anything in this repo's `raw/`, `wiki/entities/`, `wiki/graph/edges.json`, or `outputs/` - those hold this project's actual accumulated knowledge, which is exactly what should *not* travel into a fresh KB. ## Trigger phrases - "set up a new wiki like this one" / "initialize a new cascade KB" - "bootstrap a wiki here" / "create a knowledge base with this schema" - "wiki initializer" / "clone this KB structure into a new project" ## How to run this skill ### Step 1 - Confirm the target folder Ask (if not already given): "Which folder should I initialize the new knowledge base in?" Resolve to an absolute path. This is a filesystem action outside the current repo, so confirm the resolved path back to the user before writing anything - do not assume a relative path means "somewhere under the current project." If the folder doesn't exist yet, create it after confirming the path. If it exists, check its contents before doing anything else (Step 2). ### Step 2 - Don't clobber an existing KB or unrelated project If the target already contains a `wiki/` directory, or an `AGENTS.md` / `CLAUDE.md`, stop and ask: "This folder already looks like it has a knowledge base (found ``). Initializing here could overwrite it. Do you want to proceed anyway, pick a different folder, or only add whatever scaffold pieces are missing?" Never silently overwrite an existing `AGENTS.md` or populated `wiki/` tree. If the target has other, unrelated files (e.g. it's an existing code project without a KB yet) - that's fine, proceed; the scaffold is added alongside them. Note any top-level name collisions (e.g. an existing `wiki/` folder used for something else) and ask before touching those specifically. ### Step 3 - Default skill set (no need to ask) 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: `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 KB-schema-native) - only include either if the user explicitly asks for it, e.g. "also bring over ghost-writer." Record the final skill list (default five, plus anything explicitly added) - this affects Steps 6 and 7. ### Step 4 - Create the directory structure Under the target folder, create: ``` libs/ linked/ outputs/ raw/inbox/ raw/archive/ tmp/ wiki/entities/ wiki/graph/ workload/ ``` `libs/`, `linked/`, and `tmp/` are gitignored per the schema (Step 6) and stay empty. `raw/inbox/`, `raw/archive/`, and `workload/` are meant to be tracked but start empty - add a placeholder `.gitkeep` file to each so they survive a fresh `git init` + first commit rather than vanishing as empty directories. ### Step 5 - Write `AGENTS.md` and the `CLAUDE.md` symlink Copy this repo's `AGENTS.md` verbatim into the target as `AGENTS.md` - it is already fully generic (no project-specific content; it *is* the schema definition). Then create `CLAUDE.md` in the target as a symlink to `AGENTS.md`, matching this repo's own convention (one source of truth, readable under either filename). ### Step 6 - Write the empty `wiki/` scaffold Create these files in the target, using this repo's current versions as the template and stripping every reference to this project's actual content (Grant Thornton, Cloud Drift, specific entities, etc.) down to the generic structure: - **`wiki/index.md`** - frontmatter with `kb_schema_version: "1.1"` only. Body: the routing table with just its four fixed infrastructure rows (Overview, Log, Error Book, Entities, Graph) and no entity rows, plus the "## Entity Pages" section with its placeholder note. Use today's date where the template needs one. - **`wiki/overview.md`** - copy verbatim from this repo (it's already generic - directory tree, cascade priority, frontmatter summary, no project content). Set `last_updated` to today. - **`wiki/log.md`** - header and explanation only, no entries. - **`wiki/error-book.md`** - copy verbatim (already generic: empty table + placeholder note). Set `last_updated` to today. - **`wiki/entities/index.md`** - header + placeholder note, no entries. - **`wiki/graph/index.md`** - header + pointer to `edges.json`, with a generic "Current graph coverage: (none yet)" line instead of this repo's specific bullet list. - **`wiki/graph/edges.json`** - `{"version": 1, "last_updated": "", "edges": []}`. Do not carry over any entity pages, graph edges, log entries, or overview content specific to this project - the whole point is an empty KB with the same shape. ### Step 7 - Write `.gitignore` Base rules (always): `libs/`, `linked/`, `tmp/`, `.DS_Store`. Since `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. ### Step 8 - Copy the skill set from Step 3 Copy each skill's folder from this repo's `.agents/skills//` into the target's `.agents/skills//` unchanged - the default five, plus anything explicitly added. Then create `.claude/skills` in the target as a symlink to `../.agents/skills`, matching this repo's convention - do this once, after copying the whole set, not per-skill. ### Step 9 - Report Tell the user: - The resolved target path. - The directory tree created. - Whether `AGENTS.md`/`CLAUDE.md` were written or (per Step 2) skipped/merged. - Which skills were copied (the default five, plus anything explicitly added). - Next step: "Drop material into `raw/inbox/` and say 'Ingest' to populate the wiki for the first time." ## Edge cases - **Target is the current repo itself, or a parent/ancestor of it** - refuse and explain why: this would either overwrite the live KB you're running from, or nest a KB inside itself. Ask for a genuinely separate path. - **Target is on a different filesystem/drive or requires elevated permissions** - if directory creation fails, report the exact error rather than retrying with escalated permissions. - **User wants only *some* of the wiki template files** (e.g. just the directory structure, no `AGENTS.md`) - honor that; the steps above are the default full scaffold, not an all-or-nothing bundle. - **This repo's own `AGENTS.md` or template `wiki/` files have since drifted from each other** (e.g. one mentions a directory the other doesn't) - fix the drift in *this* repo first if noticed, then copy the corrected version. Don't propagate a known inconsistency into a new KB.