메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | escalate |
| description | 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. |
Some work outclasses the model you're running on. The harness ships a
stronger identity for exactly that: the architect profile — a frontier
model, a high turn budget, full skill visibility. Escalating is one tool
call:
emit_event {
"type": "in/agent/architect",
"payload": {
"prompt": "<the task, self-contained — see below>",
"profile": "architect"
}
}
That's mail to the architect's mailbox; payload.profile selects its
identity for the run. The emission is deliberately uncorrelated — the
architect's run is its own flow, and its results come back as mail or as
durable artifacts, not as a reply stitched into your conversation. Fire
it and finish your own job (which may just be: report that you escalated
and to whom).
Don't escalate work that's merely long, or questions a human should
decide (authority questions go to ask_human / the owner's mailbox, not
to a bigger model).
The architect starts FRESH — sessions don't share memory. Its context is only what you put in the prompt plus what it digs up itself. Include: the goal, what you tried and what happened (paste the actual errors), file paths involved, and where to leave the result. One self-contained paragraph beats ten clarifying round trips, because there are no round trips.
The architect costs real money per run. One well-fed escalation is cheap; a vague one that has to re-discover your context is not.
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.