菜单
Search the shared knowledge base before you guess. Call the search_knowledge tool (or `lanius kb search <query>`) to recall curated facts — model tiering, roles, conventions — and get back the file + line to open. The tool's existence is high-availability; the mechanics here are expando.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Resolve-and-promote security gate — verifies a Telegram (or other in/dm/*) chat id against the phonebook and, only when it resolves to owner, promotes it onto in/human/owner. Fail-closed; a stranger's message stops at an unresolved sighting.
Telegram bridge (daemon) — getUpdates messages become in/dm/telegram/<chat.id> conversation ingress; in/package/telegram/send delivers replies with sender=telegram receipts. A transport is just a package (zero kernel edits).
Runbook for diagnosing common lanius RUNTIME / operational failures — broker & bus errors ("CONNECT refused", "bad credential"), stray/orphaned processes, ports stuck in use, the daemon not dispatching, the web UI not loading. Use when something is failing at runtime (not a compile error or a logic bug) and you want the symptom → cause → diagnose → fix → prevent steps. Each file in this skill is ONE runbook entry, keyed by the symptom you actually see. Start here, match your symptom to an entry, follow it.
The journey → handoff → implement → verify pipeline for shipping substantial work on lanius, with deliberate model-tiering across the phases. Use when Tim asks to plan a feature, write or "knock out" handoff docs, implement a spec, or orchestrate implementation + verification — anything bigger than a quick edit. Encodes who plans vs implements vs verifies, which model/effort fits each phase, how to dispatch clean-context worker agents, and the containment + commit discipline that keeps the repo clean. Fable should *ALWAYS* follow the second-level workflow specified below.
How agents talk on Lanius - to the human (send_message vs ask_human), to coding workers (deliver/spawn/inbox), and to native/profile agents (agent catalog/run/spawn), when to speak unprompted vs stay quiet, when to set priority, shared-channel etiquette, and the failure-mail contract. Read before messaging the human, dispatching work to another agent, launching a native/profile agent, or coordinating in a shared room.
The chat/conversation view — owns the chat protocol on the bus and answers the chat-shaped conversation-list + introspection queries over local HTTP from the sqlite truth. Requires the history package.
| name | kb-search |
| description | Search the shared knowledge base before you guess. Call the search_knowledge tool (or `lanius kb search <query>`) to recall curated facts — model tiering, roles, conventions — and get back the file + line to open. The tool's existence is high-availability; the mechanics here are expando. |
The knowledge base is the union of every enabled package's kb/ corpus (see
lanius kb list). It feels like one KB even though it is many packages. This
package makes it searchable two ways, both over the same FTS5 index:
The search_knowledge tool — your primary surface. It is an ordinary
entry in your tool array (folded in once the package is approved and visible).
Call it with a plain-words query; it returns ranked hits, each a
{package, path, lines, snippet} pointing at a file and a line range you can
open with the ordinary read tools. It is read-only and cheap — call it freely
before answering from memory.
{ "query": "who verifies", "limit": 5 }
→ { "query": "who verifies",
"hits": [ { "package": "kb-llm-strengths",
"path": "kb/role-verifier.md",
"lines": "6-13",
"snippet": "Who verifies … Opus on high … Fable for the hardest" } ] }
lanius kb search <query> — the same hits from the CLI, for a harness or a
human at a shell. --json for one JSON object per hit; --limit N to widen.
The existence of search_knowledge is high-availability: know it is there and
reach for it. The mechanics — the FTS5 index, the poll-driven re-index, the
engine-swap seam — are expando: read them here only when you need them.
A read-only daemon (scripts/index) rebuilds the index from the corpus on disk,
polling for changes: enable or disable a kb-carrying package and its content
becomes findable on the next pass. The daemon never writes a kb/ file — it only
writes its own index, in its own state dir. There is no kernel schema behind any
of this.
search_knowledge is a bare tool name, so a different engine (an
embedding-based indexer, say) can ship the SAME [[tool]] name = "search_knowledge"
and replace this one invisibly — your tool array is unchanged. The harness allows
exactly one live holder of the name: disable this package, enable the other.
Enabling both and approving the second is refused, loudly.