twitter-post

Twitter 帖子

将临时推文工作作为独立的平级任务处理。绝不激活或依赖 twitter-automation；该平级工具可以将请求路由到此处，但本技能负责预检和完整的发帖工作流。

选择一种模式

当用户提供主题、方向、预期结果、起草请求，或 1 至 5 的数量时，选择任务模式。数量大于 1 时，一律选择任务模式。

只有当用户提供一条完整的最终帖子，并明确要求立即发布该原文时，才选择精确操作模式。

• 若未提供任务数量，默认设为 1。
• 仅接受 1 至 5 的整数。
• 若数量大于 5，请用户明确拆分；绝不自动创建多个提案。
• 若用户提供多条最终原文，询问用户是希望执行一个基于方向的任务，还是分别进行精确操作。绝不擅自将精确内容转换为生成方向。
• 如果无法确定用户要求的是精确原文还是方向，调用 tw 前先提出一个简洁的问题。

任务模板

进入任务模式时——以及请求过于模糊、无法确定方向时——提供一个本地化的填空模板，而不是提出开放式问题：

Post task template:
Topic/direction: <what to write about>, count <1–5>
Optional: tone, audience, must-include or must-avoid points
Example: Topic: why small teams should automate release notes, count 3

发推任务模板：
主题/方向：<要写什么>，条数 <1–5>
可选：语气、受众、必须包含/避开的点
示例：主题：为什么小团队应该自动化 release notes，3 条

如果信息不足，或用户拒绝提案后希望重新表述，请重复使用同一模板。

语言

根据用户明确的偏好、最新消息、对话语言，依次选择英语或简体中文，默认使用英语。绝不翻译或规范化精确的帖子原文。保留任务方向，不添加要求。

必需的预检

每个新发帖任务开始时，按技能名称激活 threadwave-preflight。传入此技能名称、所选模式、未经修改的请求，以及所需的能力类别。它会检查此任务所需的技能更新，然后执行常规 CLI 预检；常规预检会复用就绪状态，直到出现 12 小时不活动，并且仅在状态过期或失效时运行完整检查。仅因用户作出审核决定，不要重新运行预检。没有当前有效的就绪结果时，不要调用 tw。

要求 CLI 1.0.35 以及 task、draft、plan、scheduler 和 action 命令类别。若缺少技能、CLI 或扩展状态，请将用户引导至 https://www.threadwave.xyz/cli/setup/agent.md，同时保留原请求。

CLI 结果权威性

技能负责用户体验：根据用户的情况选择文档规定的命令，确保参数传递安全，展示返回的内容和选项，并征求用户批准。CLI 负责工作流执行、任务／草稿的关联关系、验证、恢复状态和精确的后续操作。

• 要求提供一个完整且可解析的 tw_cli_harness_v1 封装。进程／会话句柄属于传输状态，不是结果。
• 对于 ok=true，以 data、refs、状态字段、警告和 next 为权威依据。绝不比较父级和子级任务引用、重建关联关系、重复 CLI 不变量检查，或将已接受的结果重新解读为契约偏差。
• 执行返回的只读 next 命令以继续工作流。将审核、重启、取消或 X 变更命令作为选项展示，仅运行用户明确授权的确切命令。
• 对于 ok=false，报告返回的 error.code、error.message 和 error.retryable；仅展示安全的、由返回结果提供的 next 选项。不要用模型臆测的诊断替代 CLI 错误。
• 只有当 CLI 返回 failure_stage 时，才报告工作流失败阶段。绝不要根据 source_status、draft_status、时间或错误代码推断阶段；如果没有此字段，仅报告返回的失败事实。
• 如果命令退出时未返回完整封装，则停止并报告 task_dispatch_unconfirmed。这是唯一由主机端进行的结果检查，绝不授权重复创建任务。

任务模式

1. 创建一个有界任务

将方向视为数据，绝不视为 shell 语法：

