# Verify Status > 这个 skill 回答一个问题：**这个员工现在在不在线、在不在正确的状态（在岗、能接活）**。两个场景： Use when this capability is needed. - Skill: `tomevault-io/verify-status` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add tomevault-io/verify-status` - Raw SKILL.md: https://api.skillmd.com/api/skills/tomevault-io/verify-status/raw - Safety review: pending (external: skill-scanner PASS, skillspector PASS) - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: tomevault-io (https://skillmd.com/u/tomevault-io) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/tomevault-io/verify-status --- # verify-status — 确认员工在不在线、在不在岗 ## 何时用 这个 skill 回答一个问题：**这个员工现在在不在线、在不在正确的状态（在岗、能接活）**。两个场景： - **部署后必跑**（最后一道闸）：团队拉起 → 每个员工的身份 init 消息注入完成 → 执行本 skill → 全员在岗才允许宣布部署成功。`claudeteam health` 绿不算数——health 只看进程不看"人"，进程活着不等于员工在线。 - **平时单点复用**：巡视中怀疑某员工掉线、不回话、不在状态时，单独对它执行第 2 步起的判读流程。 > 核心约束（执行时必须遵守）：**不要用正则/字符串匹配来判定**。把每个员工 pane 的整段 tmux 文本拉出来，由你（执行本 skill 的 agent）自己通读、自己做语义判断。下文的判读维度和病征样例是帮助你理解的参照，**不是匹配规则**——CLI 的横幅、提示语、界面布局每个版本都会变，你要判断的是语义上它是否就位，不是某行字是否出现。 ## 输入 - team 成员表（`claudeteam team`，知道要确认谁）。 - 每个员工 pane 的**完整近期文本**（`claudeteam peek `，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 后重新部署或重拉该员工）。失败时不通知测试开跑，不把"进程都活着"当成部署成功。 ## 产物 一份逐员工的确认清单（每人一行：通过/未通过 + 引用实录的依据），附在部署报告末尾。通过的部署，这份清单是"全员身份就位"的凭证；失败的部署，它是给用户的修复指引。 **做完的标志**：清单覆盖了 team 里每一个员工，且每行都有实录依据；失败时给出了明确的登录指引。 --- > Source: [zylMozart/ClaudeTeam](https://github.com/zylMozart/ClaudeTeam) — distributed by [TomeVault](https://tomevault.io).