pan/pixelheros
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
c97c3f36c5ab44b2cd48b565e21acee701b21812
pixelheros/.trae/skills/software-copyright-desk/SKILL.md
panFD c97c3f36c5 chore(trae-skills): 新增软著登记技能并删除旧的英雄信息同步技能 
1. 新增software-copyright-desk技能，用于辅助用户完成计算机软件著作权登记申请
2. 删除HeroInfo_to_CardPoolList.md废弃技能文档
2026-09-14 16:47:18 +08:00

11 KiB
Raw Blame History

name, description
name description
software-copyright-desk Guides users through filling the official software copyright (计算机软件著作权) registration application. Invoke when user asks about 软著 / 软件著作权 / 软件登记 / 著作权人填报 / 源程序 / 设计说明书 / 操作手册 / 软著加急 / 软著流程.

Software Copyright Desk

通过结构化提问，帮用户整理《计算机软件著作权登记申请表》所需的全部材料，并输出可直接粘贴到中国版权保护中心在线填报系统的规范化文本。

适用场景

  • 用户首次办理软著登记，不知道该准备什么
  • 用户已有初稿，需要按登记要求规范化、补齐必填项
  • 用户想确认材料是否齐全、是否有常见退回风险

不适用于：

  • 电子版权认证（项目已停用此线）
  • 软件专利、商标、版权交易等其他知识产权事务

工作流程

第 1 步：明确用户当前进度

先问清用户处于以下哪个阶段，据此决定提问顺序：

  1. 完全空白：还没填过任何材料
  2. 已有部分信息：手头有软件名、著作权人信息、功能描述等
  3. 已有初稿：需要审校、补全、规范

第 2 步：按 Profile 结构收集信息

参考 src/types/index.ts 的字段结构，分四组提问：

软件基本信息（SoftwareInfo）

  • 软件全称（必填，格式建议：品牌/主体名 + 功能 + 软件）
  • 软件简称（可选）
  • 版本号（默认 V1.0）
  • 软件分类（应用软件 / 系统软件 / 支撑软件 / 嵌入式软件 / 中间件 / 游戏软件 / 其他）
  • 开发完成日期（须早于或等于申请日期）
  • 发表状态：未发表 / 已发表（如已发表需补充首次发表日期与地点）
  • 开发方式：独立开发 / 合作开发 / 委托开发 / 下达任务开发
  • 权利取得方式：原始取得 / 继受取得
  • 权利范围：全部权利（默认）

著作权人信息（OwnerInfo）

  • 主体类型：个人 / 企业 / 其他组织
  • 姓名 / 单位全称（须与证件完全一致）
  • 证件类型（依主体类型变化）
  • 证件号码
  • 国籍 / 注册地（默认中国）
  • 地址（与证件地址或营业执照住所一致）
  • 邮编、联系人、联系电话、电子邮箱

软件描述（DescInfo）

  • 硬件环境（CPU、内存、硬盘、网络）
  • 软件环境（操作系统 / 平台）
  • 编程语言
  • 源程序量（行数）
  • 主要功能（200-300 字）
  • 技术特点（150-250 字，可选）

功能模块（ManualModule[]）

  • 用户补充或从"主要功能"拆解得到 6-8 个模块
  • 每个模块名 + 一句话描述

第 3 步：生成材料

按以下顺序产出，每段都可直接复制使用：

  1. 填报速查表：调用 buildSummary 的输出结构（分组：软件基本信息 / 著作权人信息 / 软件描述）
  2. 源程序文档：见下方"源程序专项"章节
  3. 设计说明书 / 用户操作手册：调用 buildManual 的章节模板，可选其一：
    • 设计说明书：引言 / 运行环境 / 功能模块设计 / 数据结构与接口设计 / 安全与异常处理 / 联系方式
    • 用户操作手册：引言 / 运行环境 / 安装与启动 / 功能操作说明 / 常见问题 / 联系方式

源程序专项

