Към всички skills

software-copyright-materials

Fokkyp · Разработка

Generate guided Chinese software copyright application materials from a real project. Use this skill when the user asks for 软件著作权, 软著申请资料, 软著代码材料, 操作手册, 申请表信息, or wants Word/TXT materials for software copyright registration. The workflow analyzes the imported project, extracts real source code, crea

Оригинален текст · няма потвърден превод на български

Първо прочетете инструкцията.

Файлът се зарежда от посочения източник само по ваше действие. Можете да го прочетете тук, да го копирате или да го запазите като .md.

Оригинален SKILL.md
GitHub хранилище
Звезди на репото
5511
Лиценз
MIT
Последна проверка на записа
21.09.2026 г.

Добавете в своя инструмент.

Командата отваря избора на skills от репозитория. Прочетете файла и условията на автора преди изпълнение.

npx skills add Fokkyp/SoftwareCopyright-Skill

Страницата копира текст. Не инсталира и не изпълнява нищо на устройството ви.

Откъс от SKILL.md

Началото на файла на автора, без превод.

软著申请资料生成

这个 skill 生成可审阅、可追溯的软著申请资料。核心原则:

  • 固定输出目录:当前工作目录下的 软件著作权申请资料/。不要默认写到 /tmp、/private/tmp 或其他临时目录。
  • 只有测试 skill 自身时才允许显式指定临时目录;面向用户生成材料时必须写入当前目录。
  • 先生成 Markdown 草稿,用户确认后再生成正式 Word/TXT。
  • 正式 Word/TXT 只能写入 软件著作权申请资料/正式资料/,不要散落在输出目录根部。
  • 正式 Word/TXT 的文字一律使用默认黑色字体,不生成蓝色超链接、主题色标题或其他彩色文字;Markdown 链接写入 Word 时必须转成普通文本。
  • 正式资料中的软件名称必须与 草稿/申请表信息.md 的“软件全称”字段一致;正式生成时以已确认的申请表软件全称为准。
  • 正式代码 Word 页眉中的版本号必须与 草稿/申请表信息.md 的“版本号”字段一致;正式生成时以已确认的申请表版本号为准。
  • 代码材料必须来自真实项目源码,禁止 AI 编造代码。
  • 写申请表和操作手册前,必须先形成模型研判后的 草稿/业务理解.md/json,理解软件业务、行业、目标用户、核心价值和操作流程。
  • 脚本只能收集项目证据、校验字段和生成文件;行业判断、功能抽取、代码抽取选择、操作手册结构必须由模型阅读项目后决定,不得依赖脚本关键字表或固定范本。
  • 优先抽取前端代码:入口、路由、页面、核心组件、接口封装、状态管理、工具函数。
  • 生成代码材料前,必须先生成代码文件候选清单;模型理解项目后填写抽取文件和选择理由,再让用户确认或修改。
  • 代码优先抽取模型和用户确认的、最能体现软件真实功能和运行逻辑的源码;不足 60 页时,从其他相关源码文件补充到 60 页;候选源码仍不足 60 页时,才生成全部代码文档。
  • 源码发现不得依赖编程语言扩展名白名单。脚本默认扫描可读文本文件,并排除明确的文档、配置、媒体、压缩包、二进制、生成物和超大文件;未知扩展名源码同样进入候选清单,再由模型和用户确认是否抽取。
  • 业务证据收集必须发现项目中的文本设计资料以及 DOCX、PDF、ODT、DOC、WPS 等文档;能自动提取正文时写入证据,无法提取时也必须登记路径并提示模型进一步阅读,不能因格式不在文本扩展名列表中而静默遗漏。
  • 操作手册成稿应像真实软件随附的操作说明,而不是研发说明、功能清单或 AI 生成的汇总文。
  • 操作手册草稿必须按传统软著操作手册骨架组织:相关文档、说明、功能特点、系统要求、按真实页面/流程逐章操作、常见问题解答、术语表。一级章节标题使用中文大写序号,例如 一、相关文档,不得使用 (1)、相关文档。相关文档必须用表格指向总体设计、详细设计、测试案例等配套文档。正文尽量使用连续段落,不使用项目符号列表或 1. 2. 3. 编号列表。
  • 每个核心页面都要用普通用户视角说明页面用途、进入位置、用户可见内容、用户动作、输入限制或异常提示、结果反馈和截图预留。不得把章节写成“进入方式:/页面内容:/操作步骤:/操作规则:/操作结果与反馈:”这种字段模板;这些信息要自然合并到段落里。避免代码、框架、接口、状态管理、异步任务等技术化表达;撰写过程中由 agent 自行循环检查、扩写和修正,完整草稿完成后只向用户发起一次整体确认。
  • 操作手册必须去除明显“AI 味”:避免空泛赞美、营销口号、万能句式、每章同一结构、头中尾固定结构、过度对称的排比、没有项目细节的正确废话、频繁使用“旨在、赋能、一站式、智能化、高效便捷、显著提升、强大能力、丰富功能”等套话。每段都应能回答“这个项目里这个功能具体做什么、用户看见什么、操作后有什么结果”。
  • 操作手册生成必须同步输出 草稿/操作手册自检记录.md 和 草稿/操作手册自检记录.json,记录初稿、按项目流程扩写、去制式表达等自检轮次;如果前 3 轮仍发现问题,必须继续补写修正,直到问题清零或记录无法自动修复的原因后再停止。
  • 截图方式只允许用户选择:Playwright CLI 自动截图或用户自行截图。用户选择自动截图后,先检查固定验证版本的 playwright-cli 是否可用;如果用户说现在不截图、先跳过截图或截图失败,操作手册仍必须保留清晰可见的截图预留位置,正式 Word 中也要能看到。
  • 申请表信息中的硬件/系统环境必须让用户确认或填写,不能硬编码。
  • Word 生成统一使用 OfficeCLI 后端;Python 只负责业务分析、代码抽取、门禁和命令编排,不直接解包、重打包或写入 DOCX 包。OfficeCLI 完成正文写入后,必须通过 /theme + raw-set 把主题字体统一为宋体(SimSun)和 Times New Roman,并重新读取主题确认 Calibri、Calibri Light、等线等默认主题字体已消失。
  • OfficeCLI 固定验证版本为 1.0.151,运行时必须设置 OFFICECLI_SKIP_UPDATE=1,不得静默升级、静默安装或回退到 python-docx/Pandoc/.NET 工具包。
  • OfficeCLI 的安装、批处理、分页与校验细节见 references/officecli_backend.md。

路径与按需参考

开始执行前,从当前已加载的 SKILL.md 位置取得本 skill 的绝对目录,记为 <SKILL_DIR>;找到可用的 Python 3.10+ 解释器,记为 <PYTHON>。下面命令中的尖括号是必须替换的占位符,不要依赖 ${CLAUDE_SKILL_DIR} 等某个 agent 专属环境变量,也不要把占位符原样交给 shell。

Целият SKILL.md в GitHub