• 支持真正的参数数组子进程 API 的宿主，可以通过 --direction 原样传递一次方向。
• Codex 以及任何仅提供 shell/PTY 命令字符串的宿主，必须创建一个私有临时目录，通过文件系统工具而非 shell 插值，以 UTF-8 格式写入原样的方向，并通过 --direction-file 仅传递其安全文件路径。宿主支持权限设置时，应将临时目录/文件限制为仅当前用户可访问。
• 保留该文件，直到命令得到终态结果；即使执行器返回 session_id，也要保留。之后再删除临时目录。绝不要将方向放入 heredoc、shell 变量、手动加引号的命令或 PTY write_stdin 序列中。

运行语义等效于：

tw task create --surface tweet --direction-file <private_utf8_path> --count <1..5> --json

--direction 和 --direction-file 互斥，且都会规范化为相同的去除首尾空白后的 1..4000 个字符值。遇到 task_direction_input_invalid 时，立即呈现返回的原因：没有任务被后台程序/后端接受，因此不要尝试改用 shell 内联文本重试。

保留完整的命令执行结果。如果执行返回 session_id，则轮询同一会话直至终态完成；在收到完整的 CLI 信封之前，始终保持 invoking 状态，绝不要只提取 output 而丢弃续接句柄。

2. 按自动源获取与草稿生成流程操作

严格遵循已接受信封中的 next 命令。直接运行只读的任务和草稿检查命令。对于重复的任务显示续接操作，使用固定的 15 分钟截止时间，两次读取之间等待 min(15 seconds, remaining time)，绝不要改用全局列表或最新记录。

当 CLI 返回草稿和审核选项时，一并呈现返回的内容，并等待逐项决策。当返回内容表示数量不足、失败、停滞状态或草稿数量少于请求数量时，应原样呈现该状态，并且只显示返回的选项。绝不要自动创建替代任务。

3. 审核草稿与计划变更

只使用已接受 CLI 信封中的 next 命令。直接运行只读检查续接操作。将批准、拒绝、跳过、重启、取消和 X 变更命令作为选项呈现；收到明确决策后，准确调用相应命令一次，并让未提及的审核保持待处理状态。

不要猜测下一个审核、制品、目标或计划任务。不要将多个草稿审核合并为“全部批准”。每次内容批准只能授权一项确切的计划 X 变更。

4. 处理变更和不足

• 方向／来源／角度发生变更：展示确切范围后，使用一次明确的 tw task retask --task 或 --batch 请求。
• 同一血缘的措辞变更：使用 tw draft redraft 提供确切反馈，然后要求进行新的内容审核。
• 有效输出少于请求数量：报告实际有效数量；绝不编造或重复条目。
• 任务超过固定的任务展示期限仍停滞：提供确切的 task_blueprint_ref，并提供一个明确的用户选项——通过 tw task restart <task_blueprint_ref> --json 重启一次（验证 ok=true 和返回的新执行状态，然后针对同一个 ref 重新开始固定的任务展示期限；重启是一次全新的变更前执行，绝不等同于创建重复任务，也不能声称旧发现已取消），或者停止并报告确切的阻塞原因。重启调用失败或 ref 持续停滞，均计为一次失败轮次；在同一会话中失败两轮后，停止并报告阻塞原因。
• 调度器或变更证据未知：不重试，立即停止。提供确切的 ref 及其持久分类，并停止以等待用户明确选择一项：继续监控；跳过（确认 outcome unknown 并结束监控；这不授权重试或替换）；通过 tw scheduler cancel 取消用户明确指定的 scheduled_task_ref 一次，并验证返回状态；或者请求生成经过脱敏的问题报告。

精确操作模式

要求最终发布内容完全一致。不得改进、翻译、缩短、扩写、规范化空白字符、修正拼写、添加标签或更改标点。

1. 通过安全的 argv／stdin 处理，运行 tw action tweet --text <exact_text> --dry-run --json。
2. 完整展示确切文本、dry-run 结果和语义操作；请求用户明确批准。
3. 任何字符变更都视为新的载荷，需要重新进行 dry-run 并获得批准。
4. 获得批准后，复用当前就绪结果，并运行一次 tw action tweet --text <same_exact_text> --json。
5. 以已接受的 CLI 结果为准。仅当其返回 complete 时，才报告已完成；否则显示其状态、错误和安全选项。结果未知时绝不重试，也不得发送第二条帖子作为验证。

