From tts-tg-sync
Start, stop, or restart the Telegram sync bot process. TRIGGERS - start bot, stop bot, restart bot, bot process, bot status, bot control.
How this skill is triggered — by the user, by Claude, or both
Slash command
/tts-tg-sync:bot-process-controlThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Start, stop, restart, and monitor the Telegram sync bot process. Provides lifecycle management for the `bun --watch` bot runner with process verification and log access.
Start, stop, restart, and monitor the Telegram sync bot process. Provides lifecycle management for the bun --watch bot runner with process verification and log access.
Platform: macOS (Apple Silicon)
Self-Evolving Skill: This skill improves through use. If instructions are wrong, parameters drifted, or a workaround was needed — fix this file immediately, don't defer. Only update for real, reproducible issues.
~/.claude/automation/claude-telegram-sync/~/.claude/.secrets/ccterrybot-telegramShow current bot process state using pgrep:
pgrep -la 'bun.*src/main.ts'
If no output, the bot is not running. If multiple lines appear, there are duplicate instances that need cleanup.
Use AskUserQuestion to determine the desired action:
bun --watchIn production, launchd manages the bot via a compiled Swift runner binary. The runner uses bun --watch, so code changes auto-restart the service.
Restart (production — kill bun, Swift runner respawns it):
pkill -f 'bun.*src/main.ts'
sleep 2
pgrep -la 'bun.*src/main.ts'
Stop (full — kills both runner and bun):
pkill -f 'telegram-bot-runner'
pkill -f 'bun.*src/main.ts'
Start (production — via launchd):
launchctl kickstart -k gui/$(id -u)/com.terryli.telegram-bot
Start (ad-hoc — shell session, for debugging):
cd ~/.claude/automation/claude-telegram-sync && bun --watch run src/main.ts >> /private/tmp/telegram-bot.log 2>&1 &
Logs:
tail -50 /private/tmp/telegram-bot.log
# Or structured logs:
tail -50 ~/.local/state/launchd-logs/telegram-bot/stderr.log
Confirm the process state changed as expected:
pgrep -la 'bun.*src/main.ts'
1. [Check] Show current bot process status with pgrep
2. [Action] Present start/stop/restart/logs options via AskUserQuestion
3. [Execute] Run the selected action command
4. [Verify] Confirm process state changed as expected
5. [Logs] Optionally tail recent logs for confirmation
6. [Done] Report final process status to user
| Issue | Cause | Solution |
|---|---|---|
| Bot not running | Process crashed or was never started | Check with pgrep, runner should auto-respawn; if runner also dead, launchctl kickstart |
| Multiple instances | Previous stop did not fully terminate | pkill -f 'telegram-bot-runner'; pkill -f 'bun.*src/main.ts', then restart via launchd |
| Code changes not picked up | Bot started without --watch | Kill bun process — runner respawns with --watch; or recompile runner if it's outdated |
--watch not reloading | File outside watch scope changed | bun --watch monitors the entry file's dependency tree; config-only changes (mise.toml) need a kill |
| Logs not writing | Log directory missing or permissions | Verify ~/.local/state/launchd-logs/telegram-bot/ exists and is writable |
| bun not found | mise shims not in PATH | Runner sets PATH explicitly; recompile runner if shims path changed |
| Bot starts but crashes immediately | Missing env vars or secrets | Check ~/.claude/.secrets/ccterrybot-telegram exists; verify mise.toml env section |
bun --watch design rationaleAfter this skill completes, reflect before closing the task:
npx claudepluginhub terrylica/cc-skills --plugin tts-tg-syncGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Synthesizes the current conversation into a structured spec (PRD) and publishes it to the project issue tracker with a ready-for-agent label, without interviewing the user.