Skip to main content
Generaljoeyhipolito

telegram-channel

Handles inbound Telegram messages as orchestrator commands when running with --channels plugin:telegram@claude-plugins-official

Stars
59
Source
joeyhipolito/nanika
Updated
2026-05-07
Slug
joeyhipolito--nanika--telegram
View on GitHubRaw SKILL.md

// install — copy + paste into any project

mkdir -p .claude/skills && curl -fsSL https://raw.githubusercontent.com/joeyhipolito/nanika/HEAD/.claude/skills/channels/telegram/SKILL.md -o .claude/skills/telegram.md

Drops the SKILL.md into .claude/skills/telegram.md. Works with Claude Code, Cursor, and any agent that loads SKILL.md files from .claude/skills/.

Telegram Channel Skill

When running as a Telegram channel session, this skill teaches you how to handle inbound messages from Telegram and route them to orchestrator commands.

Session Context

You are running as a long-lived Claude Code session with --channels plugin:telegram@claude-plugins-official. Messages arrive as <channel source="telegram" ...> events. You have access to the reply tool to send responses back to Telegram.

Command Routing

Interpret inbound messages and map them to orchestrator actions:

User Intent Action
Task-like request ("research X", "build Y", "compare A vs B") Confirm with user, then orchestrator run "<task>"
"status" or "what's running" orchestrator status
"metrics" or "how did it go" orchestrator metrics --last 5
"cancel " or "stop" orchestrator cancel <id>
Question about codebase Answer directly, no orchestrator call
Unclear intent Ask for clarification

Response Rules

  1. Keep it short. Telegram messages render on phone screens. Max 4096 chars per message.
  2. Use monospace for IDs and commands. Wrap mission IDs, phase names, and CLI output in backtick blocks.
  3. No wide tables. Use vertical key-value layout instead.
  4. Confirm before launching missions. Never auto-run orchestrator run — always confirm the task with the user first.
  5. Reply immediately with mission ID. After orchestrator run, reply with the mission ID and phase plan. Don't wait for completion — the daemon notifier handles progress updates.
  6. Chunk long output. If output exceeds 4000 chars, break into multiple replies.

Example Flows

Mission Launch

User: research the best practices for Go error handling
You: I'll create a mission for that. Running:
     orchestrator run "research Go error handling best practices" --no-review

     Mission 20260322-abc123 started
     3 phases: research → synthesize → write-report

Status Check

User: status
You: Active missions:
     `20260322-abc123` — research Go error handling (phase 2/3: synthesize)
     `20260322-def456` — completed 5m ago

Voice Message Handling

When a voice message arrives (attachment with audio MIME type like audio/ogg, audio/mpeg, audio/mp4, audio/wav):

  1. Download the attachment using download_attachment(chat_id, message_id)
  2. Transcribe it: elevenlabs transcribe --input <downloaded_path>
  3. Use the transcription as the message content — process it exactly as if the user had typed it
  4. Reply with a brief confirmation of what you heard before acting on it

Example:

[Voice message arrives]
→ download_attachment(chat_id, message_id) → /tmp/voice_123.ogg
→ elevenlabs transcribe --input /tmp/voice_123.ogg → "check the status of my running missions"
→ Reply: "Got it — checking mission status..."
→ orchestrator status
→ Reply with results

If elevenlabs CLI is not available, reply: "Voice transcription unavailable. Please send a text message instead."

What NOT To Do

  • Don't run missions without user confirmation
  • Don't send raw JSON or unformatted CLI output
  • Don't repeat the daemon's push notifications (it handles progress updates separately)
  • Don't attempt to edit or cancel missions without explicit user request