메뉴
Bridge a harness agent onto Telegram — turn inbound chat messages into `harness::send` turns and stream assistant output, model pickers, and inline tool-call approvals back into the chat.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | telegram-bot |
| description | Bridge a harness agent onto Telegram — turn inbound chat messages into `harness::send` turns and stream assistant output, model pickers, and inline tool-call approvals back into the chat. |
The telegram-bot is a bridge between a Telegram bot and the harness agent
stack. It owns the Telegram UX — slash commands, model-picker keyboards, live
message edits, and approval prompts — and delegates turn execution, streaming,
and durability to harness, session-manager, and approval-gate. Inbound
text becomes a harness::send turn; the assistant's output flows back as
Telegram messages. It is not a general bot framework and exposes no scriptable
"send a message" surface of its own.
Reach for it to put an existing harness agent in front of Telegram users.
Prerequisites: the sibling stack installed (harness session-manager llm-router context-manager approval-gate) and a telegram-bot configuration entry with
a bot_token. A model is chosen per chat through the /start picker or fixed
with default_model; the agent only gets the tools you grant via
functions_allow. Update ingress is either long-polling (default, no public
URL) or an HTTPS webhook, and every config field hot-reloads.
chat_id ↔ session_id mapping for;
a turn on an unrelated session produces nothing in Telegram.harness and
approval-gate; this worker is only the Telegram surface. Deploying it without
the sibling stack is unsupported.HTTP-triggered (operator/ingress only — not agent-callable):
telegram-bot::webhook — receive a Telegram update in webhook mode and
route commands, messages, and callback queries.telegram-bot::set-webhook — register the configured webhook URL with
Telegram.Internal bindings (auto-registered against sibling triggers; not called directly):
telegram-bot::on-message-added — post each new assistant or
function_result entry into the chat (from session::message-added).telegram-bot::on-message-updated — stream throttled assistant edits (from
session::message-updated).telegram-bot::on-status-changed — show a typing indicator while the
session is working (from session::status-changed).telegram-bot::on-turn-completed — finalize streaming, post the outcome
toast, and drain the FIFO queue (from harness::turn-completed).telegram-bot::on-pending-created — show an inline approval keyboard for a
held call (from approval::pending-created).telegram-bot::on-pending-resolved — clear the approval prompt once the
call resolves (from approval::pending-resolved).telegram-bot::on-config-change — hot-reload configuration.The worker registers no trigger type for others to bind. It is a bidirectional bridge between one Telegram chat and one harness session, and that round-trip is the whole job.
Inbound: a Telegram update arrives by long-poll or webhook and lands in the
telegram-bot::webhook handler. Slash commands are handled locally; any other
text is sent to harness::send with the chat's session, the selected model, the
composed system prompt (built-in Telegram channel context per channel_context
plus the configured system_prompt, sent per system_prompt_mode), and the
functions_allow policy. The first message in a chat mints the session id
bot-side and persists a chat_id ↔ session_id mapping; later messages continue
that session until the next /start.
Proactive outbound: the agent can reach the user out-of-band via
telegram-bot::notify (session-scoped), e.g. a cron-bound reminder targeting
this session.
Outbound: as the turn runs, session-manager, harness, and approval-gate
emit events. The worker's bound handlers consume them and render into the
originating chat — resolving which chat by looking the session up in the
chat_id ↔ session_id mapping. Assistant text streams via message edits (or
native drafts) and is finalized on harness::turn-completed.
Reminder round-trip: a user asking the bot to "remind me at 5pm" gets an
immediate reply in the same turn — that is just the normal inbound-to-outbound
path. The later notification is a second turn: when the time comes, something
must call harness::send on that same chat-bound session_id, and its assistant
output then streams back through the same bindings. Because this worker has no
scheduler and no push API, the timing lives elsewhere (an external scheduler,
cron, or another worker that holds the session_id); the bridge's only role is
routing that session's output back to the chat.
Run Unix commands and structured filesystem ops from the iii engine: exec, background jobs, and a structured fs (ls/stat/mkdir/rm/chmod/mv/grep/sed/ read/write, jailed only if fs.host_roots is configured), all forwardable into a sandbox microVM.
Shared, adapter-backed key/value store addressed by scope and key, with a reactive `state` trigger so other functions can run on every create, update, or delete without polling.
Durable topic queues for iii: subscribe functions to topics, publish work asynchronously, retry failed deliveries with backoff, and inspect/redrive dead-lettered messages.
Mint isolated git worktrees for parallel agent work, track ownership in a cross-agent registry, and land finished branches back onto a target with a queued rebase, test gate, and atomic fast-forward merge.
Connect this engine to another iii engine over a long-lived WebSocket so functions call across the boundary. Wire stable ids with `forward:`/`expose:`; `bridge.invoke` is the ad-hoc escape hatch.
Drive Devin over the iii bus. Run the local Devin CLI agent (SWE-1.6) with the iii runtime context so it discovers and operates your mesh, or start and steer autonomous Devin cloud sessions through the REST API, with a passthrough to any Devin v1/v3 endpoint.