lanius

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.

The model-tiering knowledge base — which model to use for planning, implementation, and verification. Read a kb/role-*.md file when you are about to dispatch or pick a model for a task.

Read, search, and write knowledge bases (kb/ folders). Use when you learn something durable that is "ours" (not just your own scratch notes) — model tiering, an API's quirks, a project convention — or when you need a fact someone already wrote down.

Discord ingress bridge (UNTESTED scaffold) — gateway messages become in/dm/discord/<channel-id> conversation ingress; in/package/discord/send posts replies with delivery receipts.

The lanius visual identity — use when building, styling, or theming any UI or brand surface (ui/web, the README, a splash, an icon, an artifact/mockup). Sets the shrike/thorn identity, the palette and the one-red rule, the type system, and how the logo system is used. Marks live in brand/logos/; full direction in docs/handoffs/web-ui-redesign.md. Pair with the lanius-voice skill for copy.

How lanius talks — the plain-language rules for ALL user-facing copy in the product: UI strings, labels, buttons, empty states, errors, help text, and the helper/assistant's on-screen words. Use this whenever you write or edit text a person reads on screen (anything in ui/web/, or copy in a handler/skill that surfaces to a user). The one job: say less, plainly — name things as they are, cut words, and keep the invented vocabulary out. Full audit + before→after in docs/handoffs/web-ui-copy.md.

Maintain lanius docs/ progressive-disclosure indexes and useful docs-to-code/code-to-doc references. Use when adding, reorganizing, or auditing docs/ README indexes, AGENTS.md docs guidance, or references between design docs and implementation files.

QA the lanius web dashboard (ui/web) by driving the real UI in a headless browser against an isolated live stack, asserting DURABLE state and reading the backend log. Use when changing ui/web (server.mjs, src/App.tsx, src/api.ts, src/styles.css), when a UI gesture "does nothing"/flashes/feels unconfirmed, before merging web-UI changes, or to add/run a configuration-flow regression. Catches the class of bug HTTP 200s hide: silent edit loss, feedback that flashes and vanishes, dead UI affordances.

Estimate your work right after you plan, then count actuals against it and retro on the miss. Use `lanius estimate set` once your plan is set (dollars/turns/tokens/wall-clock), `lanius estimate actual` to see the variance, and let the Stop hook (or this package's cron) record the miss into a durable learned block so the next estimate improves.

How lanius works — topic planes and their delivery contracts, the mailbox model, grants vs leases, the cage and the camera. Read this before doing anything clever with the harness.

The knowledge base's caretaker — a no-LLM script sweep (pointers, orphans, staleness) plus a setup-gated auto-approve diff pipeline (compactor proposes, ratifier ratifies). Read this to SET UP the pipeline.

The edit→re-review loop for changing the harness — how to build or modify packages so your changes actually land, and why every edit goes back through human review.

Wake yourself later — schedule a one-shot self-message with the bus primitive if you have one, or fall back to the machine's own timers (at/launchd/sleep) if you don't. Know which you are.

What to do when you share a working tree with other coding sessions — how to see what each sibling is doing and when it was last active (sibling-status), figure out which uncommitted changes are yours vs theirs (whose-change), ask a live sibling a question and wait for the answer (ask-sibling), and the decision tree for resolving a tangle without clobbering another agent's work (resolve-sibling-conflict). Read this the moment `git status` shows changes you don't recognize, before committing/stashing in a shared tree, or when the [lanius siblings] note says another session is active.

When you lack a capability the task needs — a knowledge base, tool, skill, stage, MCP server, or harness — call the find_capability tool. It searches packages you DON'T have enabled and tells you which one carries what you need, what enabling it would add, and how to request it. Discovery's own existence is high-availability; the mechanics here are expando.

Explain what a dead session was doing — dispatch a read-only reader agent at the history of a past session (what it touched, why) and get a mailed-back explanation. It explains intent; it cannot change course.

The reconstruction view — answers read-only history queries (agents, sessions, transcripts, conversations, search with filter/projection/pagination) over local HTTP from the sqlite truth.

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.

Launch lanius agents yourself — discover profiles and packages with `lanius agent catalog`, then run (blocking) or spawn (durable, async). Native agents use the launch_agent tool; coding workers use `lanius code`. Covers launch-time --with-package and --provider.

Re-pings unanswered human asks (capped) until answered, expired, or a delivery receipt shows a human already saw it on some channel.

Local line-file ingress bridge — drop text into its inbox and it becomes harness work; the testable template for real ingress adapters.

Hand a task to the architect — a stronger model with a bigger budget — instead of grinding past your depth. One emit_event; know when to use it.

Keep durable notes for the human under notes/ in the harness root. Use when asked to remember, log, or write something down for later.