用途：帮助工程经理诊断团队知识不流动的原因，并给出可落地的最小机制，而非堆砌大型文档项目。
主要能力：按四类根因分类诊断——横向信息流缺失（用工程公会/章节或按技术域建 Slack 频道）、知识共享失效（用最小可行文档与架构决策记录 ADR）、入职不畅（结构化入职伙伴、结对编程、跨团队介绍）、“我们对他们”思维（架构评审会、闪电演讲、把知识共享纳入职业框架激励）。另含跨团队请求的三条路径：不理会、延迟处理、优先处理，并指出延迟的“是”往往比直接说“不”代价更高。
使用方式：先检查 .agents/em-context.md，若不存在则先收集最小经理画像（角色/职级、团队规模、团队使命或负责领域、当前挑战或优先级）并保存；若涉及具体成员且 .agents/reports/[name].md 不存在，先收集该人最小画像（职级、在职时长、优势、当前挑战或成长点）并保存。后续出现持久性新上下文时自动更新上述文件，只保存稳定事实与模式。回答风格：先给诊断或建议，仅在缺失上下文会改变建议时提 2-3 个针对性问题，再给下一步具体行动和可用措辞，简要提及相关框架，不逐条展开；用户要求深入时再展开。
适用场景：团队重复造轮子、文档缺失或过期、新人上手慢、团队间信息壁垒或竞争、跨团队请求悬而未决。
限制：资料未提供具体收费、价格、平台支持范围或效果数据；机制需结合组织实际，避免沦为过时官僚流程。