`, ``, ``, bold headers, inline code, or markdown-style `**bold**` / `` `code` ``, you MUST either pass `--html` (and translate markdown → HTML tags first) or strip the decoration. Sending Telegram-style markdown without `--html` renders the asterisks and backticks literally to the recipient. For multi-section messages with headers, separators, and code spans — **always** use `--html`.
>
> Recovery pattern when you've already sent a mangled message: send a follow-up prefixed `Correction — earlier message rendered as raw text, corrected version below:` then the correctly-HTML-formatted content. Do NOT silently edit if the message has been read (see "Editing Discipline" below).
```bash
/usr/bin/env bash << 'SEND_EOF'
ROOT="$(cc-plugin-root tlg)"
SCRIPT="$ROOT/scripts/tg-cli.ts"
# Default: plain text (use only for single-line unformatted messages)
bun "$SCRIPT" send @username "Hello"
# HTML formatting — the recommended default for any structured message
bun "$SCRIPT" send --html -1003958083153 "Bold header
Body with inline code and a link."
# By chat ID (groups use negative IDs)
bun "$SCRIPT" send -1003958083153 "Hello group"
# Specific profile
bun "$SCRIPT" -p missterryli send @username "Hello"
# Edit a message by ID
bun "$SCRIPT" edit -1003958083153 12345 "Updated text"
# Delete a message by ID
bun "$SCRIPT" delete -1003958083153 12345
SEND_EOF
```
**Long HTML messages**: `tg-cli.ts send --html` auto-splits at the 3900-plain-char threshold. Compose the full HTML as one string and let the splitter handle it. See "Auto-split for long messages" above.
### Editing Discipline — unread vs. read
**The core principle**: edit silently only when you are confident the recipient has NOT read the message yet. Once someone has seen a message, editing it risks creating a false record and confusing them (they remember the original text; the chat now shows different text).
| Situation | Action |
| ------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------- |
| You sent a message <30s ago in an active async chat and nobody has touched Telegram since | **Edit is safe** — iterate freely |
| You just sent a message with a typo or factual error and the recipient has not responded | **Edit is safe** — they likely have not read it yet |
| The recipient has replied to your message | **Do NOT edit silently** — send a supplement |
| The recipient has read the message but not yet replied (you see read receipts or their typing indicator came/went) | **Do NOT edit silently** — send a supplement |
| You're not sure whether the recipient has read it | **Default to supplement** — safer than confusing them |
| The message has been cited or quoted by others in the chat | **Do NOT edit** — the citation is now stale context; supplement instead |
**Supplement pattern** (when edit is unsafe):
```
Correction on my previous message:
```
or
```
Update to what I said above:
```
Make the supplement self-contained so a reader scrolling back understands without having to cross-reference.
**Why this matters**: silent edits of read messages are one of the most confusing UX anti-patterns in chat systems. The recipient remembers "Terry told me X", sees "X'" now, and wonders if their memory is wrong or if they're being gaslit. Edits are a privilege to use before observation, not to rewrite history.
**How to tell if it's been read**: Telegram's MTProto exposes read receipts in 1:1 and small group chats via `messages.readHistoryOutbox` updates, but in large groups this is unreliable. The safest heuristic is time + activity: if more than ~60 seconds have elapsed and/or the recipient has been active in the chat, assume they saw it.
## Telegram HTML Formatting Reference
GramJS uses HTML, not Markdown:
| Tag | Renders As |
| ------------------------------- | ----------------- |
| `text` | **Bold** |
| `text` | _Italic_ |
| `text` | Underline |
| `text` | ~~Strikethrough~~ |
| `text` | `Inline code` |
| `text
` | Code block |
| `text` | Hyperlink |
| `text` | Spoiler |
### Horizontal separator rules (enforced convention)
Use `━` (U+2501) for horizontal rules between sections in long messages.
**Length rule**: **14 characters preferred, 22 characters absolute maximum.**
- **Preferred**: `━━━━━━━━━━━━━━` (14 × `━`)
- **Acceptable ceiling**: `━━━━━━━━━━━━━━━━━━━━━━` (22 × `━`, = 14 + 8)
- **Never exceed** 22 characters — longer separators look visually unbalanced on mobile clients and push body content off-screen.
Rationale: Telegram's mobile client reflows body text but does NOT wrap separator lines of box-drawing characters. A 28-char separator forces horizontal scrolling on narrow phones; 14 char fits cleanly in every viewport and still reads as a clear section break. If you need more visual weight, use a heading (`...`) above the separator rather than making the separator longer.
Emojis are supported but user may prefer decorations without emojis — use `` blocks and box-drawing characters instead.
## Profiles
| Profile | Account | User ID |
| --------------- | ------------------ | ---------- |
| `eon` (default) | @EonLabsOperations | 90417581 |
| `missterryli` | @missterryli | 2124832490 |
## Known Group Chat IDs
| Group | Chat ID | Type |
| ---------------------- | -------------- | -------------------------------------------------------------- |
| Terry & MD (Bruntwork) | -1003958083153 | Supergroup |
| Terry & MD (Bruntwork) | -1003958083153 | Legacy basic chat (pre-2026-04-16, read-only for old messages) |
## Topic Registry (Bruntwork Supergroup)
To send a message to a specific topic, pass `reply_to=` in `send_message()` or use `--reply-to` in tg-cli.ts.
| Topic | root_msg_id | Scope |
| -------------------------- | ----------- | ------------------------------------------------------ |
| General | 1 | Catch-all, quick questions |
| Assignments & Deliverables | 2 | Task definitions, PR reviews, Block check-ins |
| Daily Operations | 3 | Commencement/disembarkation, shift status |
| Onboarding & Access | 4 | Repo access, SSH/Tailscale, tool provisioning |
| Policy & Standards | 5 | cc-skills carve-out, conventions, discipline |
| Bug Reports & Incidents | 6 | Merge conflicts, hook bugs, pipeline breaks |
| Tool Setup & Config | 7 | ccmax-monitor, FlowSurface, chronicle pipeline |
| Knowledge Base & Learning | 8 | KB pages, research material, skill references |
| HR & Scheduling | 9 | Shift hours, Bruntwork coordination |
| Session Monitor | 185 | Real-time Claude Code session summaries (CC Nasim Bot) |
## Anti-Patterns (NEVER DO)
| Anti-Pattern | Why It Fails |
| --------------------------------------------------- | -------------------------------------------------------------------- |
| Running `bun "$SCRIPT"` without checking auth first | If session expired, auth will fail |
| Checking only session file existence in preflight | Session file can exist but be expired — must check with `check-auth` |
| Using plain text for formatted messages | GramJS uses HTML, not Markdown. Use `--html` flag for formatting |
## Error Handling
| Error | Cause | Fix |
| ------------------------- | ----------------------- | ----------------------------------------------------------- |
| `Unknown profile` | Invalid `-p` value | Use `eon` or `missterryli` |
| `Cannot find any entity` | Bad username/ID | Verify with `dialogs` command or use `find-user` to resolve |
| `message cannot be empty` | Empty string passed | Provide message text |
| `Session expired` | Session no longer valid | Run `/tlg:setup` to re-authenticate non-interactively |
## Post-Execution Reflection
After this skill completes, check before closing:
1. **Did the command succeed?** — If not, fix the instruction or error table that caused the failure.
2. **Did parameters or output change?** — If tg-cli.ts's interface drifted, update Usage examples and Parameters table to match.
3. **Was a workaround needed?** — If you had to improvise (different flags, extra steps), update this SKILL.md so the next invocation doesn't need the same workaround.
Only update if the issue is real and reproducible — not speculative.