verify-status

verify-status — 确认员工在不在线、在不在岗

何时用

这个 skill 回答一个问题：这个员工现在在不在线、在不在正确的状态（在岗、能接活）。两个场景：

• 部署后必跑（最后一道闸）：团队拉起 → 每个员工的身份 init 消息注入完成 → 执行本 skill → 全员在岗才允许宣布部署成功。claudeteam health 绿不算数——health 只看进程不看"人"，进程活着不等于员工在线。
• 平时单点复用：巡视中怀疑某员工掉线、不回话、不在状态时，单独对它执行第 2 步起的判读流程。

核心约束（执行时必须遵守）：不要用正则/字符串匹配来判定。把每个员工 pane 的整段 tmux 文本拉出来，由你（执行本 skill 的 agent）自己通读、自己做语义判断。下文的判读维度和病征样例是帮助你理解的参照，不是匹配规则——CLI 的横幅、提示语、界面布局每个版本都会变，你要判断的是语义上它是否就位，不是某行字是否出现。

输入

• team 成员表（claudeteam team，知道要确认谁）。
• 每个员工 pane 的完整近期文本（claudeteam peek <agent> <N>，N 给足，覆盖从身份注入到当下的全过程，别只截尾巴几行）。

步骤

1. 给足处理时间（部署场景）。身份消息注入后，员工需要时间读身份文件、查收件箱、回报到位。先等一两分钟量级（慢模型更久）再开始确认——注入完立刻看，看到的多半是还没开始的画面，会误判。（巡视复用时跳过本步，直接读现场。）

2. 逐员工拉取整段现场，自己读。对每一个员工（部署场景一个都不能跳过；巡视复用时只看怀疑对象），把 pane 全文拉出来，像读一份终端实录一样从头到尾读完，回答一个问题：

   这个员工现在在线吗？在岗吗？——即：它是否以正确的身份完成了该做的事（部署场景=身份消息要求的动作），并处于能接活的状态？

   从这几个维度综合判断（任何单一特征都不是结论）：

   • 它收到身份消息了吗？ 实录里应当能看到身份 init 文本到达，并且是被提交执行了，而不是还躺在输入框里没回车。
   • 它按身份消息行动了吗？ 正常的实录会显示它去读了身份文件、查了收件箱、更新了状态之类的动作痕迹——具体做了哪几样不重要，重要的是它在按指令行动而不是无反应。
   • 它知道自己是谁吗？ 实录里它的自述（比如收尾的一行 ack）应当与它的员工名一致。自称成了别的员工、或表现出"不知道自己是谁"的困惑，判不通过。
   • 它现在处于什么状态？ 健康的终态是：动作做完，停在一个安静的、等待下一条输入的就绪界面。还在长考属于"尚未完成"而非"失败"——回到第 1 步再等一轮。
   • 有没有明显的病征？ 留意这类画面（举例性质，形态会变化，靠语义理解不靠记关键词）：要求登录/重新认证的提示、token 或 401 类报错、CLI 退出后裸露的 shell 提示符、反复打转的报错循环、身份文本卡在输入框未提交。看到这类画面，直接进第 4 步对应处置。

3. 拿不准就问一句。读完实录仍吃不准时（比如画面安静但看不出它做没做过事），允许做一次轻量活性确认：给该员工注入一句无副作用的点名（让它用一行回答自己的名字和状态），等片刻重新拉实录看是否正确响应。每员工最多问一次，别反复戳。

4. 分情况处置：

   • 尚未完成（长回合未结束）→ 再等一轮回到第 2 步。总确认窗口给到合理上限（十分钟量级），超时仍未就位按"未通过"处理。
   • 身份文本未提交（卡在输入框）→ 补一次提交键，回到第 2 步复查。软修复，每员工最多一次。
   • 认证类病征（要求登录、token 过期、401）→ 不要试图自己绕过。记下员工名、CLI 类型、实录关键画面，进入"部署失败"出口。
   • 其他未通过（自我认知错乱、CLI 崩、反复报错）→ 同上记录；崩溃类可先重拉一次（rehire/reidentify）再复查，同样每员工最多一次。

5. 结论与出口（一票否决）：

   • 全员通过 → 逐员工写一行结论（员工名 + 通过 + 一句话依据，依据引用你在实录里看到的事实），之后才允许宣布部署成功、通知测试开跑。
   • 任一员工最终未通过 → 判本次部署失败。写清：哪个员工、什么病征、实录关键片段、做过哪些软修复；明确提示用户需要人工介入登录（指出是哪个 CLI 的认证问题，让用户完成登录/换 token 后重新部署或重拉该员工）。失败时不通知测试开跑，不把"进程都活着"当成部署成功。