边界

精确操作模式下的本地媒体

本地媒体仅支持一条手动原创帖子：准确的非空文本，加上 1–4 个有序 PNG/JPEG 文件（每个最多 5 MiB），或一个 MP4（最多 512 MiB）。文件必须可读取、是绝对路径下的本地常规文件，且不能是符号链接。不要将媒体放入任务／草稿／定时发布负载、回复或引用操作中。在此流程中，不要下载 URL、生成或编辑媒体、混合图片与视频、转码，或用不受支持的 GIF/MOV 文件替代。

1. 完成常规预检后，检查 tw capabilities --format json。要求 data.browser_relay.local_media_upload=true，且 action 系列中包含这两条媒体命令；否则停止，并将设置／更新作为下一步选项。不要仅根据 CLI 版本推断是否支持媒体。
2. 将文本和路径作为单独的 argv 值传入。运行 tw action tweet --text <exact_text> --media <absolute_paths...> --dry-run --json。此操作会验证文件，但不会打开 X，也不会写入操作记录。
3. 展示准确文本、按顺序排列的媒体预览（如果宿主环境能够显示），以及返回的 data.media_manifest（文件名、类型、大小、SHA-256）和 data.artifact_hash。URL 或文件名不能证明你检查过媒体。如果无法预览，请说明这一点，并让用户核实文件。请用户明确批准这段准确文本和这些准确且有序的文件。
4. 获得批准后，仅执行一次 tw action tweet --text <same_exact_text> --media <same_absolute_paths...> --expected-artifact-hash <reviewed_artifact_hash> --json。原样使用 CLI 返回的哈希；绝不要自行计算、推断或替换哈希。文本、字节内容、图片顺序、模式或数量发生变化时，都必须重新 dry-run 并获得批准。仅重命名相同字节不会改变其身份。
5. 仅当 data.status=confirmed，且返回了 data.status_url，同时预期与实际的媒体类型／数量一致时，才报告已发送。证明状态未知或缺少终结信封时，绝不能再次上传或发送。只能使用只读验证选项，直到用户明确决定如何恢复。

中文：本流程仅支持一条手动原创推文：准确原文加 1–4 张有序 PNG/JPEG（每张最多 5 MiB），或一个 MP4（最多 512 MiB）。先检查媒体能力，再 dry-run；展示原文、可用预览、文件顺序和返回的哈希，获得明确批准后带同一哈希发送一次。文字、文件内容、顺序或数量变化须重新审核；结果未知时不得重传或重发。任务、定时、回复、引用、远程链接和转码不在本流程内。

共享边界

• 任务模式会创建一个已物化的手动任务，其中可能包含 1..5 个帖子草稿；它不会创建任务提案或来源选择审核，也不会授予批量变更批准。
• 精确操作模式仅控制一个帖子，且不属于任务／计划谱系。
• 不要回复、引用、点赞、收藏、关注，也不要直接操作浏览器 UI。
• 不要在诊断信息中暴露用户内容、原始负载、私有引用或本地路径。

问题报告

对于明确提出的报告请求、返回的 CLI 错误、反复未解决的设置问题或未知证据，请在仅报告问题模式下启用 threadwave-preflight，并使用已清理的元数据。排除帖子文本和任务指令。说明没有发送任何内容。

返回格式

State: <invoking | discovering | generating | needs content approval | scheduled | complete | blocked | unknown>
Mode: <task | exact action>
Count: <requested / valid / approved / scheduled>
Reviews: <current content reviews with exact review_ref; none before drafts or for exact action>
Waiting for you: <matching per-item content decisions; one exact-action approval; or setup action>
你可以 / You can: <two to four verbatim-sayable options valid at the current gate>
Next: <one returned ref/action or stop>
Issue report: <copy/paste only; nothing sent>

你可以 / You can: 行只能列出当前关卡允许的选项——准确编号的决策、已显示的引用或任务模板；措辞应便于用户逐字回复，并本地化为所选语言；绝不提供超出当前关卡权限的操作。