draft-message

起草 Telegram 消息（通过 Saved Messages）

向用户的 Saved Messages 发送一条消息，供用户查看、按需编辑，然后复制粘贴到目标聊天的编辑区再发送。Saved Messages 是每个 Telegram 账号内置的与自己的私人聊天，会在所有客户端之间自动同步。

为什么使用 Saved Messages，而不是 MTProto 云端草稿？ 官方 Telegram 客户端存在一个已知且尚未修复的竞态条件（tdesktop#29111，已以“not planned”关闭）：本地的空草稿状态会悄悄覆盖通过另一个授权发出的 SaveDraftRequest 推送到云端的草稿。我们在实际使用中观察到了这个问题：服务器确认了草稿，但用户的编辑区仍然是空的。Saved Messages 完全避开了这个问题——完整的 HTML 格式会得到保留，而且 Telegram 原生支持在编辑区之间复制粘贴，可在 iOS、Android、Desktop 和 Web 之间保留富文本。

自我迭代技能：此技能会在使用过程中不断改进。如果说明有误、参数发生变化，或需要采用变通方法，请立即修复此文件，不要拖延。仅针对真实且可复现的问题进行更新。

何时起草，何时发送

情况	使用
Agent 自主撰写的长消息或多段消息	起草 — 让用户先检查，再发送
消息包含敏感措辞（招聘、解雇、合同条款）	起草 — 一个错字或错误的名字代价很高
语气很重要的回复（回复同事或外部人士）	起草 — AI 生成的语气可能会有细微偏差
简短确认、状态更新、常规回复	发送 — 起草带来的不便大于其价值
自动通知、警报、定时提醒	发送 — 无需人工参与
时间紧迫，起草→审核→发送的往返流程太慢	发送 — 接受风险

不确定时的默认选择：起草。用户随时可以轻点一下发送；如果消息有误，用户无法撤回，只能之后编辑或删除。

预检

起草前，确认会话已获授权（不能只检查文件是否存在）：

bun "$SCRIPT" check-auth

如果为 EXPIRED，请先运行 /tlg:setup。

用法：tg-cli.ts draft

/usr/bin/env bash << 'DRAFT_EOF'
ROOT="$(cc-plugin-root tlg)"
SCRIPT="$ROOT/scripts/tg-cli.ts"

# Draft a plain-text message labelled for a group
bun "$SCRIPT" draft -1003958083153 "Plain text draft goes here"

# Draft an HTML-formatted message
bun "$SCRIPT" draft --html -1003958083153 "<b>Bold heading</b>

Body text with <code>inline code</code> and a <a href=\"https://example.com\">link</a>."

# Draft labelled for a user
bun "$SCRIPT" draft @someusername "Quick question: does this framing land right?"
DRAFT_EOF

recipient 参数仅用于在 Saved Messages 中标记草稿横幅，并非消息的发送目的地。消息始终会发到已授权账号自己的 Saved Messages。此标签可帮助用户识别每条累计保存的草稿是发给哪个聊天的。

草稿在 Saved Messages 中的显示方式

每份草稿会发送两条消息：

1. 标题横幅 — <b>Draft → <chat name></b>（如果无法解析聊天名称，则使用原始收件人标识符）
2. 正文 — 按要求设置了格式的草稿内容

将标题与正文分开发送，用户就可以只长按正文，点按复制，然后干净地粘贴到目标聊天的编辑区，无需删去横幅内容。

AI Agent 的工作流模式

1. 在回复中撰写消息
2. 调用起草命令——消息会出现在用户的 Saved Messages 中，而不是目标聊天中
3. 告知用户：“发给 <chat name> 的草稿已保存到你的 Saved Messages。打开 Saved Messages → 长按正文 → 复制 → 粘贴到目标聊天的编辑区 → 检查 → 发送。”
4. 由用户执行复制粘贴；用户既是发送者，也是最终审核者
5. 如需修改，请在发送前于目标聊天的编辑区中完成

草稿是为审核者提供的安全网——在 AI 撰写内容与用户发布内容之间有意留出一段暂停时间。

参数

参数	类型	描述
recipient	string/int	目标聊天 ID/用户名 — 仅用于标注“已保存的消息”横幅
message	string	草稿文本（必填）
--html	flag	将消息解析为 HTML（粗体/代码/链接）
-p/--profile	string	账户配置（默认值为 eon）

行为详情

• 草稿会追加，不会替换。 每次调用 draft 都会向“已保存的消息”发送一个新的 (header, body) 对。较早的草稿仍显示在上方，用户可以根据位置判断哪条是最新的。
• 长草稿会自动拆分。 根据 Telegram 的 4096 字符硬性限制，正文会自动按每段约 3900 个纯文本字符拆分。拆分位置优先选择 ━━━━━━━━━━━━━━ 分隔符，其次是段落分隔处，再次是换行处。每个续篇部分都会标注 <i>(Part N/M)</i>。完整算法请参阅 send-message SKILL.md 中的“长消息自动拆分”。
• 格式会端到端保留。 HTML 输入 → 渲染后的“已保存的消息”条目 → 复制 → 在目标聊天的编辑区域中粘贴后渲染。
• 不会出现云端草稿竞态条件。 “已保存的消息”是普通聊天，因此消息会通过常规同步路径传播，不会受到本地空草稿覆盖漏洞的影响；该漏洞会导致 SaveDraftRequest 不可靠。
• 从目标聊天的角度看是静默的。 目标聊天中的任何人都不会收到通知或看到任何提示；只有用户手动粘贴并发送后，目标方才会知晓。

反模式

反模式	失败原因
消息简短且是套话时仍使用草稿功能	浪费用户时间 — 用户本可以直接发送并在编辑区域中修改
短时间内连续起草多条消息	“已保存的消息”会堆满过时草稿；难以判断哪条是当前版本
使用草稿功能发送有时效性的警报（停机、服务中断）	用户可能数小时后才打开“已保存的消息”
声称草稿已“发送到群组”	应明确说明：“草稿已保存到‘已保存的消息’，供你审阅”，而不是“消息已发送”
忘记告知用户将草稿粘贴到目标聊天中	如果用户不知道下一步该做什么，草稿就会永远留在“已保存的消息”中

错误处理

错误	原因	修复方法
Cannot find any entity	用户名/聊天 ID 无效	标签会回退为原始标识符 — 草稿仍会保存到“已保存的消息”
Session expired	会话已失效	运行 /tlg:setup

与其他 TLG 技能的关系

• send-message — 无需人工审核时使用；包含针对已发送消息的编辑与补充原则
• draft-message（本文）— 发送前需要人工审核时使用
• search-messages — 起草回复前检查现有聊天上下文时很有用

执行后反思

此技能完成后，关闭前请检查：

1. 草稿是否已保存到 Saved Messages？ 请用户检查其 Saved Messages，以确认这一点。
2. 用户是否成功粘贴到了目标聊天中？ 如果粘贴后格式错乱，请报告具体客户端（iOS/Android/Desktop/Web），以便在再次出现回归问题时，在 Behavior Details 部分更新针对该客户端的注意事项。
3. 选择草稿而不是发送是否合适？ 如果用户立即复制粘贴并发送，且没有编辑，那么准备草稿就多此一举了——下次处理类似消息时，可考虑直接发送。

只有在问题确实存在且可复现时，才更新此 SKILL.md。