Open-source project
Fokkyp/SoftwareCopyright-Skill avatar
Fokkyp/SoftwareCopyright-Skill

Fokkyp SoftwareCopyright-Skill: generate Chinese software copyright filing documents from a local project

中国软件著作权申请材料 生成器 Skills,本 Skills 通过阅读本地项目,自动生成全套 .docx 软著申请材料,全开源,无须再付费购买任何软著申请服务

5,680 stars804 forksPythonMIT

At a glance

What is it?
A Python-based skill for coding agents that reads your own repository and produces the DOCX operation manual, code excerpts and application form fields needed for a Chinese software copyright registration. It solves a paperwork problem, not a legal one.
Who is it for?
Use it if you already have a real codebase and a coding agent that loads local skills, and you want the document assembly done on your own machine under the MIT licence. Do not use it if your project has no readable source, if you expect it to decide what is registrable, or if you cannot install OfficeCLI 1.0.151 globally.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 6 days ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 29, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What the skill actually removes from the filing workload

Software copyright registration in China is not a hard legal problem for most developers. It is a document assembly problem. The application form has fields that must be filled consistently, the operation manual has to read like a manual rather than a feature list, and the code material has to be cut to the first 30 and last 30 pages under the common identification-material rule. The README is blunt about why people pay for this: what the paid service usually delivers is document tidying, not legal work.

This project targets that gap. It is a skill directory, not a standalone application. It is meant to be dropped into a coding agent that supports a local skill directory, pointed at your project, and driven through a guided flow that ends with a `软件著作权申请资料/` folder in your own working directory. The audience is narrow and specific: developers who have a real repository, who can run a coding agent locally, and who would rather keep product details on their own machine than exchange them with an agency.

The README states the source code material must come from the applicant's own project and that the skill does not generate project code with AI. That constraint is the whole design premise. A tool that invented source would produce material that fails the first serious review, so the skill instead selects and extracts from files that already exist.

How the pipeline runs: environment gate, confirmation stops, DOCX output

The flow has a gate at the front and checkpoints throughout. On start, the skill runs an environment check and writes `软件著作权申请资料/环境检查.md` and `软件著作权申请资料/环境检查.json`. Those files report whether Python meets 3.10+, whether OfficeCLI is present at the pinned version, whether native Word page counting is available on the platform, and where materials will be written.

If OfficeCLI is missing or the version does not match, the README says the agent stops and offers three choices: install globally with the official script, switch to the pinned `1.0.151`, or accept compatibility risk and pass `--allow-untested-officecli`. There is no silent fallback. The README is explicit that the project no longer uses LibreOffice, Pandoc, a bundled DOCX skill, .NET tooling or a portable binary as a backup path, and that it will not pretend to generate a DOCX when OfficeCLI is unavailable.

Source selection is content-based rather than extension-based. The README states the scripts identify readable source by file content and exclude documentation, configuration, binaries and generated files, so Godot, GameMaker, C/C++, Dart and new script extensions do not need whitelisting. Markdown, TXT, DOCX, PDF, ODT, DOC and WPS files, plus documents whose names hint at design, requirements or architecture, are pulled in as business evidence. Binary documents that cannot be parsed still get their paths registered so the model can read them later.

After extraction, the skill pauses at several points: business framing, application form fields, code selection, screenshot method and the final Markdown draft. Confirmed output goes to `软件著作权申请资料/正式资料/` as an operation manual DOCX, front-30 and back-30 code DOCX files, and `申请表信息.txt`. The README also notes that the theme fonts are normalised to SimSun and Times New Roman through OfficeCLI, then re-read for verification, because WPS complains about missing DengXian, Calibri and Calibri Light.

Installing the skill and running it on a real project

Clone the repository and keep in mind that the repository root is not the skill. The actual skill lives in `software-copyright-materials/`, and the README warns against copying the root as if it were a single skill.