源程序文档与说明书是两件不同的材料，必须分别准备和提交。

提交要求（来自登记规范）

  • 取前 30 页 + 后 30 页，不足 60 页时全部提交
  • 每页不少于 50 行有效代码
  • 页眉：左侧标注 软件全称　版本号，右侧标注 第 N 页　共 M 页
  • 9.5pt 等宽字体，每行不超过 84 字符（A4 折行限制）
  • 文件名示例：软件全称_V1.0_源程序.pdf

三种生成方式（按用户掌握情况选用）

方式 A：用户手头有源代码（推荐）

让用户提供源代码文件路径或粘贴代码文本，Skill 直接执行 paginateCode 逻辑：

1. 把 \r\n 替换为 \n，\t 替换为 4 空格
2. 按每页 50 行切分，得到 N 页
3. 若 N > 60：保留前 30 页 + 后 30 页，丢弃中间
4. 给每页加上统一页眉
5. 用 A4 纸张打印 / 导出 PDF

输出格式示例：

============== 第 1 页 共 60 页 ==============
软件全称：星辰记账软件　V1.0
=============================================
[此处为第 1-50 行代码]

============== 第 60 页 共 60 页 ==============
软件全称：星辰记账软件　V1.0
=============================================
[此处为最后 50 行代码]

方式 B：用户仅有软件雏形 / 部分代码

引导用户补齐以下内容后再次提交：

  • 主入口文件（如 main.ts / MainActivity.java / app.py）
  • 核心业务模块（至少 6-8 个关键文件）
  • 与"主要功能 / 功能模块"一一对应的实现片段

如果代码量不足 3000 行（登记常见下限），提示用户补充占位实现 / 注释 / 单元测试，使总行数达到合理区间（3000-10000 行）。

方式 C：用户完全没有代码

明确告知：软著登记不接受纯文字描述代替源程序，必须有真实可运行的代码。Skill 可以：

  • 引导用户先把软件做出来（或至少做出 MVP）
  • 或者按用户描述的功能，生成一份可直接复制运行的参考骨架代码（如 React + Vite + TS 项目骨架、Python Flask API 骨架、Android Activity 骨架），用户拿去做二次开发

骨架生成时遵循：

  • 不依赖任何有版权争议的代码片段
  • 包名 / 模块名用中性占位（com.example.app）
  • 文件头不留第三方 License 声明（避免 reviewCode 第 4 条报错）

源程序审校（调用 reviewCode 规则）

生成或用户提供代码后，必须执行以下检查并报告问题：

# 检查项 等级 处理方式
1 乱码 / 控制字符 > 0.5% error 提示用户上传了二进制文件，需重传
2 空行占比 > 30% warn 删除无意义空行，避免被认定"凑页数"
3 注释行占比 > 40% info 建议补充有效代码
4 含第三方 License / Copyright 声明且与著作权人不一致 error 必须删除或修改
5 实际行数与速查表"源程序量"相差 > 10% warn 同步修改申请表
6 单行字符数 > 84 warn 折行换段
7 含与著作权人无关的手机号 / 邮箱 info 脱敏后提交
8 混入 package-lock.json / node_modules / .min.js 等构建产物 warn 移除后再上传

输出三档结论

  • ✅ 可直接提交：无 error，无 warn
  • ⚠️ 建议修改：无 error，有 warn，列出具体项
  • ❌ 必须修改：有 error，阻断提交

设计说明书与用户操作手册（详细）

Skill 必须能根据"功能模块"列表生成完整的说明书文档，章节结构与项目代码 buildManual 一致：

设计说明书模板

# 软件全称 V1.0
# 设计说明书
著作权人 · 完成日期

## 一、引言
### 1.1 编写目的
本文档用于说明「软件全称（V1.0）」的总体设计思路、功能结构与运行环境，作为计算机软件著作权登记的鉴别材料。
### 1.2 软件概述
主要功能正文（200-300 字）
### 1.3 技术特点
技术特点正文（150-250 字）

