Automates the deployment of Telegram bot integrations, pairing helpers, and validation tests into the project.

Install

mkdir -p .claude/skills/add-telegram && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/4518" && unzip -o skill.zip -d .claude/skills/add-telegram && rm skill.zip

Installs to .claude/skills/add-telegram

Activation

This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.

Add Telegram channel integration via Chat SDK.
46 charsno explicit “when” trigger
Intermediate

Key capabilities

  • →Copy Telegram adapter and helpers
  • →Register Telegram channel in core
  • →Configure bot token and environment
  • →Perform pairing handshake

How it works

It copies adapter code from a branch, registers the channel, and uses a pairing handshake to bind the bot to the service.

Inputs & outputs

You give it
Telegram bot token
You get back
Registered Telegram communication channel

When to use add-telegram

  • →Add Telegram notification support
  • →Set up Telegram as a bot control channel
  • →Migrate channel code from branches

About this skill

Add Telegram Channel

Adds Telegram bot support via the Chat SDK bridge. NanoClaw doesn't ship channels in trunk — this skill copies the Telegram adapter, its pairing helper, and their tests in from the channels branch. The pair-telegram setup step is maintained in trunk, so it is not copied here.

The mechanical steps under Apply carry nc: directive fences: an agent reads the prose and applies them, and a parser can apply them deterministically from the same document. Every directive is idempotent, so the whole skill is safe to re-run; anything a parser can't apply falls back to the prose beside it.

Re-running with a bot already configured can add a second one instead of re-pairing the first; see Add another bot under Credentials.

Apply

1. Copy the adapter, helpers, and tests

Fetch the channels branch and copy the Telegram adapter, its pairing helper (with its test), and the focused adapter tests into place (overwrite — the branch is canonical):

src/channels/telegram.ts
src/channels/telegram-pairing.ts
src/channels/telegram-pairing.test.ts
src/channels/telegram-registration.test.ts
src/channels/telegram-connect-group.test.ts
src/channels/telegram-instances-registration.test.ts
src/channels/telegram-pairing-interceptor.test.ts

2. Register the adapter

Append the self-registration import to the channel barrel (skipped if the line is already present). This one line is the skill's only reach-in into core:

import './telegram.js';

3. Register the pairing setup step

Add the pair-telegram loader to the STEPS map in setup/index.ts, inside the dormant marker region (skipped if already present — pair-telegram ships in core, so this idempotent-skips on a normal install, but is expressed for a clean-upstream rebuild). The pairing handshake below spawns this step:

'pair-telegram': () => import('./pair-telegram.js'),

4. Install the adapter package

Pinned to an exact version — the supply-chain policy rejects ranges and latest:

@chat-adapter/[email protected]

5. Build and validate

Build first: it guards the typed createChatSdkBridge(...) core call and proves the dependency is installed. Then run the focused tests.

pnpm run build
pnpm exec vitest run src/channels/telegram-registration.test.ts src/channels/telegram-connect-group.test.ts

telegram-registration.test.ts imports the real channel barrel and asserts the registry contains telegram. It goes red if the import line is deleted or drifts, if the barrel fails to evaluate, or if @chat-adapter/telegram isn't installed (the import throws) — so it also covers the dependency from step 4. End-to-end delivery against a real bot is verified manually once the service runs.

Credentials

An install that already holds TELEGRAM_BOT_TOKEN can add a second bot instead of re-pairing the first. Check which case this is; the answer steers the rest of the flow:

grep -qsE '^TELEGRAM_BOT_TOKEN=.+' .env && echo yes || echo no
[ "{{has_default_bot}}" = yes ] && echo ask || echo no

