verify

管理项目的版本号、CHANGELOG、release 流程。决定何时 bump major/minor/patch、如何生成 changelog、如何打 git tag。可在 /verify 之后、/code-review 之前或之后手动调用。

读取 .workflow/agents.json，读 ticket 内容后判断谁真正适合，为本机和服务器各给一条推荐。关键是保证强模型承担关键与复杂任务，不用计分排序。

将当前对话或 grill 摘要综合成一份正式 spec，存入 .workflow/specs/。不重新 interview，只做综合。

将 spec 拆成自包含的 tracer-bullet ticket，声明阻塞边，并给出本机和服务器各自的最佳 agent 推荐，写入 .workflow/tickets/。

管理 .workflow/agents.json。登记本机和服务器上有哪些 agent，每个 agent 只记录 harness、模型强弱、响应速度快慢、所在机器和擅长领域。属性不确定时向用户询问。

在被管理的项目里首次启用本工作流。只创建该项目 .workflow/ 下的目录与最小 config.json（路径类字段）。Agent 清单由 setup-agents 管理。

在本机和服务器之间同步 .workflow 上下文和 skills，确保 spec、ticket、research、agent 清单和验证报告使用同一份内容。

读取 .workflow/tickets/ 中未完成的 ticket，按阻塞边排出执行顺序，为每个 ticket 建一个 git worktree，按当前所在机器从两条推荐里选 agent，并给出工具建议。

测试驱动开发。当用户要构建功能或修复 bug 时使用。实现 ticket 的 agent 都应遵守。

对当前 diff、PR 或分支做双轴代码复审。合并后或发布前运行，本机和服务器都可以。

系统性调试。当遇到 bug、测试失败或意外行为时使用，在提出修复前先建立紧凑反馈循环。所有 agent 都应遵守。

问当前场景该用哪个 skill 或哪条流程。本仓库所有 skill 的路由器。不知道从哪开始时，先问它。