Software copyright

Skill raidenfc/my-skills/software-copyright

自动生成计算机软件著作权申请资料From its SKILL.md

Install

npx -y skills add raidenfc/my-skills --skill software-copyright

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

33.9 KB, ~12.4k tokens by cl100k_base, as published. Nobody here has run it

软著资料生成 Skill

概述

此 Skill 用于自动分析项目代码和文档，生成计算机软件著作权申请所需的资料。

工作模式：采用渐进式生成，分为两大阶段：

规划阶段：分析项目并生成《软著规划书》，用户确认后进入执行阶段
执行阶段：基于规划书逐步生成三类资料文档

最终产物：

软著主文档
代码文档（60 页）
使用说明书

使用方式

当用户提到需要生成软件著作权申请材料、申请资料或类似请求时，调用此 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. 交付目录（选填）：
   默认：项目根目录/软著资料/
   （如需自定义请提供绝对路径）

重要：在用户回答完这些问题之前，不要进行任何项目分析。

第二步：分析项目结构

收集用户信息后，开始分析项目：

2.1 确定项目根目录

查看用户当前工作区路径
确认项目根目录位置

Monorepo 检测：检查项目根目录是否存在 pnpm-workspace.yaml、lerna.json、或根目录下多个 package.json（如 apps/、packages/ 子目录各有独立 package.json）。若为 Monorepo 项目，询问用户选择：

a) 指定某个子项目（如 apps/web）作为扫描目标
b) 合并扫描所有子项目

2.2 扫描项目文件结构

使用 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/ 等

2.3 识别技术栈

根据文件特征判断：

前端：React, Vue, Angular, Next.js, Nuxt.js 等
后端：Node.js, PHP, Go, Java, Python 等
小程序：UniApp, 微信小程序原生等
数据库：MySQL, PostgreSQL, MongoDB 等
其他：Nginx, Redis, Docker 等

2.4 统计代码行数（有效行数）

使用 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。

第三步：读取项目文档

3.1 优先读取以下文档

contexts/context.md - 项目核心上下文
README.md - 项目概述
.doc/repowiki/系统概述.md - 系统概述
.doc/repowiki/功能模块详解/ - 功能模块文档
docs/ 目录下的其他文档

3.2 提取关键信息

项目背景和开发目的
主要功能模块列表
技术特点和创新点
系统架构说明

3.3 深度功能挖掘（重点执行）

普通文档分析容易遗漏后台和辅助功能。必须执行以下深度扫描，找出“不容易发现的功能”：

管理端/后台隐形功能：
- 扫描关键词：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》并保存到输出目录。

4.1 读取规划书模板

读取模板文件： {SKILL_DIR}/templates/planning_doc_template.md

4.2 生成代码文件索引（核心逻辑）

扫描与清洗统计
- 遍历源码文件，对每个文件执行 grep -v "^\s*$" 统计有效行数。
- 注意：必须使用清洗后的行数，否则生成的文档行数将不足。

文件排序与筛选

按照 高权重 → 普通权重 → 低权重 的顺序排列文件。权重定义如下：

权重	文件类型	说明
高优	`main.`, `app.`, `index.`, `router.`, `App.vue`, `app.json`	入口文件和路由配置
普通	`pages/`, `views/`, `components/`, `modules/`, `screens/`	页面和组件
低优	`utils/`, `helpers/`, `config/`, `types/`, `constants/`, `store/`	工具、配置、类型定义

前 30 页选择：从头部开始累加，直到累计行数 ≥ 1590 行（FRONT_LINES）。
后 30 页选择：从尾部倒推，直到累计行数 ≥ 1590 行（BACK_LINES）。

数据准备
- 准备 file_list 数据，包含：文件路径、单文件行数、当前累计行数。

4.3 生成功能模块清单（核心关键）

分析代码提取功能模块。必须严格区分“用户端”与“管理端”的代码来源，严禁混用。

步骤 0：前端路由分析与去重（必须执行）

在提取功能之前，必须先分析前端路由文件，以"页面"为维度进行归纳，避免遗漏或机械式重复。

