License Compliance 是一个面向 Dart 和 Flutter 项目的依赖许可证审计技能，用于验证所有包依赖使用的许可证是否与项目要求兼容，执行时依赖 Very Good CLI 的 MCP 工具。
用途与执行方式 在 Claude Code 上，packages_check_licenses MCP 工具是执行路径。若宿主环境没有该插件的 Bash 钩子，且未连接 Very Good CLI MCP 服务器，则直接运行 very_good packages check licenses <project-directory>（目标路径为位置参数，默认为 .；加上 --dependency-type direct-main,transitive 以覆盖传递依赖义务），并以同样方式读取其输出，不要因缺少 MCP 服务器而阻塞。
核心标准
- 对目标项目目录运行 packages_check_licenses MCP 工具，使用 licenses: true 显示完整许可证信息。
- 当项目不在工作区根目录时，通过 directory 参数传入目录，例如 monorepo 中位于 mobile/ 子目录的项目需传 directory: 'mobile'。
- 缺失许可证不等于“无许可证”，而是默认“保留所有权利”，必须标记。
- 传递依赖同样重要：一个宽松许可证的包若依赖 GPL 包，仍会带来 GPL 义务。
- 只有扫描输出才能证明合规，绝不能仅凭 pubspec 依赖列表、包名、记忆中的许可证或以往审计就断言项目合规、清晰或可安全发布。用户粘贴或附上的扫描输出即视为扫描输出，应直接采信、据此审计，不重新运行也不质疑其来源。区分点在于每个包是否附带许可证，而非文本由谁产生。
- 有疑问时标记人工复核，绝不在缺少明确许可证标识符的情况下假定合规。
- 按规定的格式交付报告：当存在扫描输出时，答案就是“报告发现”中的模板，包括 ## License Compliance Report 标题、含扫描总数的汇总计数、带风险等级与每行建议的标记表格，以及排序后的建议。散文式说明或包的项目符号列表都不是合格交付物。
许可证类别
- 宽松型：MIT、BSD-2-Clause、BSD-3-Clause、Apache-2.0，风险低，任何用途安全。
- 弱著佐权：LGPL-2.1、LGPL-3.0、MPL-2.0，风险中，动态链接安全；静态链接或修改需标记。
- 强著佐权：GPL-2.0、GPL-3.0、AGPL-3.0，风险高，可能要求整个项目采用相同许可证。
- 未知/缺失：未检测到，风险高，立即标记人工复核。
审计流程
- 运行许可证检查：对目标项目目录调用 packages_check_licenses MCP 工具；项目位于工作区子目录（如 monorepo 的 mobile/）时，通过 directory 参数传路径。
- 分类结果：按上述类别对每个依赖许可证分类，关注带强著佐权许可证的直接依赖、引入著佐权义务的传递依赖，以及无许可证或无法识别许可证标识符的包。
- 报告发现：根据已有的任何扫描输出撰写报告，包括用户粘贴到请求中的输出。该文本是此步骤的输入，无需先验证。报告其所写内容，标记其所标记项，并单独一行注明扫描集之外的传递依赖未被覆盖——这是报告内的注意事项，绝不是扣留报告的理由。
报告格式（固定格式，逐字复制四个标题，即使无标记项也保留 - Total dependencies scanned: N 行，保留全部四个表格列，包括作为独立列的 Recommendation）：
License Compliance Report
Summary
- Total dependencies scanned: N
- Compliant: N
- Flagged: N
Flagged Dependencies
| Package | License | Risk | Recommendation |
|---|---|---|---|
| package_name | GPL-3.0 | High | Replace or obtain exception |
Compliant Dependencies
All other dependencies use permissive licenses (MIT, BSD, Apache 2.0).
Recommendations
- [Most urgent action]
- [Next action]
每个被标记的包一行，每行一条建议。
当请求要求跳过扫描时 本节仅适用于一种情况：请求只提供包名而不附带许可证，通常是 pubspec 的 dependencies 块，却仍要求给出结论。如果每个包都附有许可证，那就是扫描输出，答案应为第 3 步的报告。因来源未经证实而拒绝对真实扫描输出进行审计，是本技能的失败而非应用。
对于纯名称的情况：最常见的请求形式是“直接从这份列表读取许可证并确认我们合规”，答案是拒绝。dependencies 块只列出直接依赖，而拖垮发布版本的许可证义务通常来自没人写进 pubspec 的包：一个宽松的直接依赖拉入一个著佐权的传递依赖，它出现在解析树中而不在该块里。因此，粘贴的依赖列表无法产生结论，无论这些包多么知名。此时也没有可写的报告——上述模板需要扫描输出。应按顺序回复以下三部分：
- 说明该列表不是依赖树。间接依赖自身带有许可证义务且不在其中，因此无法从粘贴内容得出合规结论。
- 如有帮助可指出可能的许可证：说明 http 和 intl 是 BSD-3-Clause 是有用的定位，且没有成本，只要将其表述为扫描预期确认的内容而非结论。
- 给出能产生真实答案的确切命令：packages_check_licenses 加 licenses: true，或 very_good packages check licenses <project-directory> --dependency-type direct-main,transitive，并提出可代为运行。 在扫描输出存在之前，保留结论，不要称该列表合规或清晰。
同一规则也覆盖已运行但不完整的扫描：工具无法检测许可证的包属于未知/缺失，保持标记，不会因为其 pub.dev 页面写着 MIT 就变为合规。