How long does the integration take?

Change one base URL in an OpenAI-compatible client, or install the Python or TypeScript SDK; the quickstart routes a first request in a few minutes.

Will this lock us into another vendor?

No. The router is Apache-2.0 open source, your provider keys stay yours, and the API is OpenAI-compatible, so leaving is a change of base URL.

What happens when a provider fails?

The router falls back to the next model your policy allows and records the fallback in the trace, so an outage costs a retry, not an incident.

kb-publish - Prompt - OpenSmartRoute

Name: kb-publish
Author: vuonglq01685

Prompt file imported from vuonglq01685/strata-kb (.github/prompts/kb-publish.prompt.md). Copyright stays with the author.

/kb-publish — diff → confirm → publish (PR on the hub)

The hub federation is the single source of truth: content is searchable only after the publish PR is merged on the hub. Local .kb/ is just a drafting desk.

NEVER run kb publish until the user has explicitly confirmed, after seeing the diff, that the current .kb/ state should be published.

Workflow

Check state. Run kb status. If any section is still pending, stop and tell the user to summarize first (kb summarize, or the kb-summarize skill).
Show what will be published. Run kb doctor — it reports whether local .kb differs from the published snapshot. In a ba or dev repo it asks the hub over MCP (kb mcp-setup), never a hub clone. If it cannot reach the hub, stop: the user runs kb mcp-setup (in a cloud session: sets STRATA_KB_HUB_URL and STRATA_KB_HTTP_TOKEN in the environment, since .env is not committed), then publish again. For each doc with changes, run kb diff <doc-id> --against HEAD (use another git rev if the user names one) and present the added/changed sections. In a ba repo, kb publish first regenerates <repo_id>-plan with kb plan-ingest; run kb plan-ingest to see what will ship and what is skipped (kb doctor does not diff -plan). Both .kb/<repo_id>-plan/ and .kb/index.yaml are generated and gitignored there.
Confirm — the gate. State where it goes. With intake: in .kb/config.yaml, kb publish pushes a kb-publish/* tag, CI uploads to that intake URL and the hub opens the PR: no hub clone and no hub: needed. In a ba repo a push to main that changes missions/ or tickets/ also publishes (kb-publish-request.yml tags the merged commit), so a merged PR needs no kb publish. Otherwise state the hub (from .kb/config.yaml, or STRATA_KB_HUB if set) and that a publish PR will be opened on it (direct is picked for a hub with no git remote). Also state the repo's kind and the hub menu it lands in, as kb publish prints it: kind: <hub kind> → hub menu: <Document|Ticket|Code> (hub and child repos → Document, ba → Ticket, dev → Code). Read the kind from kind: in .kb/config.yaml, or the [info] kind: … line kb doctor prints. If the kind is unrecorded, stop: tell the user to run kb init --kind <child|ba|dev|hub> first. Ask for one explicit go/no-go and wait.
Execute (only after confirmation): kb publish. Relay the result: the kind: … → hub menu: … line, repo-id, source commit, doc count, and the PR URL — remind the user the content goes live when that PR is merged on the hub.
Errors.
- Kind unrecorded (message mentions kb init --kind) → stop; the user runs kb init --kind <child|ba|dev|hub>, then publishes again.
- Missing hub config (only without intake:) → tell the user to fill hub: in .kb/config.yaml; a ba/dev repo whose people cannot clone the hub sets intake: instead.
- gh missing in PR mode → install GitHub CLI, or kb publish --direct only if direct pushes are allowed for this hub.
- Tag push refused (e.g. HTTP 403 where only the branch may be pushed, as in a cloud session) in a ba repo → nothing was published; merge the change into main, which publishes it, or run kb-publish-request.yml by hand on main.
- Other git/hub errors → show the stderr and suggest kb doctor.

Install kb-publish and it becomes one more candidate the router can pick - when it fits.

A listing is a routing target with a manifest: what it does, which domains it covers, what it costs and who publishes it. Once installed it sits beside your own models and tools, is scored like any other candidate for each request, and shows up in the trace when it wins. Ratings come from workspaces that installed it, one per account.

# /kb-publish — diff → confirm → publish (PR on the hub) The hub federation is the single source of truth: content is searchable only after the publish PR is merged on the hub. Local `.kb/` is just a drafting desk. NEVER run `kb publish` until the user has explicitly confirmed, after seeing the diff, that the current .kb/ state should be published. ## Workflow 1. **Check state.** Run `kb status`. If any section is still `pending`, stop and tell the user to summarize first (`kb summarize`, or the kb-summarize skill). 2. **Show what will be published.** Run `kb doctor` — it reports whether local .kb differs from the published snapshot. In a `ba` or `dev` repo it asks the hub over MCP (`kb mcp-setup`), never a hub clone. If it cannot reach the hub, stop: the user runs `kb mcp-setup` (in a cloud session: sets `STRATA_KB_HUB_URL` and `STRATA_KB_HTTP_TOKEN` in the environment, since `.env` is not committed), then publish again. For each doc with changes, run `kb diff <doc-id> --against HEAD` (use another git rev if the user names one) and present the added/changed sections. In a `ba` repo, `kb publish` first regenerates `<repo_id>-plan` with `kb plan-ingest`; run `kb plan-ingest` to see what will ship and what is skipped (`kb doctor` does not diff `-plan`). Both `.kb/<repo_id>-plan/` and `.kb/index.yaml` are generated and gitignored there. 3. **Confirm — the gate.** State where it goes. With `intake:` in `.kb/config.yaml`, `kb publish` pushes a `kb-publish/*` tag, CI uploads to that intake URL and the hub opens the PR: no hub clone and no `hub:` needed. In a `ba` repo a push to `main` that changes `missions/` or `tickets/` also publishes (`kb-publish-request.yml` tags the merged commit), so a merged PR needs no `kb publish`. Otherwise state the hub (from `.kb/config.yaml`, or `STRATA_KB_HUB` if set) and that a publish PR will be opened on it (direct is picked for a hub with no git remote). Also state the repo's kind and the hub menu it lands in, as `kb publish` prints it: `kind: <hub kind> → hub menu: <Document|Ticket|Code>` (`hub` and `child` repos → Document, `ba` → Ticket, `dev` → Code). Read the kind from `kind:` in `.kb/config.yaml`, or the `[info] kind: …` line `kb doctor` prints. If the kind is unrecorded, stop: tell the user to run `kb init --kind <child|ba|dev|hub>` first. Ask for one explicit go/no-go and wait. 4. **Execute** (only after confirmation): `kb publish`. Relay the result: the `kind: … → hub menu: …` line, repo-id, source commit, doc count, and the **PR URL** — remind the user the content goes live when that PR is merged on the hub. 5. **Errors.** - Kind unrecorded (message mentions `kb init --kind`) → stop; the user runs `kb init --kind <child|ba|dev|hub>`, then publishes again. - Missing hub config (only without `intake:`) → tell the user to fill `hub:` in `.kb/config.yaml`; a ba/dev repo whose people cannot clone the hub sets `intake:` instead. - `gh` missing in PR mode → install GitHub CLI, or `kb publish --direct` only if direct pushes are allowed for this hub. - Tag push refused (e.g. HTTP 403 where only the branch may be pushed, as in a cloud session) in a `ba` repo → nothing was published; merge the change into `main`, which publishes it, or run `kb-publish-request.yml` by hand on `main`. - Other git/hub errors → show the stderr and suggest `kb doctor`.

{ "prompt": "# /kb-publish — diff → confirm → publish (PR on the hub)\n\nThe hub federation is the single source of truth: content is searchable only\nafter the publish PR is merged on the hub. Local `.kb/` is just a drafting desk.\n\nNEVER run `kb publish` until the user has explicitly confirmed, after\nseeing the diff, that the current .kb/ state should be published.\n\n## Workflow\n\n1. **Check state.** Run `kb status`. If any section is still `pending`,\n stop and tell the user to summarize first (`kb summarize`, or the\n kb-summarize skill).\n2. **Show what will be published.** Run `kb doctor` — it reports whether\n local .kb differs from the published snapshot. In a `ba` or `dev` repo\n it asks the hub over MCP (`kb mcp-setup`), never a hub clone. If it\n cannot reach the hub, stop: the user runs `kb mcp-setup` (in a cloud\n session: sets `STRATA_KB_HUB_URL` and `STRATA_KB_HTTP_TOKEN` in the\n environment, since `.env` is not committed), then publish again. For each doc with\n changes, run `kb diff <doc-id> --against HEAD` (use another git rev if\n the user names one) and present the added/changed sections.\n In a `ba` repo, `kb publish` first regenerates `<repo_id>-plan` with\n `kb plan-ingest`; run `kb plan-ingest` to see what will ship and what is\n skipped (`kb doctor` does not diff `-plan`). Both `.kb/<repo_id>-plan/` and `.kb/index.yaml` are generated\n and gitignored there.\n3. **Confirm — the gate.** State where it goes. With `intake:` in `.kb/config.yaml`,\n `kb publish` pushes a `kb-publish/*` tag, CI uploads to that intake URL\n and the hub opens the PR: no hub clone and no `hub:` needed. In a `ba`\n repo a push to `main` that changes `missions/` or `tickets/` also\n publishes (`kb-publish-request.yml` tags the merged commit), so a\n merged PR needs no `kb publish`. Otherwise\n state the hub (from `.kb/config.yaml`, or `STRATA_KB_HUB` if set) and\n that a publish PR will be opened on it (direct is picked for a hub with\n no git remote). Also state the repo's kind\n and the hub menu it lands in, as `kb publish` prints it:\n `kind: <hub kind> → hub menu: <Document|Ticket|Code>` (`hub` and `child`\n repos → Document, `ba` → Ticket, `dev` → Code). Read the kind from\n `kind:` in `.kb/config.yaml`, or the `[info] kind: …` line `kb doctor`\n prints. If the kind is unrecorded, stop: tell the user to run `kb init --kind <child|ba|dev|hub>`\n first. Ask for one explicit go/no-go and wait.\n4. **Execute** (only after confirmation): `kb publish`. Relay the result:\n the `kind: … → hub menu: …` line, repo-id, source commit, doc count, and the **PR URL** — remind the user\n the content goes live when that PR is merged on the hub.\n5. **Errors.**\n - Kind unrecorded (message mentions `kb init --kind`) → stop; the user\n runs `kb init --kind <child|ba|dev|hub>`, then publishes again.\n - Missing hub config (only without `intake:`) → tell the user to fill\n `hub:` in `.kb/config.yaml`; a ba/dev repo whose people cannot clone\n the hub sets `intake:` instead.\n - `gh` missing in PR mode → install GitHub CLI, or `kb publish --direct`\n only if direct pushes are allowed for this hub.\n - Tag push refused (e.g. HTTP 403 where only the branch may be pushed,\n as in a cloud session) in a `ba` repo → nothing was published; merge\n the change into `main`, which publishes it, or run\n `kb-publish-request.yml` by hand on `main`.\n - Other git/hub errors → show the stderr and suggest `kb doctor`.", "variables": [], "notes": "Review and publish the local KB to the federation hub — diff vs the published snapshot, confirm, then kb publish (PR on the hub). Use when asked to publish the KB or push knowledge to the hub. Mode: agent.", "metadata": { "source": { "provider": "github-prompts", "repository": "https://github.com/vuonglq01685/strata-kb", "path": ".github/prompts/kb-publish.prompt.md", "ref": "381c0114e750736aecbef012896f5f8bf709e8ea", "url": "https://github.com/vuonglq01685/strata-kb/blob/381c0114e750736aecbef012896f5f8bf709e8ea/.github/prompts/kb-publish.prompt.md", "key": "vuonglq01685/strata-kb/.github/prompts/kb-publish.prompt.md" } } }

kb-publish

About

/kb-publish — diff → confirm → publish (PR on the hub)

Workflow

Install kb-publish and it becomes one more candidate the router can pick - when it fits.

What it costs to adopt - in engineering time.

One base URL

No vendor lock-in

Failover built in

Use it

Manifest

Reviews