定位路由文件：
- Vue/React Web: 查找 src/router/index.js, src/routes.ts, src/app-routing.module.ts 或类似文件。
- Mini-program: 查找 app.json, pages.json。
- Next.js/Nuxt.js: 扫描 pages/ 或 app/ 目录下的文件结构。
- 纯后端项目（无前端 UI 文件时），按以下方式定位路由等效文件：
  - Django: urls.py 路由定义
  - Flask: @app.route 装饰器扫描
  - Spring Boot: @RequestMapping / @GetMapping 注解扫描
  - Go Gin/Echo: router.GET/POST 注册
  - Express/Koa: router.get/post 或 app.get/post 注册
  - Laravel: routes/web.php, routes/api.php

[!NOTE] 纯后端项目特殊处理：若项目完全没有前端（无 .vue, .jsx, .wxml, .html 等 UI 文件），使用说明书应改为"接口使用说明"模式，按 API Endpoint 分组组织功能描述，每个 Endpoint 描述其请求方式、参数、响应及使用场景。

智能筛选与去重：
- 读取组件内容：进入路由对应的组件文件（如 .vue, .jsx），分析其 UI 和业务逻辑。
- 去重逻辑：
  - 合并同类项：如果发现多个路由指向相似的页面（如 detail/:id），只归纳为一个"XX详情页"。
  - 排除无效页面：忽略纯静态的协议页、过渡页或无实质功能的空白页。
  - 内容审查：只有包含用户交互（表单、按钮）或动态数据展示的页面才生成模块。
用户端（User Side）：
- 核心原则：必须优先读取前端/客户端的 UI 代码。只有在完全没有前端代码时（如纯后端渲染），才允许读取后端 Controller。
- 扫描优先级（按顺序查找）：
  1. 小程序/App: .wxml, .axml, .vue (UniApp), .dart (Flutter), .swift, .kt
  2. Web 前端: .vue, .jsx, .tsx, .html
  3. 模板引擎: .blade.php, .jsp, .ejs (仅在无独立前端时使用)
- 禁止行为：禁止使用 pure Backend Logic（如 UserLogic.php, OrderService.java）作为用户端功能的“对应代码路径”，除非该文件包含了 HTML 输出。
管理端（Admin Side）：
- 路由/菜单分析（前端优先）：
  - 首选：寻找 管理后台的前端路由（如 router/admin.js, src/admin/routes.ts）或 菜单配置文件（如 menuConfig.js, layout/sider.tsx）。
  - 次选（仅当无独立前端时）：分析 MVC 框架的 Admin 路由（如 routes/admin.php）和 Controller 结构。
- 页面归纳：
  - 核心原则：必须按前端页面视角归纳。例如"商品列表页"和"商品编辑页"是两个页面，而不是简单的"商品管理"一个大模块。
  - 将前端路由中的 path 映射为一个功能页面。
- 优先寻找 admin, manager, backend 目录下的界面代码或 View 文件。
提取要求（严格执行）：
- 对于每个识别出的页面/模块，必须提取以下 5 个字段：
  1. 页面名称：从路由 path 或 title 提取（如 首页）。
  2. 功能点：页面内的主要功能列表（如 轮播图展示, 推荐列表）。
  3. 复杂度：简单/中等/复杂。
  4. 代码路径：对应的组件文件路径。
  5. 主要操作点：基于 UI 元素的交互描述（必须包含动词）。例如：“点击‘立即购买’ -> 弹出规格选择 -> 确认支付”。
- 数量要求（尽可能全面）：
  - 不要只提取最少的几个，而是尽可能覆盖路由文件中定义的业务页面。
  - 用户端：建议提取 10~20 个 模块（覆盖首页、分类、购物车、个人中心、订单、设置等）。
  - 管理端：建议提取 5~10 个 模块（覆盖控制台、商品、订单、用户、营销、财务、设置等）。

4.4 写入规划书

将收集的数据填充到模板中，写入 {输出目录}/软著规划书.md。

关键规则：

