kb-setup

Skill: KB Setup

This skill is the single entry point for bootstrapping an agentic-kb workspace. It is idempotent: reruns add missing pieces, propose graph extensions, and never overwrite existing material without confirmation.

Scope boundary — install vs. init

This skill initializes the user's KB workspace. It does not distribute itself.

Two concerns, two tools:

Concern	Who handles it	When
Get kb-management + kb-setup + kb-operator into the harness	Marketplace install or scripts/install.py	Before this skill runs
Scaffold the user's layer repos, config, and workspace indexes	This skill	When the user types /kb setup

When to invoke

• The user types /kb setup.
• The user says they want to set up, bootstrap, or onboard a KB workspace.
• kb-management detects no .kb-config/layers.yaml in the current workspace and the user tries any /kb command.

Interactive question flow

The interview is goal-oriented, not feature-list-driven. Phase 1 collects the minimum admin facts the wizard cannot infer (workspace root and harness — frontloaded so the user knows where files will land before they invest in long answers); phase 2 asks the user about their world in their own language; phase 3 shows a derived plan and lets the user adjust before anything is written.

Ask each block in order. Stop and wait after each block for the user's answer before proceeding. Never ask the user to enumerate layers, features, contributor-mode flags, or scopes in phase 2 — those are derived in phase 3 and only adjusted there.

Phase 1 — Workspace and harness facts (short admin, frontloaded)

This phase runs first so the user always knows which directory the scaffold will land in and which harness will host /kb before they invest in open-ended answers. Wrong harness or wrong workspace root caught here is a one-line fix; caught after phase 2 it is sunk-cost frustration.

1. Workspace root — absolute path; default current directory. Confirm with the user before continuing if the current directory looks accidental (e.g. ~/Downloads, a non-git directory the user did not expect).
2. IDE targets — multi-select from claude-code, vscode, opencode, codex, gemini, kiro. Used by scripts/install.py to decide where harness hooks are written (.claude/commands/, .github/prompts/, .agents/skills/, etc.). The right answer here prevents a silent "No KB detected" later.
3. Discovery pass — scan the workspace for existing KB repos, harness hooks, and likely layer candidates. Also probe for repo-as-OS structures (e.g. work/signals/, work/missions/, org/<layer>/, CONFIG.yaml, CODEOWNERS with policy directories). If a repo-as-OS structure is detected, surface it before phase 3 so the proposal can reuse existing repos and propose bridge defaults instead of inventing parallel structure.