bash
git clone https://github.com/Fokkyp/SoftwareCopyright-Skill.git
cd SoftwareCopyright-Skill

If you do not use Git, the README points to `Code` then `Download ZIP` on the GitHub page. After extracting, you should see the `software-copyright-materials/` directory at the top level.

Next, copy that directory into the skill location your coding agent expects. The README gives this form, with the target path left to your agent's documentation:

bash
AGENT_SKILLS_DIR="<你的 coding agent 软件要求的 skill 目录>"
mkdir -p "$AGENT_SKILLS_DIR"
cp -R software-copyright-materials "$AGENT_SKILLS_DIR/"

If your agent supports project-level skills, the README offers the same pattern with a `PROJECT_SKILLS_DIR` variable. Either way, reload the session or refresh the skill list afterwards.

OfficeCLI is a hard requirement and is not vendored. On Windows PowerShell the README gives the official installer:

powershell
irm https://raw.githubusercontent.com/iOfficeAI/OfficeCLI/main/install.ps1 | iex

On macOS or Linux, the equivalent is:

bash
curl -fsSL https://raw.githubusercontent.com/iOfficeAI/OfficeCLI/main/install.sh | bash

Restart the coding agent so the new process picks up PATH, then check the version. The README states the expected output is `1.0.151`:

bash
officecli --version

With the skill loaded and your project open in the agent, the invocation is a plain sentence: `使用 software-copyright-materials 生成当前项目的软件著作权申请资料`. The agent then walks you through the confirmation stops and writes output under `软件著作权申请资料/` in the current project directory. The repository ships a worked example at `生成demo/软件著作权申请资料/` with a `草稿/` folder and a `正式资料/` folder containing `申请表信息.txt`, an operation manual DOCX and the two code DOCX files, so you can see the shape of the result before running anything.

Where the design bites: OfficeCLI pinning, pagination and screenshots

The OfficeCLI dependency is the sharpest constraint. It must be installed globally, it must be `1.0.151`, and the README says automatic updates are disabled during generation so the same material does not drift between tool versions. That is a defensible reproducibility choice, but it means you cannot treat this as a pure Python package you pip install and forget. If your environment cannot install global binaries, or if your agent runs in a sandbox without PATH control, the gate fails and you are choosing between a risky override and no DOCX at all.

Pagination is the second soft spot, and the README is honest about it. Code paragraphs are written continuously into the DOCX and Word breaks pages according to available space. OfficeCLI can call Word to obtain the real final page count, but only when Word is present. Without Word you still get generation, OpenXML validation and an OfficeCLI HTML preview, yet the README states you must manually check pagination in Word or WPS before submitting. If the 30-page boundary matters to your filing, an unverified page count is a real risk.

Screenshots are optional but the default path has its own prerequisites. Automatic capture needs Node.js 18+, npm and `@playwright/[email protected]`, installed globally so it does not touch the analysed project's `package.json`. The skill resolves `playwright-cli` from PATH first and then from the `npm prefix -g` executable directory, which the README says avoids restarting the agent after a global npm install. Chrome is preferred; an extra browser runtime is installed only with consent. If you skip automation, images go into `软件著作权申请资料/用户截图/`, or you can decline screenshots and leave visible placeholders in the manual.

The clearest wrong-tool case is a project with little or no readable source. Because code material is extracted from real files, a repository that is mostly generated code, vendored dependencies or binary assets gives the extractor very little to work with. The skill will not fill the gap by writing code for you.

Compared with a paid filing agency

The obvious alternative is a paid agent or document-tidying service, which is precisely what the README positions against. The difference is not price alone, it is where the material lives and who controls the wording. An agency asks you to hand over project details, then returns documents you review after the fact. This skill keeps the project on your machine, keeps the Markdown drafts editable, and puts you in the loop at each confirmation stop.

