用途：在上下文自动摘要、长时间中断或代理行为漂移后，恢复工作流感知，无需新建会话。它负责工作流状态的读取与恢复侧：读取当前状态、与 git 实况核对、确认工作流是否存在；写入侧（初始化、更新、阶段切换、交接）见 checkpoint 技能。
触发场景：摘要后恢复上下文（rehydrate <featureId>）；压缩后代理停止主动发事件或用工具；中断后回到工作流。
状态位置：工作流状态存于 MCP 事件库，不在文件系统。用 exarchos:exarchos_workflow 的 get 读取状态，用 exarchos_view pipeline 发现活跃工作流。不要扫描 ~/.claude/workflow-state/*.state.json，该路径为遗留位置，可能过期或为空。
存在性判定：权威记录是 SQLite 事件库；<featureId>.state.json 只是次要的“规划者印记”，缺失不代表工作流不存在。规范的检查方式是读取 rehydrate 信封的 _meta.workflowExists，或 data.workflowState.featureId 非空。对从未初始化过的 featureId 冷探测会返回 success: true、空文档、workflowExists: false，且无副作用。切勿以磁盘上的 .state.json 文件判断存在性。
恢复方式：调用 exarchos:exarchos_workflow，action: "rehydrate"，featureId: "<id>"，单次返回包含 workflowState、taskProgress、artifacts、blockers、阶段手册与后续动作的完整文档。若 featureId 未知，先用 exarchos_view pipeline 列出活跃工作流（默认按仓库范围，跨仓库需 scope: "all" 或指定 repoRoot）再询问用户。
定向读取：用 action: "get" 加 featureId 获取完整状态，加 query 做点路径查询（如 phase、tasks），加 fields 数组做字段投影以降低 token 开销。
输出格式：将返回文档渲染为紧凑行为上下文——标题含 featureId、阶段与工作流类型；House Rules 列出技能、工具、必需模型发出事件、自动发出事件、过渡条件与守卫、校验脚本；随后是事件发出提示、任务进度表、产物（设计、计划、PR）与下一动作。保持精简，细节留在文件中。
核对：运行 rehydrate <featureId> 会把新于快照的事件折叠进来并暴露偏差；更深入的手动核对可用 exarchos_orchestrate 的 action: "reconcile_state"，传 stateFile 与 repoRoot，passed: true 表示一致，false 则需按输出处理并用 exarchos_workflow 的 update 修正。
最佳实践：恢复时先核对；摘要后从事件库读取而非凭记忆；单次调用 rehydrate；用 _meta.workflowExists 判存在。
排障：状态不同步时先 rehydrate，再对比 git log 与分支状态，必要时 update；恢复发现分支或工作树已不存在时，对比 git branch -a / git worktree list 后更新；存在多个活跃工作流时系统采用最近更新的未完成工作流，可用 action: "cancel" 配 dryRun: true 预览清理陈旧工作流。
限制：工作流状态存于 MCP 事件库，依赖 exarchos MCP 环境；若事件流与 git 实况不一致，需手动核对与更新；本技能只覆盖读取与恢复，写入操作需配合 checkpoint 技能。