用途：让多张票据能在多个并行会话中同时推进——一个编排者写票据，N 个 worker 各自认领并端到端交付一张票据，且无需共享记忆或额外通信渠道。
主要能力与约定：
- 认领协议：assignee 字段即锁。开工前先把票据指派给自己并移到 In Progress，而非确认能完成之后。任何后端（Jira assignee、Backlog.md owner 列、GitHub issue assignee）的 assignee 字段都是“是否已有人在做”的权威依据。已指派的票据即视为被占用，换一张；不要私信对方，也不要在对方看似停滞时自行接管，停滞属于看板完整性问题。停止工作（被阻塞、票不对、票据信息不足）时对称地解除认领，即取消指派并同时移出 In Progress。
- 隔离：每个 worker 使用全新克隆或 git worktree，绝不共用检出目录的默认分支。按票据中的 Branch 字段创建分支，不自行发明分支名。工作区是一次性的，PR 打开后票据状态不应只存在于该检出目录。
- 票据即唯一上下文：worker 不反问。若票据缺少文件路径、验收标准含糊或验证步骤无预期输出，不猜测、不等待，停止并在票据上评论指出具体缺失内容，然后按协议解除认领。
- 回传契约：回传即三件事同时完成——向目标仓库默认分支提交只含事实的 PR；在票据评论中给出 PR URL 与本地测试结果（命令及其自身结论，而非“测试通过”这类空断言）；更新票据状态表示 PR 已开待审。仅存在于聊天中的报告对下一个 worker 与看板完整性检查不可见。
- 审查门槛：并行团队预设下 CODE_REVIEWED 在 always_required 中，无论改动类别（包括看似琐碎的票据）都会触发；审查者必须是不同于实现者的会话或人，实现者不能以任何身份自审自己的 diff 来满足该门槛。
适用场景：多个独立会话或代理并行处理同一看板上的多张票据，且无共享内存、无回传通道，只能依赖票据系统本身协调时。
限制：该技能是流程约定，需配合支持 assignee 字段的票据后端；具体配置、安装方式、命令与价格资料暂未提供。正文引用相关技能 workflow-engine、pull-request、verify-landed 与 Ticket Creation Protocol，但未给出具体命令。