用途：这是 Bitwarden 技术拆解（Tech Breakdown）模板中负责跨团队协作的一半，覆盖 Part 3（签核表与跨团队清单）以及拆解收尾时的完成沟通清单。工程内容（Part 1、2、4、5、6）与状态机（IN PLANNING → IN PROGRESS → PROPOSED → ACCEPTED → COMPLETE）在 Skill(writing-tech-breakdowns) 中定义。本技能在拆解进入 PROPOSED 时运行，并在实现落地、准备转为 COMPLETE 时再次运行。需要规范模板时，通过 get_confluence_page 获取页面 2920349776。
识别受影响团队：优先通过 Initiative 漏斗（Skill(navigating-the-initiative-funnel)）获取受影响团队列表、同属该 initiative 的兄弟团队 epic 以及 shepherd；无 initiative 或列表有缺口时，直接走 Part 3 跨团队清单，逐项判断移动端改动、团队域外的组件/服务/文件、对其他团队服务的依赖、为其他团队构建 API 等情况。
Part 3 签核表：模板规定五列——Team、Describe interface、Blocking?、Associated Other Team Breakdown、Signoff。每列都关键：每团队一行；接口描述要具体到对方 tech lead 能回应；Blocking 用于对方拥有被直接修改、调用或依赖其契约的代码，仅被告知则为 advisory；关联拆解链接可留空；签核须写具体人名与日期，不能只写“团队”。示例见 ${CLAUDE_PLUGIN_ROOT}/skills/coordinating-cross-team-breakdown/examples/signoff-table.md。
催办签核：直接私信签核行中的具体负责人；不接受没有姓名和日期的“看起来没问题”；Blocking 行超过一个 sprint 未决应升级（有 shepherd 找 shepherd，否则找双方 EM）；签核暴露的问题应回到 Skill(writing-tech-breakdowns) 修改 Part 1–4 并重新确认。有 shepherd 时，争议接口先向 shepherd 反映，由其决定是否引入 Architecture Council；无 shepherd 则升级到双方 EM。
转为 ACCEPTED：所有 Blocking 签核均记录具体人名与日期后，设置状态字段并记录转换日期；advisory 未决不构成门槛。ACCEPTED 后的重大变更需取代原拆解或退回 PROPOSED 重新流转。
完成沟通清单：实现发布后，核对所有团队签核、在 #team-eng-tech-breakdowns 发布链接、联系负责的 QA 工程师、联系团队 refinement facilitator 以便任务进入下一次梳理，然后设为 COMPLETE。若跨团队评审发现无法解决的冲突，可进入 REJECTED 终态，保留拆解作为历史记录并在该频道告知。
常见错误：忽略漏斗上下文、过度或不足标记 Blocking、签核长期未决不升级、有 shepherd 时直接跨团队谈判、跳过完成沟通清单、伪造签核记录。
限制：资料未提供具体收费、平台或效果信息；本技能依赖 Bitwarden 内部模板、Confluence 页面与相关 Skill，外部环境可能无法直接使用。