twitter-reply

Twitter 回复

将临时回复工作作为独立的平级任务处理。绝不激活或依赖 twitter-automation；该平级任务可以将工作路由到这里，但本技能负责预检和完整的回复工作流。

先精简请求

在预检或执行任何 tw 命令之前，先保护任何精确目标和最终回复文本。对于每个任务模式请求，将用户其余措辞改写为一个简洁、修正后的句子。结合完整上下文修正明显的错别字，并删去填充语或重复内容，同时保留每个明确指定的数量、主题、字面搜索短语、账号或关系筛选条件、互动门槛及其他约束。不得添加用户未提及的主题或要求。

将精简后的请求作为创建任务和任何重新开始全新任务的方向。如果无法在不猜测用户意图的情况下精简措辞，就提出一个简洁的问题并停止。绝不改写精确的目标／回复文本对。例如，fin 10 let's connect tweets and draft replies 的意思是 Find 10 tweets matching "let's connect" and draft replies，而不是财经任务。

选择一种模式

当用户提供方向、主题、字面搜索锚点、账号／界面条件、目标发现请求，或 5 到 10 之间的发现数量时，选择任务模式。

只有当用户提供一个精确目标、一条完整的最终回复，并明确表示要立即发送时，才选择精确操作模式。

如果用户明确要求重试当前任务中的一条完全相同的草稿，且其持久化结果能明确证明发送尚未开始，也选择精确操作模式。重试会创建全新的精确操作流程，绝不会重新打开、重新安排或执行失败的计划变更。

• 如果未指定发现任务数量，默认为 5。
• 目标发现只接受 5 到 10 之间的整数。
• 如果发现数量低于 5 或高于 10，请用户选择 5..10；绝不自动拆分任务，也不将其重新解释为精确操作模式。
• 绝不从浏览器状态、屏幕截图、个人资料 URL 或“那条推文”推断精确目标。
• 对于多个精确的目标／文本对，询问用户是希望执行一个基于方向的发现任务，还是分别执行多个精确操作。
• 如果无法确定是精确操作还是发现／方向请求，请在调用 tw 之前提出一个简洁的问题。
• 对于有关先前回复工作的结果或状态问题，使用“检查之前的工作”，而不是上述任一模式。

任务模板

进入任务模式时——以及用户的措辞含糊、无法在不猜测的情况下精简时——提供一个本地化的填空模板，而不是开放式提问：

Reply task template:
Find <5–10> tweets containing "<keyword/phrase>" and draft replies
Optional: only/exclude specific accounts, minimum engagement, language
Example: Find 10 tweets containing "let's connect" and draft replies

回复任务模板：
找 <5–10> 条包含「关键词/短语」的推文并起草回复
可选：只看/排除某账号、最低互动量、语言
示例：找 10 条包含「let's connect」的推文并起草回复

在发现目标不足（例如 no_valid_targets_found）时，使用相同模板建议用户改写方向。

语言

根据用户明确的偏好、最新消息、对话语言，依次选择英语或简体中文；若均未指定，则使用英语。绝不翻译或规范化精确的目标／回复文本对。按照上述定义精简任务方向，但不得添加要求。

强制预检

精简请求并选择模式后，在每个新的回复任务开始时，按技能名称激活 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 不变量检查，或将已接受的结果重新解释为契约偏差。
• 显示顶层 warnings 中每一条非空内容。当返回的草稿数据包含 generation_warnings 时，在对应草稿旁显示每条消息。这些是经过 CLI 清理、面向客户的自然语言提示：保留其含义，绝不抑制它们或用通用的门禁失败消息替代，也绝不添加内部规则 ID、提示词文本或门禁上下文。
• 执行返回的只读 next 命令以继续工作流。将审核、重启、取消或 X 变更命令作为选项呈现，只运行用户明确授权的精确命令。
• 对于 ok=false，报告返回的 error.code、error.message 和 error.retryable；在显示任何安全的返回 next 选项之前，先显示面向客户的消息，包括描述自然语言提示失败的消息。绝不将其简化为通用的受阻状态，也绝不用模型臆造的诊断替代。
• 只有 CLI 返回 failure_stage 时才报告工作流失败阶段。绝不根据 source_status、draft_status、耗时或错误代码推断阶段；如果缺少此字段，只报告返回的失败事实。
• 如果命令退出时没有完整信封，立即停止并报告 task_dispatch_unconfirmed。这是唯一的主机端结果检查，绝不授权重复创建任务。