严禁修改表格表头：必须保留模板中的 6 列结构（页面名称 | 功能点 | 复杂度 | 代码路径 | 主要操作点）。
请勿重写表格：请直接替换模板中的 {Page_Name1} 等占位符，或在占位符位置循环插入新行。
未识别到的字段：如果某个字段为空，请填写 "无" 或 "N/A"，不要删除列。

4.5 请求用户确认

重要：生成规划书后，必须通知用户审阅并请求确认。

通知内容应包含：

规划书已生成及其路径。
核心数据摘要：
- 预计总页数：{Total_Pages}
- 用户端模块数：{User_Modules}
- 管理端模块数：{Admin_Modules}
询问用户是否同意按此规划生成最终文档。

只有用户确认后，才能进入后续的"执行阶段"（第五步）。

第五步：生成软著主文档（基于规划书）

数据来源：直接读取《软著规划书.md》中的信息，不再重新分析。

读取数据：从规划书中提取基本信息、硬件环境、软件环境、源程序量（总行数）、主要功能列表、技术特点。
读取模板：templates/main_doc.md
填充生成：将提取的数据填充到模板中。
保存文件：文件名 {软件名称}_{开发完成日期}.md。

参考标准的软著文档结构：

开发的硬件环境
运行的硬件环境
开发该软件的操作系统
软件开发环境 / 开发工具
该软件的运行平台 / 操作系统
软件运行支撑环境 / 支持软件
源程序量
开发目的
面向领域 / 行业
软件的主要功能
软件的技术特点
代码文档（占位）
文档鉴别材料（占位）

硬件环境推断规则

如果项目文档中未明确说明，可使用以下默认值：

开发环境（个人电脑）

CPU：4核
内存：8GB
系统盘：256GB SSD
带宽：100Mbps

运行环境（服务器）

小型项目：CPU 2核，内存 4GB，系统盘 100GB SSD，带宽 5Mbps
中型项目：CPU 4核，内存 8GB，系统盘 200GB SSD，带宽 10Mbps
大型项目：CPU 8核，内存 16GB，系统盘 500GB SSD，带宽 20Mbps

第六步：生成代码文档（基于规划书）

核心逻辑：严格按照《软著规划书.md》中的文件索引逐个读取，实时累计行数，确保精确达标。

6.1 读取规划书与准备

读取 软著规划书.md，提取 4.1 前 30 页文件列表 和 4.2 后 30 页文件列表。
确认生成模式：
- 若 Effective_Line_Count >= 3000 → 分页模式（前 30 页 + 后 30 页）
- 若 Effective_Line_Count < 3000 → 全量模式（输出所有代码）

[!NOTE] 页数计算说明：规划阶段按每页 53 行预估分页（含安全余量），实际在 Word 中排版后每页应 ≥ 50 行。

6.2 代码清洗规则（严格执行）

在读取每个源代码文件内容后，由 AI 在内存中执行以下清洗，然后再写入文档：

敏感信息过滤（正则删除整行）：
- Copyright, (c), ©
- @author, Created by
- Address:, Email:, Phone:
- 具体的日期时间
- TODO, FIXME, HACK, XXX 等开发备注
- console.log, console.warn, console.error, print(), var_dump 等调试语句
- 硬编码的密钥、Token（包含 ApiKey, Secret, Password, Token 等关键词的赋值行）
空行处理：
- 删除所有纯空行 (^\s*$)。
- 仅保留代码和功能性注释（如类说明、方法说明）。

6.3 执行生成（分页模式）—— 强制达标机制

