@inkeep/open-knowledge 0.49.0-beta.9 → 0.49.0

package/dist/THIRD_PARTY_NOTICES.md

@@ -1976,6 +1976,41 @@ Homepage: https://ui.shadcn.com
 
 Copyright (c) 2023 shadcn
 
+### `@shikijs/core@3.23.0`
+Homepage: https://github.com/shikijs/shiki#readme
+
+Copyright (c) 2021 Pine Wu Copyright (c) 2023 Anthony Fu <https://github.com/antfu>
+
+### `@shikijs/engine-javascript@3.23.0`
+Homepage: https://github.com/shikijs/shiki#readme
+
+Copyright (c) 2021 Pine Wu Copyright (c) 2023 Anthony Fu <https://github.com/antfu>
+
+### `@shikijs/engine-oniguruma@3.23.0`
+Homepage: https://github.com/shikijs/shiki#readme
+
+Copyright (c) 2021 Pine Wu Copyright (c) 2023 Anthony Fu <https://github.com/antfu>
+
+### `@shikijs/langs@3.23.0`
+Homepage: https://github.com/shikijs/shiki#readme
+
+Copyright (c) 2021 Pine Wu Copyright (c) 2023 Anthony Fu <https://github.com/antfu>
+
+### `@shikijs/themes@3.23.0`
+Homepage: https://github.com/shikijs/shiki#readme
+
+Copyright (c) 2021 Pine Wu Copyright (c) 2023 Anthony Fu <https://github.com/antfu>
+
+### `@shikijs/types@3.23.0`
+Homepage: https://github.com/shikijs/shiki#readme
+
+Copyright (c) 2021 Pine Wu Copyright (c) 2023 Anthony Fu <https://github.com/antfu>
+
+### `@shikijs/vscode-textmate@10.0.2`
+Homepage: https://github.com/shikijs/vscode-textmate
+
+Copyright (c) Microsoft Corporation
+
 ### `@simple-git/args-pathspec@1.0.3`
 Homepage: https://github.com/steveukx/git-js
 