审批权

每项审批都必须在各自的门禁内进行：

门禁	允许的决定	“全部批准”	批准的结果
内容审核	每次精确审核各作出一项明确决定	绝不允许	每项获批审核只授权一次精确的回复变更。
精确操作	在试运行后使用一组未更改的目标／文本	绝不允许	只分派该组合一次。

不基于计划的手动任务创建，以用户请求作为发现和草稿生成的依据。此操作不会创建任务提案或来源选择审核。确定性来源选择不等同于用户批准，也绝不授权 X 变更。任何“全部批准”“继续”或“重试”之类的措辞，都不会将权限转移到其余门禁。

任务模式

1. 创建一个有明确范围的任务

将方向作为一个安全参数传递；绝不将用户内容拼接进 shell 语法。运行语义等效于：

在 Windows 打包版安装中，使用从 threadwave-preflight 保留的结构化下游形式：通过 ProcessStartInfo.ArgumentList 分别添加每个 CLI 令牌和完整的精简方向。绝不使用 PowerShell & 加 splatting、Start-Process -ArgumentList、ProcessStartInfo.Arguments 或拼接的 cmd.exe /c 字符串调用 tw.cmd。如果主机无法为每个值保留一个独立参数，则停止并报告 twitter_automation_cli_unconfirmed。

tw task create --surface reply --direction <condensed_request> --count <5..10> --json

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

2. 遵循自动发现并生成草稿

遵循已接受的信封中的确切 next 命令。如果创建任务或重启任务时返回重复且完全相同的 task-show 后续操作，将该只读后续操作合并为一条 tw task wait <task_blueprint_ref> --timeout 900 --include-drafts --json 命令。该命令会在 CLI 内等待，并一并返回终态任务以及每一份确切的草稿、来源、审核 ref 和审核后续操作；不要通过模型轮询 task show，也不要为该批次单独调用 draft-show 命令。绝不可用全局列表或最新记录替代。

如果 task wait 返回 task_wait_timeout，则显示当前任务状态及其确切返回的等待后续操作，作为用户可选项。不要自动启动另一次等待或创建替代工作。

当 CLI 返回草稿和审核选项时，将返回的目标/内容配对一并展示，并等待对每个项目分别作出决定。当返回数量不足、失败、停滞状态或草稿少于请求数量时，准确呈现该状态，并仅展示其返回的选项。绝不可自动创建替代工作。

3. 审核草稿和已安排的变更

• 仅使用已接受的 CLI 信封中 next 里的命令。直接运行只读检查后续操作。将批准、拒绝、跳过、重启、取消和 X 变更命令作为选项展示；收到明确决定后，调用对应的确切命令一次，并让未提及的审核保持待处理状态。如果某项决定失败，不要重放已成功的决定；根据返回的状态，仅询问尚未解决的决定。
• 记录每一个确切返回的 scheduled_task_ref。已安排不代表已完成：只要任何 ref 状态为 scheduled 或 running，就保持会话活动，并以不超过 15 秒的间隔使用 tw scheduler show <scheduled_task_ref> --json 轮询该 ref。不要仅为加快守护进程管理的预留任务而调用 tw scheduler execute。
• 当 ref 不再处于 scheduled 或 running 状态时，使用 tw scheduler evidence <scheduled_task_ref> --json 检查一次。如果状态为 succeeded，只有在调度器证据确凿时才能视为已发送。如果终态回复仍缺少确凿的已发送/未发送结果，则针对其确切逻辑任务运行一次 tw action snapshot verify --task <task_blueprint_ref> --json。将项目 verified 视为已发送，not_complete 视为未发送，inconclusive 视为结果未知。不要重复运行快照，也不要重新解读其结果。状态为 paused 或 waiting_review 的 ref 需要用户操作；展示该阻塞项，并继续观察所有其他 ref。
• 每轮轮询只要有任何状态发生变化，就使用原始编号草稿映射发布一条简洁更新，并将每份草稿严格归入以下一个标题：Sent、Not sent yet 或 Needs attention。仅当状态为 succeeded 且证据确凿时，才归入 Sent；仅当状态为 scheduled 或 running 时，才归入 Not sent yet。将受阻、失败、暂停、恢复中和未知结果归入 Needs attention；将有确凿证据表明未发送的结果标为 not sent，将无法确定的结果标为 outcome unknown。绝不可把 outcome unknown 改写为 nothing sent。
• 如果某轮轮询没有任何变化，至少每隔 60 秒重复一次完整的编号分类，让用户看到监控仍在持续。继续监控，直到每个返回的 ref 都已进入终态、被用户跳过，或等待用户决定；绝不可仅因所有草稿都已安排就结束回复流程。

