legal 插件 /brief 命令实战用 Claude Cowork 构建法律团队简报Daily / Topic / Incident 三种模式详解【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins导读本文围绕开源仓库 knowledge-work-plugins 中 legal 插件提供的/brief命令定义于 legal/skills/brief/SKILL.md系统讲解法律团队如何借助 Claude Cowork 自动生成三类上下文简报每日简报Daily Brief、专题研究简报Topic Brief与突发事件简报Incident Brief。读完本文你将掌握/brief的调用语法、三种模式的完整工作流与输出模板、各数据源的扫描要点以及简报场景下的合规边界与注意事项可直接在你的法律团队工作流中落地使用。重要提示/brief辅助法律工作流但不提供法律意见。所有简报在作为决策依据前均应由合格的法律专业人士复核。一、命令总览三种模式与调用语法/brief是 legal 插件中面向法律团队的核心命令之一用于生成带有上下文的简报。该插件在仓库中的定位是为法务团队提供合同审查、NDA 分流、合规、风险、会议准备与模板化回复等能力的集合详见 legal/README.md。/brief专门负责把分散在邮箱、日历、聊天、CLM、CRM 等系统中的信息汇总为结构化简报。命令支持三种模式调用方式如下来源legal/skills/brief/SKILL.md/brief daily # 早晨的涉法事项简报Morning brief of legal-relevant items /brief topic [query] # 针对特定法律问题的研究简报Research brief on a specific legal question /brief incident [topic] # 针对发展中性事件的快速简报Rapid brief on a developing situation参数约定如果用户没有指定模式Claude 应先询问用户需要哪种类型的简报而不是擅自假设。模式使用场景产出时效daily每天开始时扫描邮箱、日历、聊天、CLM、CRM 中的涉法事项例行当日topic针对一个具体的法律问题在内部各来源中检索并综合按需研究型incident数据泄露、诉讼威胁、监管问询等需要立即掌握上下文的事件快速、优先三种模式共享同一原则简报必须可执行actionable每个条目都应有明确的下一步动作或列入简报的理由保持简洁链接到源材料而非整篇复述General Notes见原文档。二、Daily Brief早晨的涉法事项总览2.1 用途与定位Daily Brief 是法务团队成员开始一天工作时所需的早晨摘要覆盖一切需要知道才能开工的信息。2.2 需要扫描的数据源清单根据 legal/skills/brief/SKILL.mdClaude 应按顺序检查每个已连接来源中的涉法事项Email如已连接新的合同请求或审查请求合规问题或合规报告交易对手方对进行中谈判的回复法务团队收件箱中被标记或紧急的条目外部律师的沟通监管或法律更新类新闻通讯Calendar如已连接今天需要法律准备工作的会议董事会会议、交易评审、供应商电话会本周即将到来的截止日期合同到期、备案截止、回复截止例行的法务团队同步会Chat如已连接法务团队频道中的隔夜消息请求法律意见的私信涉及法务相关话题合同、合规、隐私、NDA、条款的提及升级事项或紧急请求CLM如已连接等待审查或签署的合同即将到期未来 30 天内的合同新签署的协议CRM如已连接进入需要法务介入阶段的交易被标记为需法律审查的新机会数据源可用性说明legal 插件通过 MCPModel Context Protocol连接外部工具具体支持的分类Calendar、Chat、Cloud storage、CLM、CRM、Email、E-signature、Office suite、Project tracker与可选项见 legal/CONNECTORS.md。插件是工具无关tool-agnostic的文档中用~~calendar、~~chat等占位符代表某一类工具具体产品可以是 Google Calendar、Slack、Box、Ironclad、Salesforce 等任意同类的 MCP 服务器。如果某个来源未连接Claude 必须把该缺口显著标注出来让用户知道哪些信息没有被检查。2.3 输出格式模板Daily Brief 的输出结构如下来源原文档 Output Format 小节字段说明为对原模板的逐项展开## Daily Legal Brief -- [日期] ### Urgent / Action Required [需要立即关注的事项按紧急程度排序] ### Contract Pipeline - **Awaiting Your Review**: [数量与列表] - **Pending Counterparty Response**: [数量与列表] - **Approaching Deadlines**: [本周到期事项] ### New Requests [自上次简报以来收到的合同审查请求、NDA 请求、合规问题] ### Calendar Today [与法律相关、需要做准备的会议] ### Team Activity [法务团队频道中的关键消息或更新] ### This Weeks Deadlines [即将到来的截止日期与备案日期] ### Sources Not Available [任何未连接或返回错误的来源]实践要点排序优先级Urgent 段落必须按紧急程度排序确保法务人员先处理最重要的事项。来源缺口显性化末尾的 Sources Not Available 是 Daily Brief 的强制段落它防止用户误以为已覆盖所有系统。学习偏好按原文档 General Notes 的要求daily brief 应随使用逐渐学习用户偏好什么有用、什么需要过滤掉形成更贴合个人的简报。三、Topic Brief针对具体法律问题的研究简报3.1 用途与定位Topic Brief 用于针对某个具体的法律问题或主题跨可用来源进行检索与简报。它适合研究一个具体法律问题的场景例如某条款的历史处理方式、某类合同的既往立场。3.2 工作流程根据 legal/skills/brief/SKILL.mdTopic Brief 的流程为接受用户提供的主题查询topic query跨已连接来源检索Documents内部备忘录、既往分析、playbook、先例precedentEmail该主题的既往通信Chat团队关于该主题的讨论CLM相关合同或条款将检索结果综合为结构化简报3.3 输出格式模板## Topic Brief: [主题] ### Summary [发现内容的 2-3 句话执行摘要] ### Background [来自内部来源的上下文与历史] ### Current State [基于可用文档组织当前的立场或做法] ### Key Considerations [重要因素、风险或悬而未决的问题] ### Internal Precedent [内部来源中找到的既往决策、备忘录或立场] ### Gaps [缺失的信息或哪些来源不可用] ### Recommended Next Steps [用户应如何处理这些信息]3.4 重要注意事项原文档明确强调了 Topic Brief 的三点限制非正式法律研究Topic Brief 综合的是已连接来源中的现有内容不能替代正式的法律研究。需要现行法律权威时升级如果主题需要现行法律依据current legal authority或判例法case law应建议用户咨询法律研究平台如 Westlaw、Lexis 等或外部律师。始终说明检索局限必须标注所检索来源的局限性Always note the limitations of the sources searched。这三点保证了 Topic Brief 在生产环境中的边界清晰它是内部知识加速器而不是法律意见生成器。四、Incident Brief发展中性事件的快速简报4.1 用途与定位Incident Brief 面向需要立即法律关注的发展中性事件——典型场景包括数据泄露data breach、诉讼威胁litigation threats、监管问询regulatory inquiries、知识产权争议IP disputes等。4.2 工作流程接受事件主题或描述快速扫描所有已连接来源以获取相关上下文Email关于事件的通信Chat实时讨论与升级Documents相关政策、应急预案、保险承保范围Calendar已安排的响应会议CLM受影响的合同、赔偿条款indemnification provisions、保险要求汇编为可执行的突发事件简报4.3 输出格式模板## Incident Brief: [主题] **Prepared**: [时间戳] **Classification**: [若可判断给出严重程度评估] ### Situation Summary [关于事件已掌握的信息] ### Timeline [基于可用来源的事件时间顺序摘要] ### Immediate Legal Considerations [监管通知要求、证据保全义务、特权privilege问题] ### Relevant Agreements [可能被牵涉的合同、保险单或其他协议] ### Internal Response [基于邮件/聊天的信息已经发生的内部响应活动] ### Key Contacts [从来源中识别的相关内部与外部联系人] ### Recommended Immediate Actions 1. [最紧急的动作] 2. [第二优先级] 3. [以此类推] ### Information Gaps [尚不清楚、需要确定的信息] ### Sources Checked [检索了什么以及哪些不可用]4.4 Incident Brief 的关键纪律原文档为 Incident Brief 单独列出了一组强制注意事项这是三种模式中约束最严格的一档速度优先用已有信息尽快产出简报而不是等待信息齐全Speed matters。立即标记保全义务一旦涉及潜在诉讼立刻标记 litigation hold诉讼保全或 preservation obligations证据保全义务。标注特权属性注意 privilege 考量适当时将简报标记为attorney-client privileged / work product律师-客户特权 / 工作成果。数据泄露时限如果事件可能涉及数据泄露标记适用的通知截止日期例如 GDPR 下的 72 小时。重大事件建议外部律师介入如果事件影响重大建议引入外部律师。五、通用纪律三模式共享的最佳实践在三种模式之上原文档 General Notes 一节给出了所有简报的通用要求实践时应一并遵守纪律具体要求来源缺口标注若某些来源不可用显著标注缺口让用户知道哪些未被检查持续学习偏好对 daily brief随时间学习用户偏好什么有用、什么要过滤可执行性每个条目都应有清晰的下一步动作或列入简报的理由简洁性保持简洁链接到源材料而不是全文复现结合 legal/README.md 的说明插件整体在工具不可用时采用优雅降级策略会标注缺口并建议手动检查这与/brief的 Sources Not Available 段落设计一脉相承。六、前置条件连接数据源与安装插件6.1 安装/brief属于 legal 插件安装方式见 legal/README.mdclaude plugins add knowledge-work-plugins/legal6.2 连接数据源简报质量直接取决于已连接的数据源数量。legal 插件支持的连接器分类摘自 legal/CONNECTORS.md分类占位符内置服务器示例其他可选Calendar~~calendarGoogle CalendarMicrosoft 365Chat~~chatSlackMicrosoft TeamsCloud storage~~cloud storageBox, EgnyteDropbox, SharePoint, Google DriveCLM~~CLM—Ironclad, AgiloftCRM~~CRM—Salesforce, HubSpotEmail~~emailGmailMicrosoft 365E-signature~~e-signatureDocuSignAdobe SignOffice suite~~office suiteMicrosoft 365Google WorkspaceProject tracker~~project trackerAtlassian (Jira/Confluence)Linear, Asana对于 Daily Brief 的完整运行Email Calendar Chat CLM CRM建议至少连接 Email、Calendar 与 Chat 三类CLM 与 CRM 能显著增强合同流水线与交易阶段信息的完整度。6.3 与其他 legal 技能/命令的协作/brief在 legal 插件中并非孤立存在。参考 legal/README.md 的 Skills 表与各 SKILL.md/brief incident的输出可与 legal/skills/legal-risk-assessment/SKILL.md 中的 Severity × Likelihood 风险矩阵衔接对事件进行 GREEN/YELLOW/ORANGE/RED 分级并给出对应处置建议Incident Brief 中的 Relevant Agreements可引导用户进一步执行 legal/skills/review-contract/SKILL.md针对赔偿条款、责任限制或 legal/skills/triage-nda/SKILL.mdTopic Brief 中的待办可通过 legal/skills/meeting-briefing/SKILL.md 的行动项追踪机制跟进Every action item must have exactly one owner 等最佳实践可直接复用。注意以上协作路径描述的是仓库中各 SKILL.md 之间的功能衔接关系属于对仓库内容的合理推断实际使用以各自文档为准。七、合规边界与法务实践建议/brief全篇反复强调同一合规主题这是法务场景工具与通用效率工具的本质区别值得专门说明不是法律意见所有简报含 Daily/Topic/Incident 三种模式都只是信息汇总与分析辅助必须由合格法律专业人士复核后才能作为决策依据原文档开头 Disclaimer。Topic Brief 不替代正式研究涉及现行法律权威或判例法时明确建议使用专业法律研究平台或外部律师。Incident Brief 承担保全职责及时标记诉讼保全义务、数据泄露通知时限如 GDPR 72 小时并在适当时标注特权属性——这些是法律时效性最强、错过代价最高的事项。面向个人学习与改进daily brief 的用户偏好学习机制意味着随着使用频率增加简报的过滤规则会越来越贴合个人工作方式最终沉淀为团队的知识资产。总结/brief是 legal 插件中把信息汇总提升为可执行法律工作流的关键命令Daily Brief 解决每天从哪里开始Topic Brief 解决某个问题内部怎么看Incident Brief 解决事情发生了先掌握什么。三者的共同底线是——清楚标注来源缺口、强调可执行性、并始终把最终判断权留给法律专业人士。结合 legal/CONNECTORS.md 配置好 Email、Calendar、Chat、CLM、CRM 等 MCP 连接器即可在 Claude Cowork 中把法务团队的晨间扫描与应急响应效率系统化。延伸阅读想了解/brief所处的完整 legal 插件生态合同审查、NDA 分流、合规检查、风险评级、会议准备、模板回复可阅读 legal/README.md 及各技能文档若需确认 MCP 连接器的完整清单与替换方式参见 legal/CONNECTORS.md。【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考