/light-software-copyright

name: light-software-copyright
description: >-
  Prepare China software copyright registration material drafts from a real
  software project: application-field worksheet, source-code deposit material,
  user/operation manual, screenshots when needed, consistency checks and local
  formal-output evidence. Use for 软著, 软件著作权, 软件版权登记, source-code page
  extraction, operation manual drafts, version/name consistency, or pre-submit
  review. This off-DAG engineering/IP handoff skill does not provide legal
  advice, does not submit applications, does not guarantee registration, and
  never fabricates source code.

Software copyright materials

Prepare auditable China software copyright material drafts from a real project. The core job is not “write pretty documents”; it is to keep software name, version, source-code material, manual, screenshots, applicant fields and user confirmations consistent enough for the user or professional service provider to review.

Read [`references/software-copyright-resource-map.md`](references/software-copyright-resource-map.md) before current-rule or material-format work. Read [`references/materials-workflow.md`](references/materials-workflow.md) before source-code selection, business-understanding, rights-basis, third-party-code or formal-output work.

Non-negotiable boundaries

1. This skill is not legal advice and never submits applications or claims the material will pass. It prepares local drafts and review evidence only. 2. Code material must come from real project source files. Never invent, rewrite, pad, or AI-generate source code for deposit. 3. Do not expose secrets. Run or request a secret/privacy scan before exporting source-code material; if secrets are present, stop for redaction strategy. 4. Preserve official-rule uncertainty. If the current China Copyright Protection Center workflow, form, fee, page format or exception rule is not verified that day, write `UNKNOWN` or `PLANNED`. 5. Keep every formal material version and software name consistent with the application worksheet. 6. Keep this skill off the research DAG. It emits no `light.findings.v1`, has no stage, no checkpoint gate and no reroute.

Workflow

1. Intake and scope

Capture or mark `UNKNOWN`:

• jurisdiction: default `CN`; do not silently reuse CN rules for US/EU work;
• software full name, abbreviation if any, version, owner/applicant, developer,

completion date, publication status and development mode;

• whether the project is independent, commissioned, cooperative, inherited,

derivative or based on licensed third-party code;

• target output language, local folder for drafts, and whether screenshots are

needed.

Stop for user confirmation before formal documents are generated.

2. Bind to a real source snapshot and deposit plan

Inventory source files from the project the user placed in scope. Record relative path, SHA-256 and why selected. Exclude:

• generated build artifacts, minified bundles, vendored dependencies and lock

files unless the user explicitly says they are the software expression to deposit;

• secrets, tokens, keys, credentials, private data and unrelated third-party

code;

• arbitrary middle snippets chosen only to make the material look longer.

If the project is too small, submit all real source rather than padding.

Run the lightweight planner before extraction:

python scripts/source_deposit_plan.py --root <project-root> --out 软件著作权申请资料/草稿/source-deposit-plan.json --software-name "<软件全称>" --version "<版本号>"
python scripts/source_deposit_plan.py --selftest

Use the plan to confirm candidate files, page mode, selected file count, secret-scan status and the plan SHA. If secret-like content is found, stop for redaction before exporting code material.

3. Confirm application fields and business understanding

Generate a worksheet for the user to verify:

• software name and version;
• owner/applicant and contributor facts;
• development environment and operating environment;
• main functions, technical characteristics and use scenario;
• source program quantity and document material quantity;
• publication status and dates.

The manual must describe how a reviewer/user operates the software. It should not be a generic feature list disconnected from screens, commands or workflows. Record rights basis and third-party/open-source/generated-code review before formal export. Do not assume independent ownership when the project may be commissioned, cooperative, inherited, derivative or license-constrained.

4. Prepare code and document material

For normal China material logic, follow the official first/last rule:

• source program and one documentation material use front/back continuous 30

pages when the whole material is at least 60 pages;

• if the whole material is fewer than 60 pages, include the whole source or

whole document;

• full source pages normally need at least 50 lines, and full document pages at

least 30 lines, unless a documented official exception applies.

Keep extraction manifests and page counts. If exceptional deposit is requested, mark it explicitly and ask the user to verify the current official rule.

5. Generate local drafts, then formal outputs

Use a local folder such as `软件著作权申请资料/`:

• `草稿/`: application worksheet, manual draft, code-selection notes;
• `正式资料/`: final DOCX/TXT/PDF-like outputs only after confirmation;
• manifest/report JSON: file paths, SHA-256, source snapshot, confirmation

basis and rule status.

Screenshots are optional; if not used, record why. If used, bind each screenshot to a real running UI or user-provided image and hash it.

6. Run the machine gate before saying “ready for review”

Create a packet following [`templates/software-copyright-materials.example.json`](templates/software-copyright-materials.example.json), then run:

python scripts/source_deposit_plan.py --selftest
python scripts/materials_gate.py --packet softw