如果有多个内容审核待处理，应将它们作为一组编号项目一并展示，每项都包含确切的目标、回复文本和 review_ref。要求用户针对每一项提供明确的决定映射。绝不可将多条回复合并成“全部批准”，也不可将不具体的决定视为授权批量变更。每项内容批准仅授权一项确切的回复变更。

绝不可猜测目标或 ref。

4. 处理变更和失败

以下每项新任务都会运行更新检查和常规预检；只有新任务会复用最新的就绪状态，而不会强制执行完整检查。除非就绪状态已失效，否则审核、监控和重新起草都会复用当前的就绪结果。

• 如果精确任务报告 execution_status=failed 且 restart_allowed=true，请展示其失败代码，并明确提供重启或停止这一个选项。重启时，恰好调用一次 tw task restart <task_blueprint_ref> --json，验证 ok=true，然后对同一个逻辑任务恢复相同的自动发现轮询约定。重启会创建一次全新的变更前执行；它不会创建重复任务，也不表示旧尝试已取消。同一会话中重启两轮后若仍失败，请停止并报告确切的阻碍。
• 每当 tw scheduler cancel 返回 logical_workflow_terminalization.status=pending 时，请告知用户关联工作流的清理仍在进行，在 recheck_after_seconds（当前为 60）后重新检查精确任务，不要将不可变的调度器记录描述为会过期。
• 草稿已存在且没有回复变更处于 scheduled、running、paused、waiting_review 状态或证据未知时，对于仅修改措辞且来源未变的情况，请使用 tw draft redraft，并要求进行新的内容审核。对于“从头开始”“这些候选项不对”或方向、来源、角度或目标发生变化的情况，请展示所有当前内容审核，并询问用户是否确认跳过仍待处理的草稿。确认后，对每个已确认的引用恰好调用一次 tw plan review skip <review_ref> --json，验证 data.review.status=skipped，然后使用最新的精简方向和数量创建一个新任务。历史任务仍会保留记录；不会转移任何授权。
• 如果任何回复变更处于 scheduled、running、paused、waiting_review 状态或证据未知，请勿重启或创建替代回复。继续监控精确的已调度引用，直到用户根据下文的恢复决策明确作出决定。
• 对于 recovery_required 或其他无法得出结论的已调度引用，请展示确切的 scheduled_task_ref 及其持久证据分类，并停止操作，等待用户明确选择一项决定：继续监控、跳过、取消或报告。用户明确选择 skip 后，恰好调用一次 tw scheduler skip <scheduled_task_ref> --json，并要求 data.outcome_acknowledged=true；随后结束对此引用的监控，并将其作为已跳过项保留在 Needs attention 下。持久结果仍为 outcome unknown，该确认会保留到后续会话中；跳过不授权重试、重新起草、替换、取消或其他变更。只有当用户明确指定该确切引用时，才可执行 cancel：恰好调用一次 tw scheduler cancel <scheduled_task_ref> --json，验证返回的状态，并遵循上述终止化复查规则。跳过的引用不再妨碍使用其余引用完成回复流程。
• 被拒绝或跳过的内容审核不会创建变更。
• 将没有分发 ActionRecord 的 relay_unavailable，以及具有 reply:blocked_before_dispatch、无 dispatched_at 且 confirmation_state=not_required 的 action_preparation_failed，视为已确证未发送。仅有 ActionRecord 或 EvidenceRecord 数量属于审计证据，不能证明已分发。
• 重试仅接受一份内容完全未变的精确草稿。通过当前任务返回的引用，或通过 Inspect Previous Work 中与谱系精确匹配的引用，确定精确的目标/文本配对；针对全新的精确操作任务运行更新检查和常规预检，不要仅因模式变化而强制执行完整检查，然后启动一次全新的精确操作试运行。展示该配对，并要求获得新的明确批准后再分发一次。若用户请求重试多个项目，请让用户选择一个；后续每个配对都必须单独经过精确操作流程并获得批准。绝不要执行或重新调度旧的已调度任务引用，也不要转移其任务/内容批准。
• 如果编号草稿映射已过时、目标/文本已更改，或者当前任务和谱系匹配的先前工作引用都没有确凿的分发前证据，请询问用户提供确切的当前草稿/引用，或将状态报告为未知。未知、分发后、unknown_confirmation、已确认或其他无法得出结论的结果绝不能进入此重试流程；必须提交经净化且保留 outcome unknown 的问题报告，或根据上述恢复决策明确由用户选择跳过。