## 二、运行环境
### 2.1 硬件环境
### 2.2 软件环境
开发语言：xxx

## 三、功能模块设计
### 3.1 模块A
模块A的处理流程、输入输出
### 3.2 模块B
...

## 四、数据结构与接口设计
（请根据实际补充：核心数据表结构、关键字段说明、模块间接口与调用关系）

## 五、安全与异常处理
（请根据实际补充：权限控制、数据校验、异常捕获与日志记录机制）

## 六、联系方式
技术支持：xxx
联系电话：xxx　电子邮箱：xxx

用户操作手册模板

# 软件全称 V1.0
# 用户操作手册
著作权人 · 完成日期

## 一、引言
### 1.1 编写目的
### 1.2 软件概述

## 二、运行环境
### 2.1 硬件环境
### 2.2 软件环境
开发语言：xxx

## 三、安装与启动
### 3.1 安装步骤
### 3.2 启动与登录

## 四、功能操作说明
### 4.1 模块A
入口位置、操作步骤、预期结果
### 4.2 模块B
...

## 五、常见问题
（请列举 3-5 个使用中的常见问题及解决办法）

## 六、联系方式

写作要求

  • 使用书面语，句式完整
  • 一律用「本软件」指代软件本身
  • 不出现第三方产品名、公司名、品牌名
  • 游戏软件使用玩家、关卡、战斗、背包、任务、商城等术语
  • 其他软件使用用户、模块、数据、接口、权限、校验等术语
  • 操作手册中"操作步骤"用 1. 2. 3. 编号
  • 说明书建议配图 5-10 张（提示用户在 Word 中补）

第 4 步：自动审校

参考 src/lib/core.ts 的 reviewCode 思路，对用户提交的内容做轻量检查：

  • 必填项是否齐全（软件全称、版本号、完成日期、著作权人姓名/证件号/地址/联系方式、运行环境、主要功能）
  • 软件名称、版本号在申请表、源程序页眉、说明书封面是否完全一致
  • 著作权人姓名/单位名是否与平台注册主体一致
  • 主要功能、技术特点是否包含第三方品牌名、公司名
  • 源程序量是否在 3000 行以上、不超过 10 万行
  • 主要功能是否使用书面语、是否完整描述软件做什么、面向谁、解决什么问题
  • 源程序是否通过 reviewCode 的 8 项检查（详见"源程序专项"章节）
  • 说明书 / 操作手册的"软件全称 / 版本号 / 著作权人"与速查表是否完全一致

输出"通过 / 建议修改 / 必须修改"三档结论，列出问题清单。

关键规则

  • 所有对外材料一律使用「本软件」指代软件本身，不出现具体产品名
  • 不夸大功能，不杜撰用户量、市场数据
  • 著作权人姓名 / 单位名必须与证件完全一致，提醒用户核对
  • 软件分类影响描述模板：游戏软件用玩家、关卡、战斗等术语；其他软件用用户、模块、接口、权限等术语
  • 写作风格：书面语、句式完整、不使用口语化表达

输出格式

每次回复使用以下结构：

📋 当前进度：<阶段>
✅ 已收集：<字段列表>
⏳ 待补充：<字段列表>
📝 下一步建议：<具体动作>

材料生成完毕后，附上"提交前自检清单"和"官方办理入口"提示（中国版权保护中心）。

项目代码参考

实现细节可参考 src/lib/core.ts 中的以下函数：

  • buildSummary(p)：生成填报速查表
  • buildManual(p, type, modules)：生成说明书
  • reviewCode(input)：源程序提交前检查规则
  • paginateCode(code, linesPerPage, keepHeadTail)：源程序分页逻辑
  • FEATURE_TEMPLATES / TECH_TEMPLATES：主要功能与技术特点模板
  • HARDWARE_PRESETS / OS_PRESETS / LANGUAGE_PRESETS：硬件/软件/语言常用片段
Reference in New Issue View Git Blame Copy Permalink