菜单
评估软件在企业内部使用场景下的许可证、授权与潜在付费要求，输出偏保守的法务预警报告与采购整理。仅用于企业内部安装、运行、开发辅助、办公或内部平台使用，不覆盖 SaaS 对外服务、嵌入产品对外分发、OEM、转售或开源义务外部触发场景。用户提到“软件是否可以商用但仅限公司内部使用”“企业内部使用是否合法”“license 检查”“授权合规”“开源协议风险”“是否需要商业授权”“是否要付费”“年付月付怎么买”等，或提供软件名称、GitHub 链接、官网 URL、包名、本地路径并询问内部使用合规时，使用此 Skill。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Git 提交综合工具：分析改动、规划提交拆分、生成规范 commit message，并优先用 Python fast path 执行提交。支持 --plan/-p、--discuss/-d、--commit/-c、-pc、--push/-P、-pcP，以及 -l/--lang zh|en 控制输出语言（默认 zh）。 用户提到以下需求时使用： - "提交代码"、"commit 一下"、"帮我 git commit"、"git up" - "把改动分成几个提交"、"规划提交"、"拆 commit"、"分批提交" - "生成 commit message"、"写提交信息" - "讨论/修改提交计划"、"--plan/-p"、"--discuss/-d"、"--modify"、"--commit/-c" - "规划并提交"、"一步提交"、"--plan --commit"、"-pc" - "提交并 push"、"规划提交并推送"、"--push"、"-P"、"-pcP" - "英文提交"、"中文提交"、"-l en"、"--lang en"、"-l zh"、"--lang zh"
为包含 package.json 的项目补充 ntl 可读取的 scripts 说明；适用于 ntl、Node Task List、package scripts 描述、维护 ntl.descriptions 等场景。
修复 Windows 环境中的 Codex hooks 语法、入口命令和 stdout JSON schema 问题。用户提到 Codex hooks 在 Windows 报 SessionStart/UserPromptSubmit/PreToolUse/PostToolUse/Stop hook failed、invalid JSON output、invalid pre-tool-use JSON output、decision=allow、裸 sh/python3/.sh、PowerShell hook 包装器、hooks.json 路径展开失败或需要验证 hook 链路时必须使用。
轻量多 Agent 协作技能，用一个 docs/bbs/lite-team-bbs.md 协作板在不同 Agent / session 间手动交接信息。当用户手动指定或切换开发角色（产品、开发、测试、架构、安全审计等）、要求跨 session 角色交接、要求读写或初始化 docs/bbs/lite-team-bbs.md 协作板，或要求结束 / 归档轻量协作时使用。普通单 Agent 任务、自动多 Agent 编排不使用。
远程开发模式规则,rd-mode。触发条件：用户提到 host/server 协作、需要在远程环境运行代码、或涉及 CDP 浏览器操作（abc 命令）时，view 此文件后再执行任务。首次使用或用户调用 `rd-mode --init` 时，执行下方「首次使用 / 初始化」流程生成配置。
Use when working with video or audio files via ffmpeg or ffprobe, including compression, transcoding, trimming, resizing, frame-rate changes, audio extraction, muxing, concat, subtitle burn-in, watermarking, and media inspection. Also use when the user needs a target-size MP4, WebM, or GIF, or when ffmpeg is missing and you must ask the user to provide a binary path or confirm downloading an official build.
| name | software-license-checker |
| description | 评估软件在企业内部使用场景下的许可证、授权与潜在付费要求，输出偏保守的法务预警报告与采购整理。仅用于企业内部安装、运行、开发辅助、办公或内部平台使用，不覆盖 SaaS 对外服务、嵌入产品对外分发、OEM、转售或开源义务外部触发场景。用户提到“软件是否可以商用但仅限公司内部使用”“企业内部使用是否合法”“license 检查”“授权合规”“开源协议风险”“是否需要商业授权”“是否要付费”“年付月付怎么买”等，或提供软件名称、GitHub 链接、官网 URL、包名、本地路径并询问内部使用合规时，使用此 Skill。 |
| version | 1.0.0 |
面向 企业内部使用 场景，基于公开信息做一次 偏保守的法务预警，帮助用户快速识别：
仅输出合规预警，不输出法律定性意见。
若项目存在商业授权、企业版、订阅计划、试用期、席位限制、按量计费或其他潜在付费要求，还要补充一份面向技术负责人和采购的“授权与付费整理”。
仅处理以下场景：
明确不覆盖以下场景；若用户问题实际属于这些场景，先说明超出本 Skill 边界，再请用户改用更合适的分析方式：
默认按 中国团队采购视角 写结论，优先整理中国团队通常能直接看到的购买路径、币种和是否需要联系销售。
优先基于用户给出的名称、链接、路径或包名识别项目，并先收集以下稳定事实：
仅在 缺口会直接影响内部使用结论 时再追问，优先问这些问题：
您说的是哪个项目？ 仅当同名项目不止一个时提问您计划使用哪个版本？ 仅当许可证存在版本差异时提问是否仅限公司内部使用，不会对外提供服务或分发？ 仅当用户描述含糊时提问是否需要修改源码，或只是直接安装使用？ 仅当许可证条款明显依赖修改行为时提问不要为了形式完整而一次性追问所有问题。能先查明的先查明。
优先读取和引用官方来源。证据优先级与冲突处理规则见 references/source-priority.md。 付费方式、公开价格、折扣与未知项的整理规则见 references/pricing-evidence.md。
至少覆盖以下核查项：
常见许可证与内部使用风险判断框架见 references/internal-use-risk-rubric.md。
结论使用以下三级：
低风险：当前证据显示，目标版本在企业内部使用下通常可行，未发现明显附加限制高风险：存在明确限制、商业授权要求、条款冲突，或官方信息显示内部商用需额外授权信息不足：版本不明、来源冲突、条款模糊，或仅能找到低可信度信息，无法保守地下安全结论这不是法律意见。若证据不足，不要勉强下 低风险。
只要出现以下任一情况，就必须在主报告之外补充“授权与付费整理”：
如果完全未发现额外付费要求，也要用一句话明确写“当前未发现公开的额外付费要求”，不要留空。
输出 Markdown，采用“双产物”结构：
主报告：继续输出企业内部使用授权合规预警授权与付费整理：单独附录，面向技术负责人和采购，整理公开付费方式、折扣和未知项主报告结构如下：
# 软件内部使用授权合规预警报告
## 基本信息
- **软件名称**：
- **目标版本**：如未知，明确写“未知”
- **官方仓库 / 官网**：
- **使用范围**：企业内部使用
- **报告生成时间**：YYYY-MM-DD
## 预警结论
> **低风险 / 高风险 / 信息不足**
一句话说明结论，并明确是“企业内部使用”前提下的判断。
## 大白话简明结论
用 3-5 条短句，直接回答普通业务/采购/老板最关心的问题：
- `能不能用`：先说能不能在公司内部用，避免兜圈子
- `前提是什么`：例如是否必须购买商业授权、是否仅限试用期、是否必须锁定某个版本
- `主要风险`：只写最关键的 1-3 个风险点，例如“长期未授权使用风险高”“版本升级后许可证变化”“实际场景超出内部使用边界”
写法要求：
- 必须用大白话，少用法律术语
- 每条尽量控制在 1 句话内
- 不要把 `信息不足` 写成“应该没问题”
- 如果结论是 `高风险`，第一条就直接写清“不能默认免费商用”或“需要先买授权”这类结论
- 如果结论是 `低风险`，也要顺手补一句“前提是仅限企业内部使用/不对外分发”
## 核心依据
### 依据 1：许可证文本或官方许可页
- **证据级别**：官方许可证文本 / 官方许可说明 / 官方 FAQ
- **适用版本**：
- **对结论的影响**：支持低风险 / 支持高风险 / 导致信息不足
- **说明**：
- **来源**：
- **内容时间**：若未知，明确写“未知”
### 依据 2：商业授权或附加限制
- **证据级别**：
- **适用版本**：
- **对结论的影响**：
- **说明**：
- **来源**：
- **内容时间**：
### 依据 3：版本变更或双许可证情况（如有）
- **证据级别**：
- **适用版本**：
- **对结论的影响**：
- **说明**：
- **来源**：
- **内容时间**：
## 风险提示
列出 1-3 条保守建议，例如：
- 建议锁定当前低风险版本，避免升级到许可证已变更版本
- 建议采购前让法务复核商业授权条款
- 建议保留许可证文本、官网截图和采购记录
## 免责声明
本报告基于公开信息与许可证文本做内部合规预警，不构成正式法律意见；如涉及采购、替换成本高或长期关键依赖，建议由法务或知识产权律师复核。
如果触发了付费整理，再追加以下附录：
# 授权与付费整理
## 付费摘要
- **是否需要商业授权**：
- **是否存在公开价格**：有 / 无 / 部分公开
- **默认采购视角**：中国团队采购
- **主要购买路径**：例如官网月付、官网年付、按量计费、联系销售
## 公开付费方式
| 方案 | 计费方式 | 公开价格 | 币种/地区口径 | 适用对象 | 来源 | 内容时间 |
| --- | --- | --- | --- | --- | --- | --- |
| Free / Community | 免费 / 试用 / 限制版 | | | | | |
| Pro / Team / Business | 月付 / 年付 / 按席位 | | | | | |
| Usage-based | 按量 / 按调用 / 按资源 | | | | | |
| Enterprise | 联系销售 / 自定义报价 | 未公开 | | | | |
## 公开折扣与优惠
- **年付优惠**：
- **公开折扣**：例如教育、非营利、初创、限时活动；没有就写“未发现”
- **说明**：
- **来源**：
- **内容时间**：
## 未公开价格与待补信息
- `未公开项`：例如“Enterprise 需联系销售，官网未公开报价”
- `为什么不能直接估价`：例如“仅有 sales 入口，没有官方价格页”
- `建议补采信息`：例如席位数、部署规模、是否需要发票、采购地区、是否要长期锁版本
## 给技术负责人/采购的大白话建议
- 先直接说“是否必须买”
- 再说“如果先试，小团队更适合哪种公开方案”
- 再说“哪些价格还没公开，采购前必须补齐”
- 不要写私下谈判技巧，不要编造企业报价