Menu
Telegram: send/receive messages; reply to source=telegram notifications. Requires daemon.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Use for any Microsoft account, personal or work (Outlook.com, Hotmail, Live, Microsoft 365); preferred over email-client for Microsoft accounts. Graph-based mail (read/send/reply/forward, drafts, flag/categorize, move/archive, folders, attachments, block senders), calendar and meetings, Microsoft Teams (chats, channels, presence), and new-mail/Teams notifications. Requires daemon.
Browse, navigate, click, fill forms, screenshot, or scrape web pages with a stealth (Camoufox) browser.
Design judgment and UI copy for building Vesta dashboard widgets that feel considered rather than templated, within the fixed design system.
Use before building or modifying the user's dashboard: widgets, pages, layouts, custom UI. Understand what the user wants, design it, write a spec, then dispatch the dashboard-builder to build it.
Use when someone who doesn't have their own vesta asks what vesta is, how to get one, or hints they want in. Vesta is invite-only: you gatekeep and build desire through scarcity, draw out what they want, then sell vesta as indispensable to their goals and set them up end-to-end in chat. Not for the owner, who already has one.
Talk to vestad, the host daemon that runs this container. Register a background service to get a port, build public URLs, update vestad to the latest release, check its version, and read gateway logs. Use when a skill needs an inbound port or a shareable link, when the user asks to update Vesta, or when debugging gateway/container issues.
| name | telegram |
| description | Telegram: send/receive messages; reply to source=telegram notifications. Requires daemon. |
Setup: See SETUP.md
Daemon: telegram daemon start|stop|restart|status. Start is idempotent; stop/restart quit the watchdog first so it cannot race a manual restart into two daemons. Manage the daemon only through these commands, never raw screen.
# The one shape to use for any message body. Replace only the middle line.
telegram send --to '<contact_name>' --message - <<'MSG'
can't wait to see you
MSG
telegram send --to '<contact_name>' --message - --reply-to '<message_id>' <<'MSG' # quote a message
same here
MSG
telegram send '<contact_name>' '<a brief or list they asked for>' --longform # bypass short-bubble lint
telegram chats
telegram contacts
telegram messages --to "<contact_name>" --limit 20
telegram groups
telegram react '<contact_name>' '<message_id>' '👍'
telegram send-file --to "<contact_name>" --file-path /path/to/document.pdf
telegram send-voice --to "<contact_name>" --file-path /path/to/note.ogg
People change their minds after they hit send, so a message you already read can change. An edit arrives as an edit notification whose body carries what the message says now, just like a plain message, naming the message that changed (target_message_id) and the text you last saw (old_text). The stored message is rewritten, so list-messages and search show only the new text. Answer again only if the edit asks something new: a fixed typo needs nothing from you. Deletions are invisible here, Telegram never tells a bot that a message was deleted.
Send tappable buttons, get notified when the owner taps, then answer the tap and/or edit the message in place. This is the full "dynamic UI" loop: menus, confirm/deny prompts, live-updating status messages.
# 1. Send a message with an inline keyboard.
# --buttons format: rows separated by ';', buttons within a row by ',',
# each button is "Label=callback_data" (or "Label=url:https://..." for a link button).
telegram send 'Elio' 'Approve the draft?' --buttons 'yes=approve,no=reject;edit first=edit'
# 2. The owner taps a button → a notification arrives:
# {"source":"telegram","type":"callback_query","data":"approve",
# "callback_id":"...","chat_id":...,"message_id":...}
# 3. Answer the tap (stops the button's loading spinner; --text shows a toast, --alert a popup).
telegram answer-callback '<callback_id>' --text 'approved ✓'
# 4. Optionally edit the message in place to reflect the choice (and drop/replace the buttons).
telegram edit-message 'Elio' '<message_id>' 'Approved ✓' [--buttons '...']
telegram delete-message '<to>' '<message_id>' # unsend
telegram send-chat-action '<to>' typing # transient "typing…" status
telegram pin-message '<to>' '<message_id>' [--silent]
telegram unpin-message '<to>' ['<message_id>'] # omit id to unpin latest
Notification types written for the agent: message, callback_query (button tap), reaction
(inbound reactions are not decoded by the v5 library, so they don't currently fire; sending
reactions via react works). Aliases: send/edit/del/voice/action/pin/unpin.
send-message enforces short-bubble texting: a wall (over ~220 chars, or any text after a full stop) is rejected so you re-send as several short calls, one thought each. Don't use full stops at all: a ., ! or ? may only close a bubble, never carry text after it. Ellipses stay free, they're a beat rather than a stop. For genuine reference material the user asked for (a brief, a code block, a list), pass --longform to bypass. Heredoc sends are linted too, so --longform is the only escape hatch.1. or 2) is not a full stop, so a list does not need --longform.123456789 for private, -1001234567890 for groups)/start the bot before it can message them/usr/local/bin/telegram~/.telegram/~/.telegram/bot-token[How the user prefers to communicate with different contacts]