On a first install there is no bot to add another to, so add_another is no and the steps below create and configure the first bot. When a bot is already configured, ask the user whether to keep using it (no: the stored token stays as it is and the flow re-pairs that bot) or to add another one (yes: the first bot's steps are satisfied by the stored token and change nothing; the new bot is handled under Add another bot):

A Telegram bot is already configured (TELEGRAM_BOT_TOKEN in .env). Add another bot (yes), or keep using the existing one (no)?

Bot creation in Telegram is human and interactive — no parser can click through BotFather. The adapter is installed and registered, but it can't receive a message until the bot exists. On a first install, tell the user (a bot that is already configured keeps its stored token below; a second one is created under Add another bot):

Create the Telegram bot:
1. Open Telegram and message @BotFather — Telegram's official bot for creating bots.
2. Send /newbot and follow the prompts: a friendly name, then a username that must end in "bot".
3. Copy the bot token it gives you (looks like 123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11a).
4. Planning to use the bot in group chats? Send /mybots → your bot → Bot Settings → Group Privacy → Turn off, so the bot can see all messages and not just @mentions.

Collect the bot token and store it — the bridge reads it from .env (set-if-absent, so a value you've already filled in is never overwritten) and syncs it to the container:

Paste the bot token from BotFather (looks like `123456:ABC-DEF...`).
TELEGRAM_BOT_TOKEN={{bot_token}}

Confirm the token works and capture the bot's handle — getMe returns the bot account and fails here if the token is bad. You'll use the handle to open the right chat just before pairing:

curl -sf https://api.telegram.org/bot{{bot_token}}/getMe | jq -er '.result.username'

Add another bot

Only when add_another is yes. The second bot is a named adapter instance: its short name becomes the registry key telegram-<name> and, uppercased with dashes as underscores, the token key suffix (gh-bot stores TELEGRAM_BOT_TOKEN_GH_BOT). A name whose TELEGRAM_BOT_TOKEN_<NAME> key is already set is taken (storing under it would overwrite that bot's token), so it is refused:

Short name for the new bot (lowercase letters, digits, dashes; e.g. `mega`). Pick one whose token key is not already set in .env.
echo {{bot_name}} | tr 'a-z-' 'A-Z_'
! grep -qs '^TELEGRAM_BOT_TOKEN_{{bot_name_env}}=.' .env

To pair an already-configured named bot again instead (its token is stored and the service restarted, but pairing failed or was cancelled), run pnpm exec tsx setup/index.ts --step pair-telegram -- --intent main --instance telegram-<name>, then /init-first-agent with --instance telegram-<name> if it was never wired.

The second bot is created with @BotFather exactly like the first. Tell the user:

Create the second Telegram bot: message @BotFather, send /newbot and follow the prompts (its own friendly name, then a username that must end in "bot"), and copy the token it gives you. It must be a different bot from the one already configured. Planning to use it in group chats? Send /mybots → that bot → Bot Settings → Group Privacy → Turn off.

Then confirm its token with getMe as above:

Paste the second bot's token from BotFather (looks like `123456:ABC-DEF...`). It must belong to a different bot than the one already configured.
curl -sf https://api.telegram.org/bot{{bot_token_2}}/getMe | jq -er '.result.username'

A second token that resolves to the same bot as the first (its handle matches) is refused here, before anything is written: it would only start a second poller on that bot, which the adapter refuses at startup anyway.

[ "{{bot_username_2}}" != "{{bot_username}}" ]

Store the token under its suffixed key and list the name in TELEGRAM_INSTANCES, merged with the names already there. Both writes go through the set-env step, which updates an existing key and logs the key, never the value:

pnpm exec tsx setup/index.ts --step set-env -- --key TELEGRAM_BOT_TOKEN_{{bot_name_env}} --value {{bot_token_2}}
pnpm exec tsx setup/index.ts --step set-env -- --key TELEGRAM_INSTANCES --value "$({ sed -n 's/^TELEGRAM_INSTANCES=//p' .env; echo {{bot_name}}; } | tr ',' '\n' | grep . | sort -u | paste -sd, -)"

The registry key is how pairing and wiring address the new bot:

echo telegram-{{bot_name}}

Restart

Restart the service so it loads the Telegram adapter and the token you just stored, and wait for its CLI socket. The adapter must be live and polling before pairing — it's the thing that observes the code you send:

bash setup/lib/restart.sh

Pair your chat

Telegram tokens carry no user binding, so the agent proves you own the chat with a one-time pairing handshake: it issues a 6-digit code, you send those exact 6 digits to the bot from the chat you want to register, and the live adapter matches them. Open the bot first so you're on the right screen when the code appears. Tell the user:

Open @{{bot_username}} (https://telegram.me/{{bot_username}}) in Telegram now and keep it on screen — a 6-digit pairing code is about to appear in this terminal. When it does, send just those 6 digits to the bot as a message (in a group chat with Group Privacy on, prefix them with @{{bot_username}}). A wrong guess is rejected and a fresh code is issued automatically.

Run the pairing handshake. It prints the code, streams "waiting…" and wrong-code feedback while it watches for your message, and resolves your chat address telegram:<chatId> plus your Telegram user id once the code matches:


---

*Content truncated.*

When not to use it

  • →If the service is not running
  • →If the bot token is invalid

Prerequisites

Telegram bot token from BotFather

Limitations

  • →Requires manual bot creation via BotFather
  • →Does not support threads

How it compares

It uses a deterministic pairing handshake instead of manual chat ID configuration.

Compared to similar skills

add-telegram side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
add-telegram (this skill)13moReviewIntermediate
mcporter74moNo flagsIntermediate
calcom-api25moNo flagsIntermediate
dust-mcp-server12moReviewAdvanced

Try saying

Example prompts that trigger this skill in your AI assistant.

You might also like

mcporter

openclaw

Use the mcporter CLI to list, configure, auth, and call MCP servers/tools directly (HTTP or stdio), including ad-hoc servers, config edits, and CLI/type generation.

726

calcom-api

calcom

Interact with the Cal.com API v2 to manage scheduling, bookings, event types, availability, and calendars. Use this skill when building integrations that need to create or manage bookings, check availability, configure event types, or sync calendars with Cal.com's scheduling infrastructure.

216

dust-mcp-server

dust-tt

Step-by-step guide for creating new internal MCP server integrations in Dust that connect to remote platforms (Jira, HubSpot, Salesforce, etc.). Use when adding a new MCP server, implementing a platform integration, or connecting Dust to a new external service.

19

developing-genkit-tooling

firebase

Best practices for authoring Genkit tooling, including CLI commands and MCP server tools. Covers naming conventions, architectural patterns, and consistency guidelines.

27

juicebox-rate-limits

jeremylongshore

Implement Juicebox rate limiting and backoff. Use when handling API quotas, implementing retry logic, or optimizing request throughput. Trigger with phrases like "juicebox rate limit", "juicebox quota", "juicebox throttling", "juicebox backoff".

23

clay-sdk-patterns

jeremylongshore

Apply production-ready Clay SDK patterns for TypeScript and Python. Use when implementing Clay integrations, refactoring SDK usage, or establishing team coding standards for Clay. Trigger with phrases like "clay SDK patterns", "clay best practices", "clay code patterns", "idiomatic clay".

04

Search skills

Search the agent skills registry