tg-bot-ops

# Telegram Bot Ops Use this skill when the real question is whether a Telegram bot is receiving updates, processing them in the intended runtime, and sending visible responses to the right chat, user, or forum topic. ## Public Safety - Default to read-only diagnostics. - Do not print tokens, `.env` values, connection strings, raw logs, private DMs, payment payloads, session files, or full user records. - Use placeholders in notes and examples: `<TELEGRAM_BOT_TOKEN>`, `<TELEGRAM_USER_ID>`, `<CHAT_ID>`, `<TOPIC_ID>`, `<WEBHOOK_URL>`. - Do not send Telegram messages, restart production services, change webhooks, edit BotFather settings, or deploy until the user has authorized that exact action. - If any real secret appears in the repo, logs, or prompt, stop and tell the user it must be rotated before public release. ## Intake If the repo or runtime is unclear, identify: - bot repo and language/runtime; - deployment target: local, Docker, VPS/systemd, Railway, Render, Fly, Vercel, or other; - update mode: webhook, polling, or unknown; - env source for `TELEGRAM_BOT_TOKEN`; - expected symptom, chat surface, and timestamp; - whether production restart/deploy is allowed. ## Diagnostic Flow 1. **Repo and runtime** — inspect entrypoints, process manager, deploy files, and current git state. 2. **Environment** — verify required env var names exist without printing values. 3. **Update intake** — classify runtime: HTTP Bot API webhook, HTTP Bot API polling, MTProt...