检查之前的工作

当用户询问之前的任务或 Agent 会话中先前回复工作的结果时，使用此路径。这是只读的证据检查与如实报告；绝不会重新开启旧任务的发现、生成或审核流程。

1. 运行强制预检，然后运行 tw scheduler list --json。根据列表输出中的沿袭字段（task_blueprint_ref、manual_request_ref、work_cycle_id），匹配用户所指工作的 ref。绝不要猜测 ref，也不要根据时间戳推断 ref。沿袭关系存在歧义时，列出候选任务并请用户确认具体任务。
2. 使用 tw scheduler show <scheduled_task_ref> --json 和 tw scheduler evidence <scheduled_task_ref> --json 检查每个确切的 ref。对于无法确定已发送或未发送的终止状态回复，针对其确切的逻辑任务运行一次 tw action snapshot verify --task <task_blueprint_ref> --json。
3. 按照与实时监控相同的判定规则报告：有确凿的调度器证据或条目状态为 verified 时，报告 Sent；仅当状态为 scheduled 或 running 时，报告 Not sent yet；其他所有情况均归入 Needs attention；条目状态 not_complete 表示未发送，inconclusive 表示结果未知。
4. 若某个 ref 的持久化证据按照现有标准确证尚未发送，可进入重试流程；若结果不确定，则应继续监控、跳过、取消或报告，绝不能进入重试流程。

此路径绝不会重新批准、重新安排或执行旧 ref，也绝不会声称证据无法证明的结果。

精确操作模式

必须只使用 CLI 契约接受的一个目标，并且只使用一条确切的最终回复。个人资料 URL 不是回复目标。

1. 通过安全的 argv/stdin 处理方式运行 tw action reply <exact_target> --text <exact_reply> --dry-run --json。
2. 完整显示确切的目标和回复、dry-run 结果以及语义操作；请求用户明确批准。
3. 目标或任何字符发生变化，都视为新负载，必须重新执行 dry-run 并获取批准。
4. 用户明确批准后，复用当前精确操作流程的预检结果，并运行一次 tw action reply <same_target> --text <same_reply> --json 进行发送。
5. 以 CLI 接受的结果为准。仅当其返回 complete 时才报告已完成；否则呈现其状态、错误和安全选项。结果未知时绝不重试，也绝不发送测试回复。

边界

• 任务模式会创建一个已实例化的手动任务，其中包含 5..10 个可能的回复草稿；不会创建任务/来源审核，也不会授予批量修改批准。
• 精确操作模式仅控制一组目标/文本组合，不属于任务/计划沿袭。
• 不要创建原创帖子、引用、点赞、保存、关注，也不要直接操作浏览器 UI。
• 不要在诊断信息中暴露回复文本、目标、原始负载、私有 ref 或本地路径。

问题报告

对于明确的报告请求、返回的 CLI 错误、反复未解决的设置问题或未知证据，使用经过净化的元数据，以仅报告问题模式启用 threadwave-preflight。排除目标、回复文本和任务方向。问题报告的生成不会发送回复；根据持久化证据支持的确切情况，将每条受影响的回复报告为 sent、not sent 或 outcome unknown。

返回格式

State: <discovering | generating | needs content approval | needs exact-action approval | monitoring | complete | blocked | unknown>
Mode: <task | exact-action>
Count: <requested / valid drafts / content-approved / scheduled, or n/a for exact-action>
Reviews: <current content reviews with exact review_ref; none before drafts or for exact-action>
CLI messages: <every returned warning or error message; none when empty>
Waiting for you: <matching per-item content decisions; approve this exact target/text pair; or none>
你可以 / You can: <two to four verbatim-sayable options valid at the current gate>
Next: <one returned ref/action or stop>
Outcome: <sent | not sent | not sent yet | outcome unknown, per reply>
Issue report: <copy/paste only; preserves the durable outcome>

你可以 / You can: 这一行只列出当前关卡实际允许的选项——确切编号的内容决策、已显示的精确操作组合、已显示的 refs 或任务模板；措辞应让用户能够逐字回复，并根据所选语言本地化；绝不提供超出当前关卡授权范围的操作。