Menu
The review-first prompt is selected by default. You can switch to a direct command or download a local copy.
Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/raidenfc/my-skills --skill software-copyrightThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Showing SKILL.md
Based on SOC occupation classification
| name | software-copyright |
| description | 自动生成计算机软件著作权申请资料 |
此 Skill 用于自动分析项目代码和文档，生成计算机软件著作权申请所需的资料。
工作模式：采用渐进式生成，分为两大阶段：
最终产物：
当用户提到需要生成软件著作权申请材料、申请资料或类似请求时，调用此 Skill。
本 Skill 使用以下工具完成各项操作（优先使用原生工具，不可用时 fallback 到 shell）：
| 操作 | 首选工具 | Fallback |
|---|---|---|
| 列出目录 | list_dir | ls -la / find |
| 查找文件 | find_by_name / grep_search | rg --files / find |
| 读取文件 | view_file | cat |
| 写入文件 | write_to_file | shell 重定向 |
| 执行命令 | run_command | — |
| 通知用户 | notify_user | — |
立即询问用户以下必填信息，不要跳过此步骤：
请提供以下软著申请信息：
1. 软件全称（必填）：
- 规则：必须以“软件”、“APP”、“系统”、“平台”结尾（小程序可例外）。
- 注意：中英文之间**不能有空格**。
示例：享赋臻品商城系统
2. 编制单位名称（必填）：
示例：某某科技有限公司
3. 软件版本号（必填）：
- 规则：格式需规范，推荐格式：`V1.0` 或 `1.0`。
示例：V1.0
4. 开发完成日期（必填，格式：YYYY年MM月）：
示例：2024年6月
5. 开发方式（必填，请选择）：
- 独立开发
- 合作开发
- 委托开发
6. 面向行业/领域（选填）：
示例：零售商场、酒店预订、餐饮服务、电器销售
（如不提供，我将根据项目分析推断）
7. 交付目录（选填）：
默认：项目根目录/软著资料/
（如需自定义请提供绝对路径）
重要：在用户回答完这些问题之前，不要进行任何项目分析。
收集用户信息后，开始分析项目：
Monorepo 检测：检查项目根目录是否存在 pnpm-workspace.yaml、lerna.json、或根目录下多个 package.json（如 apps/、packages/ 子目录各有独立 package.json）。若为 Monorepo 项目，询问用户选择：
apps/web）作为扫描目标使用 list_dir / find_by_name 扫描（不可用时 fallback 到 rg --files、find）：
src/, app/, lib/, server/, mobile/, admin/ 等package.json, composer.json, go.mod, pom.xml, requirements.txt 等.doc/, docs/, wiki/, README.md, contexts/ 等根据文件特征判断：
使用 shell 命令执行（排除依赖库且去除空行）：
find . -type f \( \
-name "*.js" -o -name "*.jsx" -o -name "*.ts" -o -name "*.tsx" \
-o -name "*.vue" -o -name "*.go" -o -name "*.php" -o -name "*.java" -o -name "*.py" \
-o -name "*.css" -o -name "*.scss" -o -name "*.less" \
-o -name "*.html" -o -name "*.json" \
-o -name "*.wxml" -o -name "*.wxss" -o -name "*.wxs" \
-o -name "*.swift" -o -name "*.kt" -o -name "*.dart" \
-o -name "*.sql" -o -name "*.sh" -o -name "*.yaml" -o -name "*.yml" \
\) \
-not -path "*/node_modules/*" \
-not -path "*/dist/*" \
-not -path "*/vendor/*" \
-not -path "*/.git/*" \
-not -path "*/.venv/*" \
-not -path "*/__pycache__/*" \
-not -path "*/target/*" \
-not -path "*/build/*" \
-not -path "*/.next/*" \
-not -path "*/.nuxt/*" \
-not -path "*/miniprogram_npm/*" \
-not -path "*/.taro/*" \
-not -path "*/coverage/*" \
-not -path "*/.cache/*" \
-not -path "*/public/*" \
-not -path "*/migrations/*" \
-exec grep -v "^\s*$" {} + 2>/dev/null | wc -l
[!TIP] 上述扩展名列表覆盖了大部分常见技术栈。如有特殊文件类型（如
.rs,.rb,.lua等），可根据项目实际情况增删。
注意：此命令统计的是去除空行后的有效代码行数。
将此结果记录为 Effective_Line_Count。
contexts/context.md - 项目核心上下文README.md - 项目概述.doc/repowiki/系统概述.md - 系统概述.doc/repowiki/功能模块详解/ - 功能模块文档docs/ 目录下的其他文档普通文档分析容易遗漏后台和辅助功能。必须执行以下深度扫描，找出“不容易发现的功能”：
管理端/后台隐形功能：
admin, manage, system, config, auth, role, log.从依赖库推断技术功能：
package.json / pom.xml / go.mod 等依赖文件。redis -> 缓存加速 / 高并发处理jwt / security -> 多重身份认证 / 接口安全防护oss / cos -> 海量文件云存储schedule / cron -> 自动化定时任务websocket / socket -> 实时消息推送excel / csv -> 数据批量导入导出用户端辅助功能：
基于前三步收集的信息，生成《软著规划书.md》并保存到输出目录。
读取模板文件：
{SKILL_DIR}/templates/planning_doc_template.md
扫描与清洗统计
grep -v "^\s*$" 统计有效行数。文件排序与筛选
| 权重 | 文件类型 | 说明 |
|---|---|---|
| 高优 | main.*, app.*, index.*, router.*, App.vue, app.json | 入口文件和路由配置 |
| 普通 | pages/, views/, components/, modules/, screens/ | 页面和组件 |
| 低优 | utils/, helpers/, config/, types/, constants/, store/ | 工具、配置、类型定义 |
FRONT_LINES）。BACK_LINES）。数据准备
分析代码提取功能模块。必须严格区分“用户端”与“管理端”的代码来源，严禁混用。
步骤 0：前端路由分析与去重（必须执行）
在提取功能之前，必须先分析前端路由文件，以"页面"为维度进行归纳，避免遗漏或机械式重复。
src/router/index.js, src/routes.ts, src/app-routing.module.ts 或类似文件。app.json, pages.json。pages/ 或 app/ 目录下的文件结构。urls.py 路由定义@app.route 装饰器扫描@RequestMapping / @GetMapping 注解扫描router.GET/POST 注册router.get/post 或 app.get/post 注册routes/web.php, routes/api.php[!NOTE] 纯后端项目特殊处理：若项目完全没有前端（无
.vue,.jsx,.wxml,.html等 UI 文件），使用说明书应改为"接口使用说明"模式，按 API Endpoint 分组组织功能描述，每个 Endpoint 描述其请求方式、参数、响应及使用场景。
智能筛选与去重：
.vue, .jsx），分析其 UI 和业务逻辑。detail/:id），只归纳为一个"XX详情页"。用户端（User Side）：
.wxml, .axml, .vue (UniApp), .dart (Flutter), .swift, .kt.vue, .jsx, .tsx, .html.blade.php, .jsp, .ejs (仅在无独立前端时使用)UserLogic.php, OrderService.java）作为用户端功能的“对应代码路径”，除非该文件包含了 HTML 输出。管理端（Admin Side）：
router/admin.js, src/admin/routes.ts）或 菜单配置文件（如 menuConfig.js, layout/sider.tsx）。routes/admin.php）和 Controller 结构。path 映射为一个功能页面。admin, manager, backend 目录下的界面代码或 View 文件。提取要求（严格执行）：
将收集的数据填充到模板中，写入 {输出目录}/软著规划书.md。
关键规则：
{Page_Name1} 等占位符，或在占位符位置循环插入新行。重要：生成规划书后，必须通知用户审阅并请求确认。
通知内容应包含：
只有用户确认后，才能进入后续的"执行阶段"（第五步）。
数据来源：直接读取《软著规划书.md》中的信息，不再重新分析。
templates/main_doc.md{软件名称}_{开发完成日期}.md。参考标准的软著文档结构：
如果项目文档中未明确说明，可使用以下默认值：
开发环境（个人电脑）
运行环境（服务器）
核心逻辑：严格按照《软著规划书.md》中的文件索引逐个读取，实时累计行数，确保精确达标。
软著规划书.md，提取 4.1 前 30 页文件列表 和 4.2 后 30 页文件列表。Effective_Line_Count >= 3000 → 分页模式（前 30 页 + 后 30 页）Effective_Line_Count < 3000 → 全量模式（输出所有代码）[!NOTE] 页数计算说明：规划阶段按每页 53 行预估分页（含安全余量），实际在 Word 中排版后每页应 ≥ 50 行。
在读取每个源代码文件内容后，由 AI 在内存中执行以下清洗，然后再写入文档：
敏感信息过滤（正则删除整行）：
Copyright, (c), ©@author, Created byAddress:, Email:, Phone:TODO, FIXME, HACK, XXX 等开发备注console.log, console.warn, console.error, print(), var_dump 等调试语句ApiKey, Secret, Password, Token 等关键词的赋值行）空行处理：
^\s*$)。[!CAUTION] 红线规则：前部和后部代码行数必须各自达到 1590 行才能停止生成。 若行数不足，禁止写入"中间省略"，必须继续添加文件直到达标。
templates/code_material.md 文件头部的 Word 格式设置提示（即 --- 包裹的引用块）。A. 生成前 30 页（强制循环机制）
初始化：accumulated_lines = 0, file_index = 0
WHILE accumulated_lines < 1590:
1. 从前部文件列表取第 file_index 个文件
2. 若文件列表已用尽 → 执行【自动补充机制】
3. 读取文件内容
4. 执行代码清洗（删除空行、敏感信息）
5. 计算清洗后行数 file_lines
6. 写入文件头注释：## 文件：{相对路径}
7. 写入代码块（带语法高亮）
8. accumulated_lines += file_lines
9. 输出进度日志：[前部] 文件 {n}: {filename} | +{file_lines}行 | 累计: {accumulated_lines}/1590
10. file_index++
结束条件：仅当 accumulated_lines >= 1590 时退出循环
记录：Actual_Front_Lines = accumulated_lines
B. 达标校验门禁（写入中间省略前必须通过）
在写入"中间省略"之前，必须通过以下检查：
| 检查项 | 条件 | 未通过处理 |
|---|---|---|
| 前部行数 | Actual_Front_Lines >= 1590 | 返回步骤 A 继续添加文件 |
| 文件列表 | 仍有可用文件 | 执行【自动补充机制】获取更多文件 |
只有检查全部通过，才能写入：\n\n... (中间代码省略) ...\n\n
C. 生成后 30 页（强制循环机制）
初始化：accumulated_lines = 0, file_index = 0
WHILE accumulated_lines < 1590:
1. 从后部文件列表取第 file_index 个文件
2. 若文件列表已用尽 → 执行【自动补充机制】
3. 读取文件内容
4. 执行代码清洗
5. 计算清洗后行数 file_lines
6. 写入文件头注释：## 文件：{相对路径}
7. 写入代码块
8. accumulated_lines += file_lines
9. 输出进度日志：[后部] 文件 {n}: {filename} | +{file_lines}行 | 累计: {accumulated_lines}/1590
10. file_index++
结束条件：仅当 accumulated_lines >= 1590 时退出循环
记录：Actual_Back_Lines = accumulated_lines
重要：必须包含最后一个文件的最后一行代码，确保文档自然结束。
当规划书的文件列表用尽但行数仍不足时，自动执行以下补充策略：
扫描未列入的源代码文件：
find {项目目录} -type f \( -name "*.vue" -o -name "*.js" -o -name "*.ts" -o -name "*.php" -o -name "*.go" \) \
-not -path "*/node_modules/*" -not -path "*/vendor/*" -not -path "*/dist/*"
按优先级排序补充：
pages/）、视图文件（views/）components/）、工具函数（utils/）动态添加到文件列表，继续循环生成直到达标。
更新规划书：将补充的文件追加到规划书的文件列表中。
如果规划书指定为全量模式：
templates/code_material.md 中的格式设置提示。# 全部代码。[!IMPORTANT] 验证是强制门禁：任何一项不通过都禁止标记代码文档生成任务为完成。 必须立即执行修复措施，直到所有项目通过为止。
生成代码文档后，立即执行以下验证：
验证任务：
1. 使用 wc -l 统计实际生成的行数
2. 计算实际页数 = 总行数 ÷ 53
3. 检查是否达标（所有项必须通过）
4. 输出验证报告
验证报告模板：
## 代码文档生成验证报告
| 验证项 | 目标值 | 实际值 | 状态 |
|--------|--------|--------|------|
| 前部代码行数 | ≥ 1590 行 | {Actual_Front_Lines} 行 | {✅/❌} |
| 后部代码行数 | ≥ 1590 行 | {Actual_Back_Lines} 行 | {✅/❌} |
| 总源代码行数 | ≥ 3180 行 | {Total_Lines} 行 | {✅/❌} |
| 预估总页数 | ≥ 60 页 | {Total_Lines ÷ 53} 页 | {✅/❌} |
| 首页内容 | 入口代码 | {是/否} | {✅/❌} |
| 末页内容 | 自然结束 | {是/否} | {✅/❌} |
| 敏感信息过滤 | 无版权信息 | {是/否} | {✅/❌} |
| 空行过滤 | 无纯空行 | {是/否} | {✅/❌} |
### 验证结论
{全部通过 ✅ / 存在问题需要修正 ❌}
验证失败强制处理流程：
IF 任意验证项为 ❌:
1. 分析不达标原因
2. 确定修复方案：
- 行数不足 → 返回 6.3.1 自动补充机制，添加更多文件
- 空行未过滤 → 重新执行代码清洗
- 敏感信息未过滤 → 重新执行敏感信息过滤
3. 重新生成代码文档
4. 再次执行验证
5. 重复上述步骤直到 ALL 验证项为 ✅
ONLY WHEN 所有验证项为 ✅:
→ 允许标记代码文档生成任务完成
→ 允许通知用户生成成功
Copyright 或人名信息{软件名称}_代码文档.md
核心逻辑：遍历《软著规划书.md》中的功能模块清单，按复杂度级别和写作规范逐个展开描述。
软著规划书.md，提取 5.1 用户端功能 和 5.2 管理端功能 清单。templates/user_manual.md。核心原则：像素级 UI 还原 + 业务逻辑串联。不能只写“功能介绍”，必须写“使用流程”。
准备工作：
准备两个内容块变量：User_Content_Block 和 Admin_Content_Block。
对清单中的每个模块，执行以下深度扫描与生成步骤：
读取源码（强制 UI 优先）：
深度解析 UI（像素级扫描）： 你必须要在脑海中构建出页面画面，提取所有可见元素：
关联业务逻辑：
api.submitOrder()），根据 API 命名推断后台发生了什么（如：扣减库存、创建记录）。生成详细内容： 基于上述提取的信息，编写详细的操作步骤。绝不允许一笔带过（例如：“用户填写信息后提交”是不合格的）。
合格示例：
“用户在界面顶部点击‘筛选’按钮，在弹出的下拉菜单中选择‘已发货’状态。列表自动刷新后，用户找到目标订单，点击右侧红色的‘确认收货’按钮。系统弹出二次确认弹窗‘是否确认收到商品？’，用户点击‘确定’后，系统提示‘操作成功’并自动跳转至评价页面。”
A. 复杂度分级策略
| 维度 | 复杂功能 | 中等功能 | 简单功能 |
|---|---|---|---|
| 功能概述 | 100-150 字 (3-5句) | 60-100 字 (2-3句) | 30-50 字 (1-2句) |
| 操作步骤 | 详细展开 (含前置/异常) | 标准步骤 | 简洁步骤 |
| 使用场景 | 必须有 (2-3个) | 推荐有 (1-2个) | 可省略 |
| 功能特点 | 3-5 个 | 2-3 个 | 1-2 个 |
B. 模块结构规范
每个功能模块必须严格遵循以下 Markdown 结构：
#### {模块名称}
**功能概述**
{第一句核心目的}...{最后一句价值}。
**操作步骤**
1. **{步骤标题}**
{前置条件} 用户{动作描述}，系统{响应描述}。
- {细节补充}
2. **{步骤标题}**
...
**使用场景** (复杂/中等功能必需)
- **场景一**：{用户}在{背景}下，通过{操作}达到{目的}。
**功能特点**
- **特点名称**：{特点说明}
拒绝冷冰冰：
强化逻辑闭环：
前置条件 -> 用户动作 -> 系统响应 -> 后续状态 的链条。拒绝简略描述（详细化要求）：
能够反映业务深度：
生成使用说明书后，必须执行以下检查：
验证清单：
{占位符}？验证不通过处理：
{软件名称}_使用说明书.md
读取模板：读取 templates/user_manual.md 的完整原始内容。
清洗示例内容（核心步骤）：
### 1.1 用户端功能 标题，但删除该标题之后、### 1.2 管理端功能 标题之前的所有内容（包括模板中的 "1.1.1 注册登录"、"1.1.2 商品浏览" 等所有示例章节）。### 1.2 管理端功能 标题，但删除该标题之后、## 附录 标题之前的所有内容（包括模板中的 "1.2.1 管理员登录"、"1.2.2 商品管理" 等所有示例章节）。执行组装：
### 1.1 用户端功能 标题下方，插入生成的 User_Content_Block。### 1.2 管理端功能 标题下方，插入生成的 Admin_Content_Block。{软件名称}, {版本号}, {编制日期} 等基本信息占位符。保存文件：
{软件名称}_使用说明书.md。✓ 使用说明书已基于模板组装完成
ℹ 已分析项目代码，提取了 {X} 个用户端功能模块和 {Y} 个管理端功能模块
! 请注意：您需要手动补充功能截图，标记为【需补充截图】的位置
默认路径：{项目根目录}/软著资料/
保存以下文件。务必删除模板顶部的 <!-- ... --> 警告块。
{软件名称}_{日期}.md - 软著主文档{软件名称}_代码文档.md - 代码鉴别材料{软件名称}_使用说明书.md - 使用说明书框架检测 Pandoc：
运行 pandoc --version 检查是否安装。
执行转换：
如果检测到 pandoc，必须将代码文档转换为 .docx 格式。可选将使用说明书也转换。
# 必须转换：代码文档
pandoc "{交付目录}/{软件名称}_代码文档.md" -o "{交付目录}/{软件名称}_代码文档.docx"
# 可选转换：使用说明书（方便用户直接插入截图）
pandoc "{交付目录}/{软件名称}_使用说明书.md" -o "{交付目录}/{软件名称}_使用说明书.docx"
提示：若不使用 Pandoc，也可通过 Typora、VS Code Markdown PDF 插件等方式导出 Word/PDF 格式。
## ✓ 软著资料生成完成
已在以下目录生成资料：
📁 {输出目录路径}
📄 文件清单：
1. {软件名称}_{日期}.md - 软著主文档
2. {软件名称}_代码文档.docx - 代码文档 (请在此文件中调整排版)
3. {软件名称}_代码文档.md - 代码文档 (源文件)
4. {软件名称}_使用说明书.md - 使用说明书框架
打开 {软件名称}_代码文档.docx：
{软件名称} {版本号} 和 第 X 页，确保与提示一致。打开 {软件名称}_使用说明书，在标记为【需补充截图】的位置添加功能截图。
所有材料需加盖公章（如为公司申请）。
#### 8.5 清理临时文件（重要）
1. **识别临时文件**：
- 仅查找本次生成过程创建的临时文件，统一使用前缀命名（如 `tmp_softcopy_*.txt`、`tmp_softcopy_*.md`）。
2. **执行清理**：
- 仅删除匹配 `tmp_softcopy_*` 前缀的临时文件。
- **严禁删除**：`{软件名称}_代码文档.docx`、`*.md` 以及任何最终交付物。**务必保留 Word 文档**。
---
## 重要提示
### 技术特点描述参考
可从以下角度描述：
- 架构设计（前后端分离、微服务、分布式等）
- 性能优化（缓存机制、负载均衡、并发处理等）
- 安全性（数据加密、身份认证、权限管理等）
- 用户体验（响应式设计、实时更新等）
- 数据处理（大数据分析、数据可视化等）
- 跨平台支持（多端兼容、小程序/Web/App 等）
### 代码提取注意事项
- 优先选择 `.js`, `.vue`, `.go`, `.php`, `.java`, `.py` 等源代码文件
- 排除 `node_modules/`, `vendor/`, `.git/`, `dist/`, `build/`, `test/` 等目录
- 可保留功能性注释；应移除版权声明、作者姓名、联系方式等敏感信息
- 确保代码连续性，避免中途跳转
---
## 错误处理
### 如果找不到项目文档
- 提示用户项目缺少文档，建议先创建 `README.md` 或 `contexts/context.md`
- 询问用户是否可以口头描述项目功能，由你记录后生成
### 如果无法识别技术栈
- 列出发现的文件类型
- 请用户确认使用的技术栈
### 如果代码量过少
- 提示用户源程序量较少，可能不符合软著申请要求（通常需要 3000 行以上）
- 询问是否继续生成
---
## 模板引用
执行时使用以下模板文件：
- `{SKILL_DIR}/templates/planning_doc_template.md`
- `{SKILL_DIR}/templates/main_doc.md`
- `{SKILL_DIR}/templates/user_manual.md`
- `{SKILL_DIR}/templates/code_material.md`
---
## 断点恢复机制
本 Skill 执行流程较长，为防止中断导致丢失进度，每完成一个主要阶段后，自动将进度写入 `{输出目录}/.progress.json`：
```json
{
"current_step": 5,
"completed_steps": [1, 2, 3, 4],
"last_updated": "2024-06-15T10:30:00",
"outputs": {
"planning_doc": "软著规划书.md",
"main_doc": null,
"code_doc": null,
"user_manual": null
}
}
恢复逻辑：每次启动时，检查 {输出目录}/.progress.json 是否存在。若存在且 completed_steps 不为空，询问用户是否从上次中断处继续（跳过已完成的步骤），还是重新开始。
此 Skill 的核心流程：
核心思想：通过"规划书"将复杂的生成任务解耦，确保源代码行数达标、功能描述详实。
确保每个步骤都清晰告知用户进度，遇到不确定的信息主动询问。
对于每个识别出的页面/模块，必须提取以下 5 个字段：
首页）。轮播图展示, 推荐列表）。数量要求（尽可能全面）：