---
name: generate-software-copyright-docs
description: "Analyze a local software project, prototype demo, repository, or Codex task and generate three Chinese software-copyright Word documents: the technical-information area of the application form, a source-program document, and an operation manual with screenshots. Use when the user asks for 软著材料、软件著作权三件套、申请表技术字段、源程序文档、操作说明书, or wants the supplied software-copyright templates filled and retitled from a project or demo."
---

# Generate software-copyright documents

Generate exactly three final DOCX files from one reviewed project profile. Keep the bundled templates immutable, restrict application-form edits to the screenshot-defined technical area, and finish with structural validation plus page-by-page render QA.

## Load required guidance

Load the `documents` skill before editing or rendering Word files. Follow its template, dependency-runtime, and render-inspect-iterate requirements. Read:

- `references/profile-schema.md` before drafting or reviewing `profile.json`.
- `references/template-map.md` before generating documents or changing any template behavior.

## Resolve the input

1. Resolve a local project directory as the source-of-truth for code.
2. For a Codex task link, use the Codex thread tools to inspect the task and locate its workspace or handed-off artifact. Do not create another task unless the user explicitly requests it.
3. For a repository URL, obtain a local read-only working copy using the appropriate repository tool or `git`.
4. For a running prototype, inspect the visible user journey and capture representative screenshots. Prefer an available browser or Playwright skill for deterministic screenshots.
5. If the input exposes only rendered screens and no source code, stop before producing the source-program document and request the associated project/export. Do not fabricate source code and present it as the user's project.

Keep all scratch data under a task-specific workspace directory or `mktemp -d`. Never modify the input project merely to produce documentation.

## Capture evidence

Inspect project manifests, README content, source folders, visible routes, and major UI flows. Capture only screens needed to explain the normal user journey, such as login, home/dashboard, primary business workflows, query/results, settings, and error/empty states when material.

Use stable filenames ordered by journey, for example `01-login.png`, `02-dashboard.png`, and `03-create-record.png`. Avoid secrets, personal data, browser chrome, developer overlays, and unrelated windows. Do not claim functions, roles, integrations, default passwords, or business rules that are not visible in code or the prototype.

## Build and review the profile

Resolve the bundled workspace Python runtime and run:

```bash
"$PYTHON_BIN" "$SKILL_DIR/scripts/analyze_project.py" "$PROJECT_DIR" \
  --out "$WORK_DIR/profile.json" \
  --name "软件全称" \
  --version "V1.0" \
  --screenshot-dir "$SCREENSHOT_DIR"
```

Use `--name` only when the user supplied or confirmed the registered name. Otherwise let the analyzer propose a name, then verify it against the project before generation.

Review and edit `profile.json` with `apply_patch`:

- Replace every placeholder using source- or UI-backed facts.
- Reconcile language and line-count evidence with the actual project.
- Keep software name and version identical across the profile.
- Write concise application-form text that fits the template cells.
- Order manual sections by the real user journey and pair each screenshot with accurate steps.
- Preserve uncertainty in the working profile until resolved; do not convert uncertainty into invented facts.

Search for `TODO`, `待确认`, `待命名`, `请填写`, and `XXXXXXXX`. Generation must not proceed while any remain.

## Generate the documents

Run the deterministic generator with the reviewed profile and local project:

```bash
"$PYTHON_BIN" "$SKILL_DIR/scripts/generate_documents.py" \
  --profile "$WORK_DIR/profile.json" \
  --project "$PROJECT_DIR" \
  --outdir "$OUTPUT_DIR"
```

The generator must produce:

1. `<软件全称> 申请表.docx`
2. `<主要语言><软件全称><版本> 源程序.docx`
3. `<软件全称><版本> 操作说明书.docx`

Do not pass `--allow-todo` except for local script testing. Do not convert the manual to legacy `.doc` unless the user explicitly requires that format; retain `.docx` as the verified default.

## Validate and render

Run structural validation:

```bash
"$PYTHON_BIN" "$SKILL_DIR/scripts/validate_documents.py" \
  --profile "$WORK_DIR/profile.json" \
  --outdir "$OUTPUT_DIR"
```

Treat any validation error as a failed generation. In particular, fail if the application form changes a non-technical row, any placeholder remains, the source body is empty, a title/version differs, or a requested screenshot is missing.

Render each final DOCX separately with the canonical `documents` renderer into new QA directories. On macOS, prefix each render command with `FONTCONFIG_FILE="$SKILL_DIR/assets/fontconfig-macos.xml"`; the bundled headless LibreOffice otherwise may not discover system Chinese fonts even when Word will. Inspect every PNG page at 100% zoom. Check:

- application table wrapping, red technical values, and unchanged non-screenshot fields;
- source-code legibility, header title/version, indentation, line wrapping, and absence of empty trailing pages;
- manual cover, headings, screenshot scaling, captions, numbered steps, page breaks, and absence of clipping or excessive blank space.

Revise the profile or generator input and repeat generation, validation, and rendering until all pages pass. Never treat structural validation as a substitute for visual QA.

## Deliver

Return only the three final DOCX files unless the user asks for the profile, screenshots, validation report, or render intermediates. State that the application form was intentionally limited to the screenshot-defined technical-information area. Remind the user to verify the registered software name, version, source-line count, and technical descriptions before formal submission.