[!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

重要：必须包含最后一个文件的最后一行代码，确保文档自然结束。

6.3.1 自动补充机制（文件不足时触发）

当规划书的文件列表用尽但行数仍不足时，自动执行以下补充策略：

扫描未列入的源代码文件：

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/）
- 低优先级：配置文件、类型定义
动态添加到文件列表，继续循环生成直到达标。
更新规划书：将补充的文件追加到规划书的文件列表中。

6.4 执行生成（全量模式）

如果规划书指定为全量模式：

写入顶部格式提示：同样先写入 templates/code_material.md 中的格式设置提示。
写入标题 # 全部代码。
遍历列表中的所有文件，逐个清洗写入，不做截断。

6.5 生成后验证（强制门禁 —— 必须全部通过）

[!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 所有验证项为 ✅:
    → 允许标记代码文档生成任务完成
    → 允许通知用户生成成功

6.6 最终检查清单（所有项必须勾选）

确认第 1 页是入口代码（main/index/app）
确认前 30 页行数 ≥ 1590 行
确认后 30 页行数 ≥ 1590 行
确认结束处是自然结束代码
确认没有任何 Copyright 或人名信息
确认代码中没有空行（紧凑排版）
验证报告所有项为 ✅

文件名

{软件名称}_代码文档.md

第七步：生成使用说明书（基于规划书）

核心逻辑：遍历《软著规划书.md》中的功能模块清单，按复杂度级别和写作规范逐个展开描述。

7.1 读取规划书与准备

读取 软著规划书.md，提取 5.1 用户端功能 和 5.2 管理端功能 清单。
识别每个模块的复杂度（简单/中等/复杂）和对应代码路径。
读取模板：templates/user_manual.md。

7.2 逐模块生成流程

核心原则：像素级 UI 还原 + 业务逻辑串联。不能只写“功能介绍”，必须写“使用流程”。

准备工作：准备两个内容块变量：User_Content_Block 和 Admin_Content_Block。

对清单中的每个模块，执行以下深度扫描与生成步骤：

读取源码（强制 UI 优先）：
- 读取该模块对应的 UI 界面代码（.vue, .wxml, .jsx 等）。
- 如果源码引用了子组件，必须推断子组件的含义，或者有条件时进一步查看子组件。
深度解析 UI（像素级扫描）：你必须要在脑海中构建出页面画面，提取所有可见元素：
- 交互控件：提取所有 Button（文案是什么？）、Input（Placeholder是什么？）、Select（选项有哪些？）、Checkbox/Switch。
- 展示信息：提取页面展示的关键字段（如：订单号、金额、红色高亮的状态文字）。
- 反馈机制：提取 Toast 提示、Modal 弹窗、Validator 错误红字。
关联业务逻辑：
- 如果代码中调用了 API（如 api.submitOrder()），根据 API 命名推断后台发生了什么（如：扣减库存、创建记录）。
生成详细内容：基于上述提取的信息，编写详细的操作步骤。绝不允许一笔带过（例如：“用户填写信息后提交”是不合格的）。

合格示例：

“用户在界面顶部点击‘筛选’按钮，在弹出的下拉菜单中选择‘已发货’状态。列表自动刷新后，用户找到目标订单，点击右侧红色的‘确认收货’按钮。系统弹出二次确认弹窗‘是否确认收到商品？’，用户点击‘确定’后，系统提示‘操作成功’并自动跳转至评价页面。”

7.3 生成策略与写作规范（严格执行）

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. **{步骤标题}**
   ...

**使用场景** (复杂/中等功能必需)
- **场景一**：{用户}在{背景}下，通过{操作}达到{目的}。

**功能特点**
- **特点名称**：{特点说明}

7.4 关键写作要求（红线规则）

拒绝冷冰冰：
- ❌ "点击提交按钮。"
- ✅ "用户确认信息无误后，点击'提交'按钮，系统将自动验证数据并保存。"
强化逻辑闭环：
- 必须遵循 前置条件 -> 用户动作 -> 系统响应 -> 后续状态 的链条。
- 使用 "首先"、"接着"、"随后"、"完成后" 等连接词。
拒绝简略描述（详细化要求）：
- ❌ 错误示范：“进入页面，填写信息，点击保存。”（太简略，不知道填了什么，点了哪个按钮）
- ✅ 正确示范（需包含 UI 细节）： “用户进入个人中心，点击头像下方的‘编辑资料’图标。在编辑页面中，用户可以点击头像区域触发‘更换头像’弹窗，选择本地图片上传；随后在‘昵称’输入框中修改名称（支持 emoji）。修改完成后，点击底部深蓝色的‘保存修改’长按钮，若格式正确，顶部弹出‘保存成功’绿色提示条。”
能够反映业务深度：
- 结合代码逻辑，描述数据流转。例如不只是“点击支付”，而是“点击支付唤起微信收银台，支付成功后系统自动扣除优惠券并生成核销码”。

7.5 生成后验证与处理

生成使用说明书后，必须执行以下检查：

验证清单：

用户端是否包含 ≥ 5 个模块？
管理端是否包含 ≥ 3 个模块？
复杂模块是否有"使用场景"？
简单模块描述是否清晰完整？
是否消除了所有 {占位符}？
描述是否包含"系统响应"？

验证不通过处理：

如果字数不足或描述过于简单，必须重新生成该模块。
如果缺少模块，从规划书中补充更多模块。

7.6 最终检查清单

确认文档结构完整
确认所有占位符已替换
确认截图位置已标记

文件名

{软件名称}_使用说明书.md

7.7 组装与最终生成（关键）

读取模板：读取 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。

7.8 生成提示

✓ 使用说明书已基于模板组装完成
ℹ 已分析项目代码，提取了 {X} 个用户端功能模块和 {Y} 个管理端功能模块
! 请注意：您需要手动补充功能截图，标记为【需补充截图】的位置

第八步：输出与转换

8.1 创建输出目录

默认路径：{项目根目录}/软著资料/

8.2 保存 Markdown 文件

保存以下文件。务必删除模板顶部的  警告块。

{软件名称}_{日期}.md - 软著主文档
{软件名称}_代码文档.md - 代码鉴别材料
{软件名称}_使用说明书.md - 使用说明书框架

8.3 转换为 Word (Pandoc)

检测 Pandoc：运行 pandoc --version 检查是否安装。

执行转换：如果检测到 pandoc，必须将代码文档转换为 .docx 格式。可选将使用说明书也转换。

# 必须转换：代码文档
pandoc "{交付目录}/{软件名称}_代码文档.md" -o "{交付目录}/{软件名称}_代码文档.docx"

# 可选转换：使用说明书（方便用户直接插入截图）
pandoc "{交付目录}/{软件名称}_使用说明书.md" -o "{交付目录}/{软件名称}_使用说明书.docx"

提示：若不使用 Pandoc，也可通过 Typora、VS Code Markdown PDF 插件等方式导出 Word/PDF 格式。

8.4 生成完成提示

## ✓ 软著资料生成完成

已在以下目录生成资料：
📁 {输出目录路径}

📄 文件清单：
1. {软件名称}_{日期}.md - 软著主文档
2. {软件名称}_代码文档.docx - 代码文档 (请在此文件中调整排版)
3. {软件名称}_代码文档.md - 代码文档 (源文件)
4. {软件名称}_使用说明书.md - 使用说明书框架

📝 后续操作

1. 调整代码材料格式 (重要)

打开 {软件名称}_代码文档.docx：

全选全文，将字体调整为 小六号 / 8号（或更小）。
确保调整字体后，每一页的代码行数 不少于 50 行。
设置页眉：在 Word 中双击页眉区域，添加 {软件名称} {版本号} 和 第 X 页，确保与提示一致。

2. 补充使用说明书截图

打开 {软件名称}_使用说明书，在标记为【需补充截图】的位置添加功能截图。

3. 提交材料

所有材料需加盖公章（如为公司申请）。


#### 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 的核心流程：

信息收集：询问用户软件名称、单位等基本信息
规划先行：分析项目结构，生成《软著规划书》并计算代码页数
用户确认：展示规划书，确认功能模块和文件清单无误
执行生成：基于规划书的数据，精确生成三份核心材料
质量验证：生成的每份文档都经过清洗规则和质量标准的自动验证
后续指导：提示用户补充截图

核心思想：通过"规划书"将复杂的生成任务解耦，确保源代码行数达标、功能描述详实。

确保每个步骤都清晰告知用户进度，遇到不确定的信息主动询问。