@@ -4451,6 +4486,16 @@ Homepage: https://github.com/sindresorhus/onetime
 
 Copyright (c) Sindre Sorhus <sindresorhus@gmail.com> (https://sindresorhus.com)
 
+### `oniguruma-parser@0.12.2`
+Homepage: https://github.com/slevithan/oniguruma-parser
+
+Copyright (c) 2025-2026 Steven Levithan
+
+### `oniguruma-to-es@4.3.6`
+Homepage: https://github.com/slevithan/oniguruma-to-es
+
+Copyright (c) 2024-2026 Steven Levithan
+
 ### `open@11.0.0`
 Homepage: https://github.com/sindresorhus/open
 
@@ -4902,6 +4947,21 @@ Homepage: http://github.com/benjamn/recast
 
 Copyright (c) 2012 Ben Newman <bn@cs.stanford.edu>
 
+### `regex@6.1.0`
+Homepage: https://github.com/slevithan/regex
+
+Copyright (c) 2025 Steven Levithan
+
+### `regex-recursion@6.0.2`
+Homepage: https://github.com/slevithan/regex-recursion
+
+Copyright (c) 2025 Steven Levithan
+
+### `regex-utilities@2.3.0`
+Homepage: https://github.com/slevithan/regex-utilities
+
+Copyright (c) 2024 Steven Levithan
+
 ### `rehype-harden@1.1.8`
 Homepage: https://github.com/vercel-labs/markdown-sanitizers#readme
 
@@ -5092,6 +5152,11 @@ Homepage: https://github.com/ljharb/shell-quote
 
 Copyright (c) 2013 James Halliday (mail@substack.net)
 
+### `shiki@3.23.0`
+Homepage: https://github.com/shikijs/shiki#readme
+
+Copyright (c) 2021 Pine Wu Copyright (c) 2023 Anthony Fu <https://github.com/antfu>
+
 ### `side-channel@1.1.1`
 Homepage: https://github.com/ljharb/side-channel#readme
 

package/dist/{acp-harness-probe-DAvWLUO9.mjs → acp-harness-probe-DOXp9Wx4.mjs}

@@ -1,3 +1,3 @@
-import{Y as e}from"./sleep-ByqzSHar.mjs";import{h as t,s as n,v as r}from"./write-project-skill-CbLmhWjs.mjs";import{d as i}from"./init-DH-Px80S.mjs";import{execFileSync as a}from"node:child_process";import{dirname as o,join as s}from"node:path";import{existsSync as c,mkdirSync as l,readFileSync as u,writeFileSync as d}from"node:fs";import{homedir as f}from"node:os";var p=e();const m=`open-knowledge`;function h(e){try{e()}catch{}}var g=class{backend=`keyring`;constructor(e){this.onKeychainRead=e}async get(e){let{Entry:t}=await import(`@napi-rs/keyring`),n;try{n=new t(m,e).getPassword()}catch(t){return h(()=>this.onKeychainRead?.({kind:`read-error`,host:e,error:t instanceof Error?t.name:`unknown`})),null}if(n==null)return h(()=>this.onKeychainRead?.({kind:`absent`,host:e})),null;try{return JSON.parse(n)}catch{return h(()=>this.onKeychainRead?.({kind:`corrupt-entry`,host:e,error:`corrupt-entry`})),null}}async set(e,t,n,r){let{Entry:i}=await import(`@napi-rs/keyring`),a=new i(m,e),o={login:t,token:n,...r};a.setPassword(JSON.stringify(o))}async clear(e){let{Entry:t}=await import(`@napi-rs/keyring`);try{new t(m,e).deletePassword()}catch{}}},_=class{backend=`file`;authFile;constructor(e){this.authFile=e??s(f(),`.ok`,`auth.yml`)}read(){if(!c(this.authFile))return{};try{return(0,p.parse)(u(this.authFile,`utf-8`))??{}}catch(e){let t=e instanceof Error?e.message:`unknown error`;return process.stderr.write(`[auth] Failed to parse ${this.authFile}: ${t}. Starting with empty credentials.\n`),{}}}write(e){let t=o(this.authFile);c(t)||l(t,{recursive:!0,mode:448}),d(this.authFile,(0,p.stringify)(e),{mode:384})}async get(e){return this.read()[e]??null}async set(e,t,n,r){let i=this.read();i[e]={login:t,token:n,...r},this.write(i)}async clear(e){let t=this.read();delete t[e],this.write(t)}},v=class{backend=`keyring`;constructor(e,t){this.keychain=e,this.file=t}async get(e){let t=await this.keychain.get(e);if(t!=null)return t;let n=await this.file.get(e);if(n==null)return null;try{await this.keychain.set(e,n.login,n.token,{gitProtocol:n.gitProtocol,name:n.name,email:n.email}),await this.file.clear(e),process.stderr.write(`[auth] migrated ${e} credential from ~/.ok/auth.yml to the OS keychain\n`)}catch{}return n}set(e,t,n,r){return this.keychain.set(e,t,n,r)}async clear(e){await this.keychain.clear(e),await this.file.get(e)!=null&&await this.file.clear(e)}};async function y(e,t){try{let{Entry:n}=await import(`@napi-rs/keyring`);return new n(m,`__probe__`),process.stderr.write(`[auth] token storage: OS keychain
+import{Y as e}from"./sleep-DVOInM4H.mjs";import{h as t,s as n,v as r}from"./write-project-skill-WXZSbQlg.mjs";import{d as i}from"./init-ZOWQ1Th4.mjs";import{execFileSync as a}from"node:child_process";import{dirname as o,join as s}from"node:path";import{existsSync as c,mkdirSync as l,readFileSync as u,writeFileSync as d}from"node:fs";import{homedir as f}from"node:os";var p=e();const m=`open-knowledge`;function h(e){try{e()}catch{}}var g=class{backend=`keyring`;constructor(e){this.onKeychainRead=e}async get(e){let{Entry:t}=await import(`@napi-rs/keyring`),n;try{n=new t(m,e).getPassword()}catch(t){return h(()=>this.onKeychainRead?.({kind:`read-error`,host:e,error:t instanceof Error?t.name:`unknown`})),null}if(n==null)return h(()=>this.onKeychainRead?.({kind:`absent`,host:e})),null;try{return JSON.parse(n)}catch{return h(()=>this.onKeychainRead?.({kind:`corrupt-entry`,host:e,error:`corrupt-entry`})),null}}async set(e,t,n,r){let{Entry:i}=await import(`@napi-rs/keyring`),a=new i(m,e),o={login:t,token:n,...r};a.setPassword(JSON.stringify(o))}async clear(e){let{Entry:t}=await import(`@napi-rs/keyring`);try{new t(m,e).deletePassword()}catch{}}},_=class{backend=`file`;authFile;constructor(e){this.authFile=e??s(f(),`.ok`,`auth.yml`)}read(){if(!c(this.authFile))return{};try{return(0,p.parse)(u(this.authFile,`utf-8`))??{}}catch(e){let t=e instanceof Error?e.message:`unknown error`;return process.stderr.write(`[auth] Failed to parse ${this.authFile}: ${t}. Starting with empty credentials.\n`),{}}}write(e){let t=o(this.authFile);c(t)||l(t,{recursive:!0,mode:448}),d(this.authFile,(0,p.stringify)(e),{mode:384})}async get(e){return this.read()[e]??null}async set(e,t,n,r){let i=this.read();i[e]={login:t,token:n,...r},this.write(i)}async clear(e){let t=this.read();delete t[e],this.write(t)}},v=class{backend=`keyring`;constructor(e,t){this.keychain=e,this.file=t}async get(e){let t=await this.keychain.get(e);if(t!=null)return t;let n=await this.file.get(e);if(n==null)return null;try{await this.keychain.set(e,n.login,n.token,{gitProtocol:n.gitProtocol,name:n.name,email:n.email}),await this.file.clear(e),process.stderr.write(`[auth] migrated ${e} credential from ~/.ok/auth.yml to the OS keychain\n`)}catch{}return n}set(e,t,n,r){return this.keychain.set(e,t,n,r)}async clear(e){await this.keychain.clear(e),await this.file.get(e)!=null&&await this.file.clear(e)}};async function y(e,t){try{let{Entry:n}=await import(`@napi-rs/keyring`);return new n(m,`__probe__`),process.stderr.write(`[auth] token storage: OS keychain
 `),h(()=>t?.onBackendSelected?.({backend:`keyring`})),new v(new g(t?.onKeychainRead),new _(e))}catch(n){let r=n instanceof Error?`${n.name}: ${n.message}`:String(n);return process.stderr.write(`[auth] token storage: file (~/.ok/auth.yml) — OS keychain unavailable: ${r}\n`),h(()=>t?.onBackendSelected?.({backend:`file`,reason:r})),new _(e)}}function b(e){let t=null;return function(){if(t)return t;let n=2e3;return t=(async()=>{let t=null,r=new Promise(r=>{t=setTimeout(()=>{process.stderr.write(`[auth] token storage: keyring init exceeded ${n}ms; falling back to file (~/.ok/auth.yml)\n`),r(new _(e))},n)});try{return await Promise.race([y(e),r])}catch{return new _(e)}finally{t!==null&&clearTimeout(t)}})(),t}}function x(e){let t=b(e);return{async get(e){let n=await(await t()).get(e);return n===null?null:{token:n.token}}}}function S(e){let t=b(e);return{backend:`file`,async get(e){return(await t()).get(e)},async set(e,n,r,i){return(await t()).set(e,n,r,i)},async clear(e){return(await t()).clear(e)}}}async function C(e,t){let n=[],r=new _(t);await r.get(e)!=null&&(await r.clear(e),n.push(`file`));let i;try{let{Entry:t}=await import(`@napi-rs/keyring`);new t(m,`__probe__`);let r,a=await new g(e=>{e.kind===`read-error`&&(r=e.error??`read-error`)}).get(e);if(r!==void 0)i=r;else if(a!=null)try{new t(m,e).deletePassword(),n.push(`keychain`)}catch(e){i=e instanceof Error?e.name:`delete-error`}}catch{}return{touched:n,keychainError:i}}const w=[`/opt/homebrew/bin/gh`,`/usr/local/bin/gh`,`/opt/local/bin/gh`,`/snap/bin/gh`,`/usr/bin/gh`],T={encoding:`utf-8`,stdio:[`ignore`,`pipe`,`pipe`],timeout:5e3,windowsHide:!0};function E(e,t={}){let n=t._exec??a,r=t._fileExists??c,i=[`auth`,`token`,...e?[`--hostname`,e]:[]],o=[`gh`,...w.filter(r)];for(let e of o)try{let t=n(e,i,T).toString().trim();if(t.length>0)return{available:!0,token:t}}catch{}return{available:!1}}function D(e,a,o){let s=n[e],c=e===`opencode`?r:t,l=[],u=s.projectConfigPath?.(a);u!==void 0&&l.push({scope:`project`,configPath:u});try{l.push({scope:`user`,configPath:s.configPath(a,o)})}catch{}for(let t of l){let n=i(s,a,o,t.configPath);if(n!==null&&c(n))return{editorId:e,scope:t.scope,configPath:t.configPath}}return null}export{x as a,y as i,E as n,S as o,C as r,D as t};
-//# sourceMappingURL=acp-harness-probe-DAvWLUO9.mjs.map
+//# sourceMappingURL=acp-harness-probe-DOXp9Wx4.mjs.map

package/dist/assets/skills/packs/codebase-wiki/SKILL.md

@@ -11,7 +11,7 @@ metadata:
 
 This project holds an **agent-authored wiki of a codebase** — DeepWiki, but living in the repo. A coding agent reads the source and writes a navigable, diagram-rich, source-grounded wiki as markdown under `wiki/`. It is version-controlled and diffable, private by default, human+agent co-editable, renders in OK's live preview, and doubles as durable grounding context for future agent sessions. There is no separate Q&A surface — Q&A is "the OK-grounded agent + `search`".
 
-> This skill is pack guidance. The platform `open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers the wiki workflow on top.
+> This skill is pack guidance. The platform `/open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers the wiki workflow on top.
 
 ## The shape
 

package/dist/assets/skills/packs/entity-vault/SKILL.md

@@ -11,7 +11,7 @@ metadata:
 
 A Personal CRM built as a typed-entity vault, inspired by Garry Tan's gbrain. Each entity is a dossier; the agent keeps dossiers current by extracting entities from meeting notes and original thinking. This skill holds those behaviors so templates and folder descriptions stay clean. The Markdown shape is **GBrain-compatible**: if the external `gbrain` CLI is installed, it can import/sync the same vault.
 
-> This skill is pack guidance. The platform `open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers the dossier conventions on top.
+> This skill is pack guidance. The platform `/open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers the dossier conventions on top.
 
 ## The dossier convention (the load-bearing rule)
 
@@ -40,7 +40,7 @@ Two deltas from the platform default, both GBrain-specific:
 
 ## Agent behaviors
 
-- **Ingest from a meeting recorder.** If a meeting-recorder MCP (Granola, Fireflies, Circleback, tl;dv, Fathom, …) is registered alongside `open-knowledge`, pull recent meetings and write each into `meetings/`. Address each as `meetings/<source>-<source_meeting_id>` so re-syncing a meeting updates it in place instead of creating a duplicate. Normalize whatever the recorder returns (Granola's Me/Them streams, a bot's speaker turns) into notes plus the verbatim transcript; do NOT rewrite the transcript. This works the same on demand (you ask) or unattended (a scheduler asks) — the recorder is bring-your-own and interchangeable.
+- **Ingest from a meeting recorder.** If a meeting-recorder MCP (Granola, Fireflies, Circleback, tl;dv, Fathom, …) is registered alongside the OpenKnowledge MCP server, pull recent meetings and write each into `meetings/`. Address each as `meetings/<source>-<source_meeting_id>` so re-syncing a meeting updates it in place instead of creating a duplicate. Normalize whatever the recorder returns (Granola's Me/Them streams, a bot's speaker turns) into notes plus the verbatim transcript; do NOT rewrite the transcript. This works the same on demand (you ask) or unattended (a scheduler asks) — the recorder is bring-your-own and interchangeable.
 - After a meeting note lands, extract entity mentions and append timeline bullets to each referenced dossier (cite the meeting by markdown link). Stub any mentioned entity not yet captured.
 - Treat `originals/` as authoritative (the user's own words, not inferences).
 - Surface entity-to-entity edges (person ↔ company, concept hubs) when both ends exist.

package/dist/assets/skills/packs/knowledge-base/SKILL.md

@@ -11,7 +11,7 @@ metadata:
 
 This project uses the **source-grounded knowledge-base** layout. The whole point is a closed evidence loop: nothing canonical exists without a traceable chain back to a preserved source. This skill holds the workflow so the templates and `log.md` can stay clean — when you create a doc from a template you get structure, and the *how* lives here.
 
-> This skill is pack guidance. The platform `open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers the KB workflow on top.
+> This skill is pack guidance. The platform `/open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers the KB workflow on top.
 
 ## Link at creation
 
@@ -37,9 +37,9 @@ Each layer has a full, STOP-gated procedure, and each ships as its own skill so
 
 | Procedure | Where it lives | When |
 | --- | --- | --- |
-| ingest | Platform `open-knowledge` skill (`references/ingest-and-sources.md`) — its Grounding rule depends on it everywhere, so it ships with every project, not just this pack. | Preserve a shared URL / PDF / file verbatim, OR you fetched a URL to ground a KB claim (binary sources preserved, not scraped). |
-| research | Sibling skill `research-with-sources` | Investigate / compare / synthesize multiple sources → `status: provisional` article + `sources:`. |
-| consolidate | Sibling skill `consolidate-notes` | A decision was actually made → commit canonical source-of-truth with a `supersedes:` chain. |
+| ingest | Platform `/open-knowledge` skill (`references/ingest-and-sources.md`) — its Grounding rule depends on it everywhere, so it ships with every project, not just this pack. | Preserve a shared URL / PDF / file verbatim, OR you fetched a URL to ground a KB claim (binary sources preserved, not scraped). |
+| research | Sibling skill `/research-with-sources` | Investigate / compare / synthesize multiple sources → `status: provisional` article + `sources:`. |
+| consolidate | Sibling skill `/consolidate-notes` | A decision was actually made → commit canonical source-of-truth with a `supersedes:` chain. |
 
 Typical day-2 flow: user shares a URL → **ingest** (preserve) → user asks "now research this" → **research** (provisional article, ingesting more sources as needed) → decision lands → **consolidate** (canonical article, supersedes the research).
 
@@ -51,9 +51,9 @@ Typical day-2 flow: user shares a URL → **ingest** (preserve) → user asks "n
 
 **`external-sources/`** — Raw sources saved verbatim, not just cited: the actual fetched text of URLs, extracted text of PDFs, copies of referenced files. Each file's frontmatter carries the original URL, access date, and any author/publisher metadata. Produced by the ingest procedure (applies whether the user shared the URL or you fetched it yourself to ground a claim). Immutable after capture — update only to refresh a stale fetch. **No analysis here**; that belongs in `research/`.
 
-**`research/`** — Provisional analysis synthesizing external sources. Produced by the `research-with-sources` skill. Every factual claim cites a specific doc in `external-sources/` (or an inline URL if ingest was skipped); no unsourced assertions. Keep the `sources:` frontmatter list aligned with the docs actually linked in the body. Promote to `articles/` via the `consolidate-notes` skill once the team decides the findings are stable.
+**`research/`** — Provisional analysis synthesizing external sources. Produced by the `/research-with-sources` skill. Every factual claim cites a specific doc in `external-sources/` (or an inline URL if ingest was skipped); no unsourced assertions. Keep the `sources:` frontmatter list aligned with the docs actually linked in the body. Promote to `articles/` via the `/consolidate-notes` skill once the team decides the findings are stable.
 
-**`articles/`** — Canonical knowledge, committed after a team decision. Produced by the `consolidate-notes` skill. Carries a `supersedes:` chain tying back to the `research/` docs it replaces (which in turn cite `external-sources/`) so the full evidence chain is traceable without leaving the repo. Source-of-truth for the domain; update only when a new decision supersedes it.
+**`articles/`** — Canonical knowledge, committed after a team decision. Produced by the `/consolidate-notes` skill. Carries a `supersedes:` chain tying back to the `research/` docs it replaces (which in turn cite `external-sources/`) so the full evidence chain is traceable without leaving the repo. Source-of-truth for the domain; update only when a new decision supersedes it.
 
 ## Status flow
 

package/dist/assets/skills/packs/knowledge-base/consolidate/SKILL.md

@@ -9,7 +9,7 @@ metadata:
 ---
 # Consolidate — promote research into a canonical article
 
-> This skill is pack guidance. The platform `open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers the procedure on top.
+> This skill is pack guidance. The platform `/open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers the procedure on top.
 
 Promote existing research on a topic into a canonical article under `articles/`. **Canonical, not provisional** — the output is the source of truth for future agents, not a snapshot of uncertainty.
 
@@ -58,7 +58,7 @@ Locate research articles on this topic:
 - Follow its `sources:` frontmatter list — read every referenced source file
 - Also read any existing canonical article on the topic — if one already exists, you may be **updating** it rather than creating a new one
 
-If there is no research to consolidate, stop. Consolidation is promotion, not creation. Do the `research-with-sources` skill first.
+If there is no research to consolidate, stop. Consolidation is promotion, not creation. Do the `/research-with-sources` skill first.
 
 ### 2. Re-confirm the decision
 

package/dist/assets/skills/packs/knowledge-base/research/SKILL.md

@@ -9,9 +9,9 @@ metadata:
 ---
 # Research — gather sources and write provisional findings
 
-> This skill is pack guidance. The platform `open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers the procedure on top.
+> This skill is pack guidance. The platform `/open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers the procedure on top.
 
-Conduct **evidence-driven research** on a topic and produce a provisional research article under `research/`. Provisional, not canonical: research articles capture findings, trade-offs, and open questions at a point in time. They are promoted to canonical articles via the `consolidate-notes` skill only when decisions solidify.
+Conduct **evidence-driven research** on a topic and produce a provisional research article under `research/`. Provisional, not canonical: research articles capture findings, trade-offs, and open questions at a point in time. They are promoted to canonical articles via the `/consolidate-notes` skill only when decisions solidify.
 
 The content directory is the resolved `content.dir` — read it with `config({ key: 'content.dir' })` if you don't already know it. Paths below are relative to it.
 
@@ -189,7 +189,7 @@ Return this structure to the user:
 
 ## Step 3: Capture raw sources via ingest
 
-For each relevant URL, paper, or document in the confirmed rubric, follow the **ingest** procedure — it lives in the platform `open-knowledge` skill at `references/ingest-and-sources.md`, not in this pack. **Typical research pulls 3-8 sources.** Too few → thin synthesis. Too many → you'll be reading for the rest of the session.
+For each relevant URL, paper, or document in the confirmed rubric, follow the **ingest** procedure — it lives in the platform `/open-knowledge` skill at `references/ingest-and-sources.md`, not in this pack. **Typical research pulls 3-8 sources.** Too few → thin synthesis. Too many → you'll be reading for the rest of the session.
 
 - **Don't skip ingest.** Raw preservation separates capture from interpretation and makes research reproducible. An article without preserved sources is just opinion; an article with preserved sources is a trail someone else can follow.
 - If a fetch fails for a source you specifically need, **stop and ask the user to paste it** — don't silently drop it. Write-time fabrication of missing evidence is the biggest failure mode.
@@ -296,7 +296,7 @@ sources:
 ### Voice
 
 - **Provisional, not canonical.** Use "tentative", "initial findings", "based on current understanding."
-- **Do NOT write as if it were canonical** — that's misleading. Canonicality is the `consolidate-notes` skill's job, after decisions land.
+- **Do NOT write as if it were canonical** — that's misleading. Canonicality is the `/consolidate-notes` skill's job, after decisions land.
 - **Explicit about uncertainty.** Research is the layer where uncertainty is allowed to live.
 
 ---
@@ -366,7 +366,7 @@ In headless mode, write the recap into the research article's "Further reading"
 
 ## Non-goals
 
-- **Don't promote to a canonical article.** That's the `consolidate-notes` skill's job after a decision actually lands. Premature canonicalization buries uncertainty and misleads future readers.
+- **Don't promote to a canonical article.** That's the `/consolidate-notes` skill's job after a decision actually lands. Premature canonicalization buries uncertainty and misleads future readers.
 - **Don't hide uncertainty.** Research is the layer where "we don't know yet" is acceptable prose. Say it explicitly.
 - **Don't skip ingest.** Always capture raw sources first, then analyze. An article without preserved sources is opinion.
 - **Don't skip the Step 1 scan.** Duplicate research wastes the user's time AND misses chances to extend prior work.

package/dist/assets/skills/packs/okf/SKILL.md

@@ -16,7 +16,7 @@ metadata:
 
 This project was scaffolded to be conformant with **Google's Open Knowledge Format (OKF) v0.1** from the first commit — markdown + YAML frontmatter, a standard-markdown link graph, and two reserved files. Conformance here is pre-populated, **not enforced**: OpenKnowledge's native frontmatter schema stays open-shaped, nothing is linted, and you are free to author however you like. This skill explains the conventions so the kit stays OKF-portable as it grows.
 
-> This skill is pack guidance. The platform `open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers the OKF conventions on top.
+> This skill is pack guidance. The platform `/open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers the OKF conventions on top.
 
 ## The one rule (keep the kit conformant)
 

package/dist/assets/skills/packs/plain-notes/SKILL.md

@@ -11,7 +11,7 @@ metadata:
 
 The lightest pack: no posture imposed, just write and link.
 
-> This skill is pack guidance. The platform `open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers the notes habit on top.
+> This skill is pack guidance. The platform `/open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers the notes habit on top.
 
 ## Folders
 

package/dist/assets/skills/packs/software-lifecycle/SKILL.md

@@ -11,7 +11,7 @@ metadata:
 
 This project holds the doc lifecycle for an engineering team or OSS project. The flow is **proposals → decisions → specs → postmortems**, with **guides** as the how-to bucket. This skill holds the workflow so templates and folder descriptions stay clean.
 
-> This skill is pack guidance. The platform `open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers the lifecycle conventions on top.
+> This skill is pack guidance. The platform `/open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers the lifecycle conventions on top.
 
 ## The flow
 
@@ -44,11 +44,11 @@ Authoring in this project is procedural, not conventional. Each workflow ships a
 
 | Workflow | Sibling skill | When |
 | --- | --- | --- |
-| Frame a proposal | `frame-a-proposal` | A change needs designing and arguing before anyone builds it. |
-| Write a spec | `write-a-spec` | An accepted proposal needs scoping into an implementable spec. |
-| Record a decision | `record-a-decision` | A decision was actually made and needs its context and consequences preserved. |
-| Write a postmortem | `write-a-postmortem` | An incident happened and the team needs a blameless write-up. |
-| Review a design | `review-a-design` | An existing proposal, spec, or decision needs pressure-testing for soundness. |
+| Frame a proposal | `/frame-a-proposal` | A change needs designing and arguing before anyone builds it. |
+| Write a spec | `/write-a-spec` | An accepted proposal needs scoping into an implementable spec. |
+| Record a decision | `/record-a-decision` | A decision was actually made and needs its context and consequences preserved. |
+| Write a postmortem | `/write-a-postmortem` | An incident happened and the team needs a blameless write-up. |
+| Review a design | `/review-a-design` | An existing proposal, spec, or decision needs pressure-testing for soundness. |
 
 ## Templates
 

package/dist/assets/skills/packs/software-lifecycle/frame-a-proposal/SKILL.md

@@ -10,7 +10,7 @@ metadata:
 
 # Frame a proposal — turn a problem into a reviewable RFC
 
-The platform `open-knowledge` skill still governs every markdown operation here (reads via `exec`/`search`, writes via `write`/`edit`, links as plain relative markdown, never native Read/Edit/Grep/`cat` on in-scope files). This skill layers proposal-authoring craft on top: it decides *what a good proposal contains and in what order you earn each section*.
+The platform `/open-knowledge` skill still governs every markdown operation here (reads via `exec`/`search`, writes via `write`/`edit`, links as plain relative markdown, never native Read/Edit/Grep/`cat` on in-scope files). This skill layers proposal-authoring craft on top: it decides *what a good proposal contains and in what order you earn each section*.
 
 A proposal in `proposals/` is a design argument, not a decision and not a plan. It exists to force a **choice** among options and to give reviewers enough to disagree with. Filename is `0001-feature-name.md` — a zero-padded 4-digit sequence plus a kebab title. Status flows `draft → fcp → accepted/rejected` (fcp = final comment period). Acceptance graduates the proposal to a record in `decisions/` — that is a *separate*, human act and a *separate* skill.
 
@@ -215,8 +215,8 @@ State plainly that advancing status and accepting the proposal are human acts. Y
 
 ## Non-goals
 
-- **Don't record the decision.** Acceptance graduates a proposal to a record in `decisions/` — that's the sibling `record-a-decision` skill, run *after* a human accepts. This skill stops at `draft`.
-- **Don't write the implementation spec.** Design altitude, not build detail. The spec is `write-a-spec`.
+- **Don't record the decision.** Acceptance graduates a proposal to a record in `decisions/` — that's the sibling `/record-a-decision` skill, run *after* a human accepts. This skill stops at `draft`.
+- **Don't write the implementation spec.** Design altitude, not build detail. The spec is `/write-a-spec`.
 - **Don't mark a proposal `accepted` (or `fcp`) on your own authority.** Advancing status is a human act. Leave `status: draft`; offer the recap of what advancing would require.
 - **Don't skip the Step 1 framing gate.** Solution text before an agreed problem is the exact failure this skill exists to prevent. If you've drafted Design without a confirmed beneficiary and forced decision, you skipped the gate — back up.
 - **Don't pad Alternatives with strawmen or leave Drawbacks empty.** Both are tells that the proposal wasn't really examined. Reviewers read them as such.

package/dist/assets/skills/packs/software-lifecycle/record-a-decision/SKILL.md

@@ -10,7 +10,7 @@ metadata:
 
 # Record a decision — write an ADR under `decisions/`
 
-The platform `open-knowledge` skill still governs every markdown operation here (grounding, linking, the rule that OK's MCP tools own in-scope markdown); this skill layers ADR craft on top.
+The platform `/open-knowledge` skill still governs every markdown operation here (grounding, linking, the rule that OK's MCP tools own in-scope markdown); this skill layers ADR craft on top.
 
 An Architecture Decision Record is a small, dated, frozen document that captures **one** decision, the forces that made it necessary, and what the team now has to live with. The value compounds over years: a reader who joins in three years should understand not just what was decided but *why it was even a question*. ADRs are frozen once accepted — you never rewrite one to change your mind, you **supersede** it with a new record and leave the old one standing as history. That supersedes chain is what separates an honest decision log from a pile of stale opinions.
 
@@ -22,9 +22,9 @@ Filenames are `NNNN-title.md` (zero-padded 4-digit sequence + kebab title). Stat
 
 **An ADR records a decision; it does not make one.** Before anything else, establish that a choice has been settled.
 
-- If the user is still weighing options, comparing approaches, or asking "should we do X or Y?" — they do not have a decision yet. **Stop and route them to the `frame-a-proposal` skill.** A proposal is where options get explored and argued; an ADR is where the settled outcome gets recorded. Recording a decision the user has not made produces a fake record that misleads every future reader.
+- If the user is still weighing options, comparing approaches, or asking "should we do X or Y?" — they do not have a decision yet. **Stop and route them to the `/frame-a-proposal` skill.** A proposal is where options get explored and argued; an ADR is where the settled outcome gets recorded. Recording a decision the user has not made produces a fake record that misleads every future reader.
 - If the user says "we decided X" but you cannot tell *what lost* or *why*, ask one question: "What were the alternatives, and what made you pick this one?" An ADR with no rejected options is a press release, not a record.
-- If the thing in question is whether the design itself is sound — not the record of it — hand off to `review-a-design`. This skill assumes the decision is sound; it captures it.
+- If the thing in question is whether the design itself is sound — not the record of it — hand off to `/review-a-design`. This skill assumes the decision is sound; it captures it.
 
 Do not proceed past this gate until the user has confirmed a specific decision. State it back to them in one sentence and get a nod.
 
@@ -129,7 +129,7 @@ Read the draft as a skeptic who disagrees with the decision. Answer each honestl
 - **Would a reader who disagrees find their objection addressed?** The strongest counter-argument should appear somewhere — in a rejected option or a named consequence. If the obvious objection is missing, add it.
 - **Is any consequence being hidden because it's inconvenient?** The cost you'd rather not write down is exactly the one that belongs in the record.
 
-If this pass reveals that the *design itself* is in question — not the quality of the record but whether the decision is right — stop and hand off to `review-a-design`. This skill records sound decisions; it is not the place to relitigate one.
+If this pass reveals that the *design itself* is in question — not the quality of the record but whether the decision is right — stop and hand off to `/review-a-design`. This skill records sound decisions; it is not the place to relitigate one.
 
 ---
 
@@ -181,8 +181,8 @@ Then note whether `status` is `accepted` (deciders signed off) or `proposed` (aw
 
 ## Non-goals
 
-- **Don't decide on the user's behalf.** If no decision has been made, route to `frame-a-proposal`. This skill records; it does not choose.
+- **Don't decide on the user's behalf.** If no decision has been made, route to `/frame-a-proposal`. This skill records; it does not choose.
 - **Don't rewrite an accepted record.** ADRs are frozen. To change a past decision, supersede it (Step 7) and leave the old one standing — never edit its Context/Decision/Consequences prose.
-- **Don't fold implementation detail into an ADR.** The migration plan, the API shape, the rollout steps belong in a spec (`write-a-spec`). The ADR captures what and why, not how.
+- **Don't fold implementation detail into an ADR.** The migration plan, the API shape, the rollout steps belong in a spec (`/write-a-spec`). The ADR captures what and why, not how.
 - **Don't record a decision that has no consequences section.** A record with only upside, or with no costs and no new obligations, isn't an ADR — it's marketing. Every real decision costs something; find it and write it down.
-- **Don't judge the soundness of the design here.** If the question is whether the decision is *right* rather than whether it's well-recorded, that's `review-a-design`.
+- **Don't judge the soundness of the design here.** If the question is whether the decision is *right* rather than whether it's well-recorded, that's `/review-a-design`.

package/dist/assets/skills/packs/software-lifecycle/review-a-design/SKILL.md

@@ -10,7 +10,7 @@ metadata:
 
 # Review a design — is it sound, not just complete
 
-The platform `open-knowledge` skill still governs every markdown operation here (reads via `exec`, writes via `write`/`edit`, links as plain relative markdown, MCP owns in-scope `.md`); this skill layers design-review craft on top of it.
+The platform `/open-knowledge` skill still governs every markdown operation here (reads via `exec`, writes via `write`/`edit`, links as plain relative markdown, MCP owns in-scope `.md`); this skill layers design-review craft on top of it.
 
 **Three reviews are not the same review, and only one is this skill's job.**
 
@@ -119,9 +119,9 @@ Never edit the design under review to "apply" a finding. You emit findings; the
 
 Route blocking and substantive findings back to whoever owns the fix:
 
-- Findings on a **proposal** → **frame-a-proposal** (the argument, alternatives, or motivation needs rework).
-- Findings on a **spec** → **write-a-spec** (goals, non-goals, migration, or test plan needs rework).
-- A finding that has *resolved into a made choice* ("we discussed it; we're going with the synchronous version") → **record-a-decision**, so the choice and its rationale land in `decisions/` with a `supersedes:` link if it overturns a prior ADR.
+- Findings on a **proposal** → `/frame-a-proposal` (the argument, alternatives, or motivation needs rework).
+- Findings on a **spec** → `/write-a-spec` (goals, non-goals, migration, or test plan needs rework).
+- A finding that has *resolved into a made choice* ("we discussed it; we're going with the synchronous version") → `/record-a-decision`, so the choice and its rationale land in `decisions/` with a `supersedes:` link if it overturns a prior ADR.
 - A finding that a **past failure is being reintroduced** → point the author at the specific `postmortems/YYYY-MM-DD-name.md` so the design engages with it explicitly.
 
 Name the skill and the reason in your handoff so the author knows exactly where to go.

package/dist/assets/skills/packs/software-lifecycle/write-a-postmortem/SKILL.md

@@ -10,7 +10,7 @@ metadata:
 
 # Write a postmortem
 
-The platform `open-knowledge` skill still governs every markdown operation here — folder scope, the read/write tool surface, linking, and preview. This skill layers postmortem craft on top of it; it does not replace those rules.
+The platform `/open-knowledge` skill still governs every markdown operation here — folder scope, the read/write tool surface, linking, and preview. This skill layers postmortem craft on top of it; it does not replace those rules.
 
 A postmortem is not a status update and not a blame ledger. It is a durable, blameless reconstruction of one incident, built from evidence, that makes the system's failure mode legible and produces action items someone will actually verify. The value compounds only when postmortems that share a subsystem link to each other — that is how a repeat class stops being invisible.
 
@@ -198,5 +198,5 @@ Then point at the file: `postmortems/YYYY-MM-DD-name.md` and any runbook stubs c
 - **Don't stop at the first plausible cause.** "A bad config was pushed" is a trigger. Keep asking what made the trigger sufficient until you reach a missing safeguard.
 - **Don't write action items you cannot verify.** No owner, no date, no checkable done-condition means it is a wish, not an action item. Leave it out or fix it.
 - **Don't quietly omit "what went well."** Skipping it loses the practices worth preserving. If little went well, say so honestly rather than dropping the section.
-- **Don't use a postmortem to relitigate a design decision.** A postmortem documents what happened and what to change operationally. Arguing that the architecture should have been different belongs in a proposal (`frame-a-proposal`) or a design review (`review-a-design`) — link to it from Related; don't fight it here.
+- **Don't use a postmortem to relitigate a design decision.** A postmortem documents what happened and what to change operationally. Arguing that the architecture should have been different belongs in a proposal (`/frame-a-proposal`) or a design review (`/review-a-design`) — link to it from Related; don't fight it here.
 - **Don't fabricate the timeline.** No entry without a source you can point at; reconstructed-from-memory entries are labelled inline as such.

package/dist/assets/skills/packs/software-lifecycle/write-a-spec/SKILL.md

@@ -9,7 +9,7 @@ metadata:
 ---
 # Write a spec — scope a feature and commit an implementation spec
 
-> This skill is pack guidance. The platform `open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers spec-writing craft on top.
+> This skill is pack guidance. The platform `/open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers spec-writing craft on top.
 
 A spec is the contract between "we decided to build this" and "here is how it gets built." It is derived from an ACCEPTED proposal, maps the system that exists TODAY before proposing a change, and records its one-way-door choices in a Decision Log so the reasoning survives the author leaving. A spec that skips the current-system mapping, or resolves its open questions silently, is a liability — it reads authoritative while being unfounded.
 
@@ -58,7 +58,7 @@ A spec implements a decision that was already made. Before scoping anything, fin
 
 - **Accepted proposal exists** → note its path; it becomes `parent_proposal:` in the spec frontmatter. Proceed to Step 1.
 - **Proposal exists but is not accepted** (`draft`, `fcp`, `rejected`) → STOP. A spec for an un-accepted proposal builds on sand. Surface this: "The proposal `<path>` is at `status: <x>`, not accepted. A spec should follow an accepted proposal. Want me to help get it accepted first, or proceed anyway?"
-- **No proposal at all** → say so plainly: "There's no accepted proposal behind this feature. Specs derive from proposals — the proposal is where we argue *whether* to build; the spec is *how*. I can frame a proposal first (that's the `frame-a-proposal` skill), or, if you acknowledge the risk, proceed straight to a spec and record that we skipped the proposal." If the user opts to proceed, record that choice in the Decision Log (Step 6) with its rationale. Do not silently skip it.
+- **No proposal at all** → say so plainly: "There's no accepted proposal behind this feature. Specs derive from proposals — the proposal is where we argue *whether* to build; the spec is *how*. I can frame a proposal first (that's the `/frame-a-proposal` skill), or, if you acknowledge the risk, proceed straight to a spec and record that we skipped the proposal." If the user opts to proceed, record that choice in the Decision Log (Step 6) with its rationale. Do not silently skip it.
 
 **HARD GATE:** do not create `spec.md` until the parent-proposal question is resolved one way or the other and, if skipped, acknowledged by the user.
 
@@ -189,7 +189,7 @@ Each entry is a short block:
 Discipline:
 - One entry per one-way-door choice from Step 5, plus any process decision (e.g. "proceeded without a parent proposal per the user's acknowledgement on <date>").
 - The `Reverses if` line is not optional — a decision with no stated reversal condition can never be re-examined honestly.
-- This log is scoped to THIS spec. It is not the project's decision record. Recording an architecture decision in `decisions/` is the sibling `record-a-decision` skill's job; do not write ADRs here.
+- This log is scoped to THIS spec. It is not the project's decision record. Recording an architecture decision in `decisions/` is the sibling `/record-a-decision` skill's job; do not write ADRs here.
 
 ---
 
@@ -291,8 +291,8 @@ State plainly what is still open. A spec's honesty about its own gaps is what ma
 ## Non-goals
 
 - **Don't invent requirements the proposal didn't establish.** The spec is *how*, not a second bite at *whether*. A goal with no root in the parent proposal is scope creep — flag it, don't smuggle it in.
-- **Don't record decisions in `decisions/`.** That's the sibling `record-a-decision` skill. The spec's Decision Log is scoped to THIS spec's one-way doors; it is not the project's ADR record.
+- **Don't record decisions in `decisions/`.** That's the sibling `/record-a-decision` skill. The spec's Decision Log is scoped to THIS spec's one-way doors; it is not the project's ADR record.
 - **Don't skip the current-system mapping.** Designing against an imagined system is the top failure mode. No `## Design` before Step 1's map with real pointers.
 - **Don't mark `shipped` before the work ships.** `status` reflects reality. A spec is `draft` until built, and only `shipped` once the code is live — never aspirationally.
-- **Don't write the postmortem.** If the shipped feature breaks, the incident write-up is the `write-a-postmortem` skill's job, not an addendum here.
+- **Don't write the postmortem.** If the shipped feature breaks, the incident write-up is the `/write-a-postmortem` skill's job, not an addendum here.
 - **Don't silently resolve Open Questions.** A marked open question is information; a fabricated answer is a hazard. Ship the spec with its unknowns visible.

package/dist/assets/skills/packs/worldbuilding/SKILL.md

@@ -11,7 +11,7 @@ metadata:
 
 This project is a fiction encyclopedia. The graph is the product: characters, settings, themes, factions, and lore that link to each other. The agent's main jobs are auto-stubbing new entities as they're mentioned and flagging contradictions. This skill holds those behaviors so templates and folder descriptions stay clean.
 
-> This skill is pack guidance. The platform `open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers the worldbuilding conventions on top.
+> This skill is pack guidance. The platform `/open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers the worldbuilding conventions on top.
 
 ## Folders
 

package/dist/assets/skills/packs/writing-pipeline/SKILL.md

@@ -11,7 +11,7 @@ metadata:
 
 A lean three-stage flow for short-to-medium-form writing (essays, newsletters, blog posts).
 
-> This skill is pack guidance. The platform `open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers the drafting flow on top.
+> This skill is pack guidance. The platform `/open-knowledge` skill (read/write/preview/linking/grounding rules) still governs every markdown operation — this layers the drafting flow on top.
 
 
 ```

package/dist/assets/skills/project/SKILL.md

@@ -21,7 +21,7 @@ OpenKnowledge (OK) is a markdown-CRDT collaboration platform exposed via MCP. Th
 3. **Preview / open a doc — determine your ONE surface FIRST (once per session).** Stop at first match: **`OK_DESKTOP_TERMINAL` or `OK_HOSTED_AGENT` set** → you're inside OpenKnowledge (desktop terminal / in-app agent panel) → `ok open <name>` (switches the window the user is already looking at); never paste a `localhost` URL into your reply here · in-app browser (Claude Code Desktop's Browser pane, Cursor, Codex) → `preview_url`, then open/navigate it to the doc · else plain CLI → `ok open <name>`. `ok open <name>` opens a doc or folder (auto-detected); `--skill <name>` for a skill. The `previewUrl` field is a route id, **not** your open mechanism. Don't `preview_screenshot` to confirm edits. Full Step-0 procedure + per-surface how-to: `references/preview.md`.
 4. **Knowledge layers:** capturing a source (ingest), synthesizing findings (research), promoting a decision (consolidate) — procedures, **not tool calls**; there is no `ingest` tool. Ingest ships here (`references/ingest-and-sources.md`); research + consolidate come with the `knowledge-base` pack. Layer model + packs: `references/starter-packs.md`.
 5. **Direct questions:** a plain business question ("which customers…", "what did we decide about…") routes to `search` / `exec` + a cited chat answer — no "research" keyword needed. Persist only when durable + multi-doc + not already covered, and *offer* first. See `references/corpus-qa.md`.
-6. **Authoring or improving a skill** ("write/make a skill", "improve this skill", "turn this into a skill"): STOP and invoke the **`open-knowledge-write-skill`** skill — it owns scope choice (project vs global), the SKILL.md contract, evaluation, and install; don't improvise here. Author through the `skill` target (`write({ skill })`), never a raw path document. Skills are REAL folders under the editor dirs' `skills/` (`.claude` · `.cursor` · `.codex` · `.opencode` · `.pi` · `.agents`): ONE is the source, the rest are managed copies/symlinks. **Read and edit via the tools (`skills`, `edit({ skill })`) — they route to the source.** Never hand-edit a non-source copy: unedited copies refresh from the source, and editing one forks it into its own skill that stops refreshing.
+6. **Authoring or improving a skill** ("write/make a skill", "improve this skill", "turn this into a skill"): STOP and invoke the **`/open-knowledge-write-skill`** skill — it owns scope choice (project vs global), the SKILL.md contract, evaluation, and install; don't improvise here. Author through the `skill` target (`write({ skill })`), never a raw path document. Skills are REAL folders under the editor dirs' `skills/` (`.claude` · `.cursor` · `.codex` · `.opencode` · `.pi` · `.agents`): ONE is the source, the rest are managed copies/symlinks. **Read and edit via the tools (`skills`, `edit({ skill })`) — they route to the source.** Never hand-edit a non-source copy: unedited copies refresh from the source, and editing one forks it into its own skill that stops refreshing.
 
 ## Tool index — 21 tools (router; the MCP tool descriptions carry each tool's full contract)
 
@@ -115,8 +115,8 @@ Three recurring practices, not tool calls — each a full procedure that ships a
 | Layer | When | Procedure |
 | --- | --- | --- |
 | **ingest** | Preserve a shared URL/PDF/file verbatim, or you fetched a URL to ground a claim (binary sources preserved, not scraped). | `references/ingest-and-sources.md` — ships here, §Grounding depends on it |
-| **research** | Investigate / compare / synthesize sources → `status: provisional` article + `sources:`. | `research-with-sources` skill |
-| **consolidate** | A decision was made → canonical source-of-truth with a `supersedes:` chain. | `consolidate-notes` skill |
+| **research** | Investigate / compare / synthesize sources → `status: provisional` article + `sources:`. | `/research-with-sources` skill |
+| **consolidate** | A decision was made → canonical source-of-truth with a `supersedes:` chain. | `/consolidate-notes` skill |
 
 Research and consolidate arrive with `ok seed --pack knowledge-base`. **Without that pack you do not have those procedures** — don't improvise one; do the work as an ordinary grounded `write`, or offer to seed it (`ok seed --pack knowledge-base --dry-run` shows what it would add).
 

package/dist/assets/skills/project/references/starter-packs.md

@@ -12,7 +12,7 @@ Typical day-2 flow: user shares a URL → ingest (preserve) → user asks "now r
 
 - ingest → reference file `ingest-and-sources.md`, here in this bundle. Ships with every `ok init` because Core's Grounding rule depends on it, pack or no pack.
 - onboard a repo that already has content → reference file `onboard-existing-repo.md`, here in this bundle.
-- research / consolidate → their own skills, `research-with-sources` and `consolidate-notes`, installed alongside their pack by `ok seed --pack knowledge-base`. **Not available otherwise** — if the pack isn't seeded, say so rather than improvising a lookalike pipeline.
+- research / consolidate → their own skills, `/research-with-sources` and `/consolidate-notes`, installed alongside their pack by `ok seed --pack knowledge-base`. **Not available otherwise** — if the pack isn't seeded, say so rather than improvising a lookalike pipeline.
 - generate / refresh a codebase wiki → reference file `generate-and-refresh.md`, inside the `codebase-wiki` skill's bundle and readable once that skill loads. Installed by `ok seed --pack codebase-wiki`.
 
 Read the relevant procedure and execute its numbered steps with the OK verbs; don't skip its STOP gates.