40 lines
1.5 KiB
Markdown
40 lines
1.5 KiB
Markdown
---
|
|
name: telegram-ops
|
|
description: Set up, validate, and operate Telegram messaging in OpenClaw. Use when adding Telegram, debugging delivery/replies, mapping chat IDs, validating channel/account routing, or creating Telegram notification workflows with low-noise test sends.
|
|
---
|
|
|
|
# Telegram Ops
|
|
|
|
## Operating policy
|
|
|
|
1. Use first-class OpenClaw messaging tools only.
|
|
2. Explicitly set `channel: telegram` when channel ambiguity exists.
|
|
3. Ask before messaging a new target/chat.
|
|
4. Run one minimal test send per change, then stop.
|
|
5. Record stable environment-specific routing notes in `TOOLS.md`.
|
|
|
|
## Standard workflow
|
|
|
|
1. Identify intent: setup | debug | automation.
|
|
2. Verify target metadata (chat/user id, account, expected direction).
|
|
3. Validate outbound with a short plain-text test.
|
|
4. Validate inbound reply path back to current session.
|
|
5. Summarize status and exact next action.
|
|
|
|
## Debug decision tree
|
|
|
|
- Wrong destination -> re-check target id/name and account mapping.
|
|
- No delivery -> verify channel/account selection and retry minimal payload.
|
|
- Delivery works, reply missing -> check routing/session mapping for inbound path.
|
|
- Intermittent -> reduce formatting/media, confirm with plain text, then re-add complexity.
|
|
|
|
## Output contract
|
|
|
|
Return:
|
|
|
|
- **State:** working | partial | blocked
|
|
- **Validated:** exact checks that passed
|
|
- **Failed at:** first failing step
|
|
- **Next action:** smallest user/actionable fix
|
|
- **Safety hold:** what was not sent without approval
|