That trade runs the other way too. An agency absorbs the back-and-forth with the filing system and may catch field-level mistakes from experience. This tool gives you a generated `申请表信息.txt` to copy into the official site yourself, and the README states plainly that users must check whether the generated material matches the actual project and the current requirements on the official site. There is no review layer. If you want someone else to own correctness, this is not that.

A second alternative is doing it by hand in Word. That is entirely viable for a small project, and it avoids the OfficeCLI pin entirely. The skill earns its place when the repository is large enough that choosing representative code files and writing a manual that reflects real pages and features becomes the slow part.

Licence, maintenance and what an upgrade costs you

The project is MIT licensed, which the README confirms, so you can use, copy, modify and redistribute it, including as the basis for your own version. The README adds one condition in plain language: you still have to check that the generated material matches your project and the official requirements. MIT covers the code, not the accuracy of what it produces, and nothing here is legal advice.

The repository is not archived and the last push was on 2026-09-18, the same day v2.5 was released. Earlier releases were v1.3 on 2026-07-18 and v1.2 on 2026-06-25, so the release cadence over the visible window is roughly monthly to biweekly. The version numbers jump from v1.3 to v2.5, which the release list does not explain.

Upgrade cost is dominated by the OfficeCLI pin rather than by the Python code. Moving to a newer OfficeCLI means either passing `--allow-untested-officecli` and accepting that the README calls it a compatibility risk, or waiting until the skill pins the new version. Because automatic updates are disabled during generation, an upgrade is a deliberate act, not something that happens underneath you. The Python side needs 3.10+ and the README states you can use the agent's own runtime without installing `python-docx` separately.

Editorial conclusion

Use it if you already have a real codebase and a coding agent that loads local skills, and you want the document assembly done on your own machine under the MIT licence. Do not use it if your project has no readable source, if you expect it to decide what is registrable, or if you cannot install OfficeCLI 1.0.151 globally. Before you submit anything, verify three things: that every code excerpt traces to a file you actually wrote, that the software name and version string match across 申请表信息.txt and both DOCX outputs, and that the page breaks in the manual survive a real Word or WPS open, because the README states pagination is only fully verified when Word is present.

Frequently asked questions

Can Fokkyp SoftwareCopyright-Skill give me examples of software copyright materials?

Yes, in the sense that the repository ships a worked example under `生成demo/软件著作权申请资料/`, with a `草稿/` folder and a `正式资料/` folder holding `申请表信息.txt`, an operation manual DOCX and front-30 and back-30 code DOCX files. The README also links screenshots of the generation flow in `docs/screenshots/`. It does not provide samples of granted registrations.

Does Fokkyp SoftwareCopyright-Skill write the project code for me?

No. The README states the skill does not generate project code with AI and does not fabricate source content, because the code identification material must come from the applied-for software itself. It selects and extracts from files already in your project.

What do I need installed before Fokkyp SoftwareCopyright-Skill can produce DOCX files?

Python 3.10+ and a globally installed OfficeCLI at the pinned version 1.0.151, plus a coding agent that can load the `software-copyright-materials/` skill directory. The README states the project does not fall back to LibreOffice, Pandoc or a bundled DOCX implementation.

Where does Fokkyp SoftwareCopyright-Skill put the generated files?

By default it writes into the current project directory under `软件著作权申请资料/`, with confirmed output in `软件著作权申请资料/正式资料/`. That folder holds `申请表信息.txt`, the operation manual DOCX and the front-30 and back-30 code DOCX files.

Can I use Fokkyp SoftwareCopyright-Skill without Microsoft Word installed?

Generation, OpenXML validation and OfficeCLI HTML preview still work, according to the README. What you lose is native page-count verification: the README states you must manually check pagination in Word or WPS before submitting if Word is not available.

Official sources

  1. Fokkyp/SoftwareCopyright-Skill on GitHub
  2. Issues
  3. License: MIT
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/fokkyp-softwarecopyright-skill.svg)](https://hysenlabs.com/projects/fokkyp-softwarecopyright-skill)