一键导入
kb-create
Operator procedure to declare and provision a new Knowledge Base GitOps-style, so it survives pod restarts.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Operator procedure to declare and provision a new Knowledge Base GitOps-style, so it survives pod restarts.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Configure, operate, troubleshoot, or upgrade a Cartographer server or client; connect agents and manage Knowledge Bases.
Agent-guided procedure to import an existing non-OKF wiki or knowledge base (Obsidian vault, markdown folder, wiki export) into a Cartographer KB, incrementally and without big-bang LLM rewriting.
Packages the outcome of an analysis/design discussion into a self-contained GitHub plan issue (design → implementation handoff). Use when the user asks to "write the plan" following a discussion, or when a session needs to implement an existing plan issue.
Orchestrate implementation of one or more approved plan issues (label `plan`) into merged PRs — wave planning from cross-plan execution order, delegation to `dev` subagents in isolated worktrees, coordinator review, and ordered squash-merge with docs-append conflict resolution. Use when the user asks to implement/ship/land open plan issues (one or many). Sibling of the `plan` skill: `plan` writes issues (design → handoff), `implement-plan` consumes them (issue → merged PR).
Guide an agent through resolving open git rebase conflicts on degraded KB concepts.
Guide for querying the infra map (rete expanded concept) of the homelab KB.
| name | kb-create |
| description | Operator procedure to declare and provision a new Knowledge Base GitOps-style, so it survives pod restarts. |
| version | 2.3 |
Guide an operator through creating a new Knowledge Base (KB) the persistent, GitOps way: a Gitea repo as source of truth, declared in the server's config (ConfigMap), rolled out, then verified and connected. This replaces the old runtime-only creation flow (v1.x) — a KB that only exists as an ad-hoc runtime mount on an emptyDir is not durable.
WARNING — data loss risk. A KB mounted on an
emptyDirvolume that is not declared in the Deployment's ConfigMap (kbs:entry +remote:) dies with the pod: on the next reschedule / rollout the directory is recreated empty and every concept written to it is gone. The ConfigMap + Gitea repo declaration is what makes the KB persistent and reconstructible — the server clones it fresh on every pod start (docs/deployment.md§Bootstrap KB da remote git).
Create an empty repo <nome>.git on Gitea. The KB name is the name: field of its kbs:
entry (D53) — set it explicitly; if omitted it falls back to the repo basename (resolveKBName in
cmd/cartographer/bootstrap.go). The name is used everywhere downstream: token scopes
(kb:<nome>:rw/kb:<nome>:r), the ?kb=<nome> query param on multi-KB HTTP, and the
<nome>.token/<nome>.age per-KB file conventions below. Choose it accordingly (kebab-case).
Then create a dedicated Gitea service user for the KB (convention: kb-<nome>), add it as a
collaborator with write permission on the repo only, and generate an access token for it
(scope write:repository). This token is the KB's git credential (one user per KB = per-repo
isolation; Gitea tokens are per-user, not per-repo).
On any machine with the cartographer binary and git access to the new repo:
cartographer serve --kb <dir> --init # creates the layout, then Ctrl-C
This creates the standard layout: data/ (conceptual root), services/, skills/, agents/,
hooks/ — content directories only, no AGENTS.md/.gitignore (D62; the local .cartographer/
index is excluded via .git/info/exclude, not a versioned .gitignore) — and initializes <dir>
as a git repo with a first commit
("init: KB inizializzata"). Optionally, add a curated instructions.md at the KB root (sibling of
data/, skills/, agents/) with free-form orchestration directives (e.g. delegation routing,
"large reads → explorer") — its body is folded into the generated instructions artifact after the
auto-generated archives/agent sections (D61, docs/sync.md §Instructions). Then push it to the
Gitea repo created in step 1:
git -C <dir> remote add origin <gitea-repo-url>
git -C <dir> push -u origin <branch>
Add an entry under kbs: in the server's YAML config (CARTOGRAPHER_CONFIG, see
config.example.yaml) with the remote: pointing at the Gitea repo from step 1:
git:
token_dir: /etc/kb-git # per-KB git credentials: <token_dir>/<nome>.token (D53)
sops:
age_key_dir: /etc/kb-sops # per-KB age keys: <age_key_dir>/<nome>.age (D53)
kbs:
- name: <nome>
remote: https://gitea.example.com/user/<nome>.git
# optional per-KB overrides (zero value = fall back to the global git/sops config):
# author_name / author_email, committer_name / committer_email
# sops_age_key_file: /path/custom.age # only to override the age_key_dir convention
No per-KB paths are needed in the config: with git.token_dir and sops.age_key_dir set once,
the server picks up <nome>.token and <nome>.age by convention. SSH remotes
(ssh_key/known_hosts) remain supported for setups without token auth.
Secret backing git.token_dir (key
<nome>.token); if the KB has SOPS secrets, add its age key as <nome>.age in the secret
backing sops.age_key_dir. Never inline key material in the ConfigMap itself.CARTOGRAPHER_TOKENS (or auth.tokens in
the YAML): format token|kb:<nome>:rw (read-write) or token|kb:<nome>:r (read-only), entries
separated by comma/whitespace, scopes on one token separated by ;. Do not reuse an admin
(scope-less) token for a KB that should be access-limited.Apply the updated ConfigMap/Secret and roll out the Deployment so the server picks up the new
kbs: entry and clones the repo on startup (ensureClonedKB).
atlas_overview with ?kb=<nome> (HTTP
multi-KB) or kb=<nome> argument, confirm data/index.md exists.cartographer connect (interactive form or flags) with the scoped token,
or edit .cartographer.yaml directly (server_url, token env var pointing at the token from
step 4).Once the KB is live, use the standard MCP tools to shape its content — this part is unchanged from v1.x and can be driven by the agent, not just the operator:
kind
(map/journal), concept_types, ontology_mode: strict/emergent/off, default
emergent.map_create for each one.concept_expand
(turns <id>.md into <id>/index.md plus satellite concepts) — there is no separate
"dossier create" step.skill_list / skill_install to offer relevant bundled skills.atlas_overview, map_create, concept_expand, concept_write, skill_list, skill_install.data/ is the conceptual root; concept IDs are relative to it./mcp?kb=<name> when more than one KB is mounted; <name> is always
the KB's basename (see step 1).config.example.yaml, docs/deployment.md §Bootstrap KB da remote git e
§Configurazione, docs/transport-auth.md §Autorizzazione per-KB, decisions.md D39/D44/D46/D47.