القائمة
Discord ingress bridge (UNTESTED scaffold) — gateway messages become in/dm/discord/<channel-id> conversation ingress; in/package/discord/send posts replies with delivery receipts.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | discord |
| description | Discord ingress bridge (UNTESTED scaffold) — gateway messages become in/dm/discord/<channel-id> conversation ingress; in/package/discord/send posts replies with delivery receipts. |
Status: untested scaffold. Written without a live token; the structure follows packages/linemux (the tested template) but the gateway handling has not seen a real connection. Treat the first live run as a debugging session.
Setup: DISCORD_TOKEN in the daemon's environment, pip install websockets,
copy this package onto the package path, lanius approve discord.
Flow: gateway MESSAGE_CREATE → in/dm/discord/<channel-id> (ledger,
published once — the canonical conversation address recall keys on; the
channel id is the address, 1:1 and group alike, Handoff B). Any handler
subscribing in/dm/# (or in/dm/discord/#) receives it. The in/dm/discord/#
publish grant is the ingress-bridge capability the broker ACL requires — only
an owner-approved manifest may hold a dm-scoped grant. Outbound: emit
in/package/discord/send with {channel_id, content}; the bridge posts it
and publishes an obs/channel/discord/sent receipt. Unconfigured, the actor
parks instead of crash-looping; the supervisor still shows it alive in
obs/package/discord/status.
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.
