Software Copyright Application Materials Generation

This skill generates reviewable and traceable software copyright application materials. Core principles:

Fixed output directory:
```
软件著作权申请资料/
```
under the current working directory. Do not write to
```
/tmp
```
,
```
/private/tmp
```
or other temporary directories by default.
Explicitly specifying a temporary directory is only allowed when testing the skill itself; when generating materials for users, they must be written to the current directory.
Generate Markdown drafts first, then produce official Word/TXT documents after user confirmation.
Official Word/TXT documents must only be written to
```
软件著作权申请资料/正式资料/
```
, do not scatter them in the root of the output directory.
All text in official Word/TXT documents must use the default black font; do not generate blue hyperlinks, theme-colored headings or other colored text; Markdown links must be converted to plain text when written to Word.
The software name in official materials must match the "Full Software Name" field in
```
草稿/申请表信息.md
```
; the confirmed full software name from the application form shall prevail during official generation.
The version number in the header of the official code Word document must match the "Version Number" field in
```
草稿/申请表信息.md
```
; the confirmed version number from the application form shall prevail during official generation.
Code materials must come from real project source code; AI-generated code is prohibited.
Before writing the application form and operation manual, a model-judged
```
草稿/业务理解.md/json
```
must be created first to understand the software's business, industry, target users, core value and operation process.
Scripts can only collect project evidence, verify fields and generate files; industry judgment, function extraction, code extraction selection, and operation manual structure must be determined by the model after reading the project, and must not rely on script keyword lists or fixed templates.
Prioritize extracting front-end code: entry points, routes, pages, core components, interface encapsulation, state management, utility functions.
Before generating code materials, a candidate list of code files must be generated first; after understanding the project, the model fills in the extracted files, line segments and selection reasons, then lets the user confirm or modify.
Code extraction prioritizes source code confirmed by the model and user that best reflects the software's real functions and operation logic; if it is less than 60 pages, supplement from other relevant source code files to reach 60 pages; if candidate source code is still insufficient for 60 pages, generate all code documents.
The operation manual is for reviewers, explaining the software's purpose and operation process in general language.
The operation manual draft must be written as coherent paragraphs by chapters, not just a list of functions; each core module must explain the module's purpose, operation process and result feedback in language that ordinary people can understand. Avoid technical expressions such as code, frameworks, interfaces, state management, asynchronous tasks; during writing, the agent shall self-circulate to check, expand and revise, and only initiate one overall confirmation to the user after the complete draft is finished.
The operation manual must remove obvious "AI-style" content: avoid empty praises, marketing slogans, universal sentence patterns, identical structure in each chapter, overly symmetrical parallelism, correct nonsense without project details, and frequent use of clichés such as "aims to, empowers, one-stop, intelligent, efficient and convenient, significantly improves, powerful capabilities, rich functions". Each paragraph should answer "what this function specifically does in this project, what the user sees, what results after operation".
When generating the operation manual,
```
草稿/操作手册自检记录.md
```
and
```
草稿/操作手册自检记录.json
```
must be output synchronously, recording self-inspection rounds such as initial draft, expansion according to project process, removal of formalized expressions, etc.; if problems are still found in the first 3 rounds, continue to supplement and revise until problems are cleared or the reason for automatic repair failure is recorded before stopping.
Screenshot method must first be selected by the user: Chrome DevTools MCP, Codex Computer Use, user-provided screenshots. After the user selects, check whether the current MCP / Computer Use capability is available; if the user says not to take screenshots now, skip screenshots first or screenshot fails, the operation manual must still retain clearly visible screenshot reserved positions, which must also be visible in the official Word document.
The hardware/system environment in the application form information must be confirmed or filled in by the user, and cannot be hard-coded.
Word generation capability must use the built-in
```
vendor/docx-toolkit
```
of this skill; external DOCX directories must not be referenced.

Mandatory User Confirmation Gates

At any stage involving user selection, confirmation or supplementary information, the current execution must be stopped immediately, and the next script must not be called. Even in automatic review, automatic continuation or unattended mode,

STOP_FOR_USER

and

NEXT_ACTION

must be informed to the user as they are, and wait for user input before continuing.

Prohibit the logic of "default to continue if user does not select". After the user replies with confirmation, first use the confirmation script to record the corresponding gate, then enter the next stage:

bash

python3 scripts/confirm_stage.py --workdir 软件著作权申请资料 --stage <阶段名> --note "<用户确认内容>"

Gates that must stop:

```
environment
```
: When the complete DOCX environment is missing, the user must choose "Install complete environment" or "Continue with basic DOCX fallback".
```
project
```
: When there are multiple candidate project directories, the user must specify the project directory.
```
business
```
: After
```
草稿/业务理解.md
```
is generated, the user must confirm the industry, target users, core functions and application caliber.
```
application-fields
```
: After
```
草稿/申请表信息.md
```
is generated, the user must complete and confirm fields such as hardware, system environment, copyright holder, date, etc.
```
code-selection
```
: After
```
草稿/代码文件选择.json
```
is generated, the user must confirm or modify the extracted files and line segments.
```
screenshot-method
```
: Before taking screenshots for the operation manual, the user must choose one of the three methods: Chrome DevTools MCP, Codex Computer Use, user-provided screenshots; if the user clearly says "don't take screenshots now/skip screenshots first", record it as
```
skip
```
.
```
markdown
```
: After all Markdown drafts are completed, the user must confirm that they can proceed to Word/TXT generation.

Workflow

1. Initiate Environment Check

First, create the output directory in the current working directory and check the running capabilities:

bash

python3 scripts/check_environment.py \
  --out-dir 软件著作权申请资料

Output:

软件著作权申请资料/环境检查.md

软件著作权申请资料/环境检查.json

The environment check must inform the user:

Materials will be generated under "Current Directory/软件著作权申请资料".
Whether Markdown drafts, TXT, and basic DOCX are available.
Whether the complete OpenXML environment of the built-in
```
vendor/docx-toolkit
```
is available.
If
```
.NET SDK
```
is missing, ask the user whether to install the complete environment.

User options:

If the user is willing to install the complete environment, install dependencies according to the requirements of
```
vendor/docx-toolkit/scripts/setup.sh
```
, then continue. The complete environment generates and verifies more standardized materials.
If the user does not install, continue to use the fallback solution to generate Markdown, TXT and basic DOCX.
If the complete DOCX environment is missing, must stop and wait for user selection; cannot continue automatically.

Record the gate after user reply:

bash

python3 scripts/confirm_stage.py \
  --workdir 软件著作权申请资料 \
  --stage environment \
  --note "<用户选择>"

Do not wait until the final verification stage to find that the complete DOCX environment is unavailable; this information must be provided at the beginning of the process.

2. Locate Project

Users usually place projects in the current folder. First scan the current directory, avoid this skill, its own output directory,

node_modules

, build artifacts and hidden directories, find the most likely project root directory.

If there are multiple candidate projects, must stop and ask the user to select; if there is only one obvious candidate project, it can be used directly.

3. Analyze Project

Run:

bash

python3 scripts/analyze_project.py \
  --project <项目目录> \
  --out 软件著作权申请资料/analysis/project.json

Analysis content includes:

```
package.json
```
, README, script commands, dependencies
Front-end framework and main programming languages
Entry files, routes, pages, components, interfaces, state management
Number of source code files and lines of source program
Candidate software names, candidate main functions, candidate running commands

4. Form Business Understanding

Before writing the application form and operation manual, first let the script collect project evidence:

bash

python3 scripts/generate_business_context.py \
  --project <项目目录> \
  --analysis 软件著作权申请资料/analysis/project.json \
  --software-name "<软件全称>" \
  --out-dir 软件著作权申请资料/草稿

Output:

```
草稿/业务理解证据.md
```
```
草稿/业务理解证据.json
```
```
草稿/业务理解模型稿模板.json
```

This step only collects evidence, does not determine the final business caliber. Next, the model must read

业务理解证据.md/json

, README, PRD/BRD, page copy, routes, interfaces, necessary source code and user supplementary materials, and independently judge:

Which documents and source code should be focused on reading
Which industry/field the software belongs to
Who the target users are
What the core value is
Which functions should be included in the software copyright application materials
How to organize typical operation processes
Which chapter structure is suitable for the operation manual
How to express the suggested caliber of the application form

The model must not use script keyword lists to determine industry, functions and structure; must not write user-provided template copy, test project names, test project processes as general rules.

After the model completes the judgment, generate a business understanding model draft JSON, which must include at least the following fields:

```
product_positioning
```
```
industry
```
```
target_users
```
```
core_value
```
```
business_features
```
```
business_feature_details
```
```
operation_flow
```
```
application_purpose
```
```
main_functions
```
```
technical_characteristics
```
```
manual_sections
```

Then run:

bash

python3 scripts/generate_business_context.py \
  --project <项目目录> \
  --analysis 软件著作权申请资料/analysis/project.json \
  --software-name "<软件全称>" \
  --out-dir 软件著作权申请资料/草稿 \
  --model-context <模型生成的业务理解JSON>

Output:

```
草稿/业务理解.md
```
```
草稿/业务理解.json
```

The final business understanding must cover:

Product positioning
Target industry/field
Target users
Core value
Main business functions
Typical operation processes
Suggested application form caliber
Evidence sources
Suggested operation manual structure

If project materials are insufficient, business type is new, or the user clearly wants to refer to competitors, search for similar products and industry materials online; external research is only used to understand industry expressions, and cannot fabricate functions that do not exist in the project. The research summary should be written into the business understanding draft, and distinguish between "project evidence" and "industry reference".

After generating

业务理解.md/json

, must stop and wait for user confirmation or modification. Before the business understanding is confirmed, the application form and operation manual cannot be generated. If the business understanding is still insufficient, ask the user to supplement product description first. After user confirmation, run:

bash

python3 scripts/confirm_stage.py \
  --workdir 软件著作权申请资料 \
  --stage business \
  --note "<用户确认内容>"

5. Guide User to Confirm Fields

Based on the analysis results, confirm with the user:

Full software name
Version number
Copyright holder
Development completion date
First publication date or unpublished
Development hardware environment
Running hardware environment
Development operating system
Running platform/operating system
Development tools (IDE or editor name)
Running support environment/supporting software (Node.js, Python, Docker, database, browser, middleware or external services required for project operation)
Software classification
Software technical characteristics options

Inferable fields of the project can be given suggested values first; hardware/system environment must allow users to choose suggested values or fill in manually. The field caliber must be clearly distinguished:

Full software name: Must be confirmed by the user. The final official material file name, code Word header, operation manual title and software name in the text must all match the "Full Software Name" field in
```
申请表信息.md
```
.
Version number: Must be confirmed by the user. Prioritize reading the version number in the project configuration as evidence; if the project version number is less than V1.0 (e.g., V0.1.0, V0.9.0), explicitly ask the user "Software copyright first submission usually uses V1.0, shall we fill in V1.0 or the current project version number this time?" The "Version Number" field in the final
```
申请表信息.md
```
is the version number of official materials.
Software development environment / development tools: Fill in the IDE or editor name, such as Visual Studio Code, WebStorm, IntelliJ IDEA, Cursor; do not write technical stacks such as React, Next.js, Vite, TypeScript into this field.
Operating system for software development: Fill in the operating system version of the actual development computer, such as Windows 10, Windows 11, macOS 14, macOS 15.
Software running platform / operating system: Fill in the operating system version where the software runs, such as Windows 10/11 or macOS 13 and above.
Software running support environment/supporting software: Fill in the software environment required for project operation, such as Node.js, Python, Docker, PostgreSQL, Redis, browser, middleware, external models or cloud services.
Development hardware environment: Prioritize reading the current computer's CPU, memory, hard disk, architecture and other configurations as suggested values; let the user fill in if it cannot be read.
Running hardware environment: The suggested value of the development hardware environment can be used by default, or modified according to the actual deployment or running device.

At this stage, must stop and wait for user input; after receiving the user's reply, organize it into

answers

JSON and pass it into the application form draft generation. The final gate for application form fields is recorded after

草稿/申请表信息.md

is generated.

6. Confirm Code File Selection

Before generating code materials, first run candidate file analysis:

bash

python3 scripts/propose_code_selection.py \
  --project <项目目录> \
  --analysis 软件著作权申请资料/analysis/project.json \
  --out-dir 软件著作权申请资料/草稿

Output:

```
草稿/代码文件候选清单.md
```
: Candidate description for users to view.
```
草稿/代码文件选择.json
```
: Editable selection file.

The candidate list generated by the script only lists evidence, does not select files by default. The model must first read the business understanding, candidate files, entry files, page files and necessary source code, judge which source code best reflects the software's real functions and operation logic, then modify

代码文件选择.json

```
selected: true
```
means extract this file.
```
selected: false
```
means do not extract this file.
```
start_line
```
and
```
end_line
```
can be used to extract only specified line segments of a file.
```
model_reason
```
must explain why this file or line segment is selected.

Model selection usually prioritizes front-end entry points, pages, core components, business interactions, data requests, state processing and other code that allows reviewers to understand the software's functions; if relevant front-end code is less than 60 pages, supplement with back-end services, business processing, configuration and other relevant source code. Supplementary files must also be written into

代码文件选择.json

and confirmed by the user. Do not extract the entire code library by default. After the user confirms and records the

code-selection

gate, code extraction only reads the selected files and line segments in

代码文件选择.json

. After user confirmation, run:

bash

python3 scripts/confirm_stage.py \
  --workdir 软件著作权申请资料 \
  --stage code-selection \
  --note "<用户确认内容>"

7. Generate Markdown Drafts

Run code material extraction:

bash

python3 scripts/extract_code_material.py \
  --project <项目目录> \
  --analysis 软件著作权申请资料/analysis/project.json \
  --selection 软件著作权申请资料/草稿/代码文件选择.json \
  --software-name "<软件全称>" \
  --version "<版本号>" \
  --out-dir 软件著作权申请资料/草稿

Code pagination rules:

Default 60 lines per page, use compact fixed line spacing in Word, try to fill the page before turning to the next page.

Total pages

>= 60

: Generate

代码-前30页.md

and

代码-后30页.md

Total pages
```
< 60
```
and candidate source code is exhausted: Only generate
```
代码-全部.md
```
.
Total pages
```
< 60
```
but there are still supplementary source code in the candidate list: Stop and require the user to continue selecting supplementary files in
```
代码文件选择.json
```
.
Do not generate oversized "full backup Word" for large projects.
Generate
```
代码提取清单.md
```
and
```
代码提取清单.json
```
at the same time for tracing code sources.

Generate application form information draft:

bash

python3 scripts/generate_application_info.py \
  --analysis 软件著作权申请资料/analysis/project.json \
  --code-manifest 软件著作权申请资料/草稿/代码提取清单.json \
  --business-context 软件著作权申请资料/草稿/业务理解.json \
  --software-name "<软件全称>" \
  --version "<版本号>" \
  --out-dir 软件著作权申请资料/草稿

After generation, must stop and let the user check and complete

草稿/申请表信息.md

. After fields are completed and confirmed, run:

bash

python3 scripts/confirm_stage.py \
  --workdir 软件著作权申请资料 \
  --stage application-fields \
  --note "<用户确认内容>"

Generate operation manual draft:

bash

python3 scripts/generate_manual_draft.py \
  --analysis 软件著作权申请资料/analysis/project.json \
  --business-context 软件著作权申请资料/草稿/业务理解.json \
  --software-name "<软件全称>" \
  --version "<版本号>" \
  --out-dir 软件著作权申请资料/草稿

The operation manual draft must not force the use of user-provided template copy or fixed chapters. It should first organize a manual structure suitable for the project based on

manual_sections

草稿/业务理解.json

written by the model and project page entry points; it usually needs to cover software overview, applicable objects, operating environment, accessing the software, main functions, operation processes and precautions, but chapter titles and order can be adjusted according to the actual project. Each chapter should contain paragraph descriptions, functional modules cannot only list titles and steps, must clearly write the module's purpose, user operations and system feedback. The language should be oriented to reviewers and ordinary readers, explaining "what this module does, how the user operates it, what the user sees after operation", do not write technical details such as code implementation, framework names, interface encapsulation, state management, asynchronous queues. During writing, the agent shall self-check whether chapters are complete, content is too thin, language is too technical, and complete necessary supplements in the draft; only let the user do one overall confirmation after the complete draft is finished, and cannot proceed to official Word/TXT generation before confirmation.

The generation script must also write

草稿/操作手册自检记录.md

and

草稿/操作手册自检记录.json

. The self-inspection record must include at least:

Round 1: Initial draft generation, check chapter completeness, screenshot reservations, module content thickness and technical expressions.
Round 2: Expand module descriptions according to the real operation process of the project, supplement upstream and downstream connection relationships.
Round 3: Remove formalized expressions and AI-style content, focus on checking repeated sentence patterns, unified clichés, empty praises, marketing slogans, overly neat parallelism and correct nonsense without project details.
Subsequent rounds: If there are still problems, continue to supplement, deduplicate, rewrite, cannot directly hand over uncorrected problems to the user.

The module writing of the operation manual must start from the industry, target users, core value, business functions and typical operation processes in

草稿/业务理解.json

. Different modules should write their respective business roles, cannot uniformly apply the fixed sentence pattern of "enter page, fill in content, submit button, view results"; similar modules should also distinguish their respective operation purposes and results combined with the real business of the project, and cannot write function names, business processes or example copy of test projects as general rules.

8. Select and Obtain Screenshots

After the operation manual draft is completed, first stop and let the user select the screenshot method, must provide three options:

Chrome DevTools MCP: Suitable for Web projects already opened in the browser, preferred for full-page web screenshots.
Codex Computer Use: Suitable for scenarios that require clicking, switching, viewing status in desktop applications or browser interfaces before taking screenshots.
User-provided screenshots: Users put PNG/JPG/JPEG/WebP images into
```
软件著作权申请资料/用户截图/
```
, and the agent only responsible for organizing and referencing.

If the user clearly says "don't take screenshots now", "skip screenshots first", "don't take screenshots this time", must also record the screenshot method gate, fill in

skip

for the method. Skipping screenshots does not block the generation of official materials, but each core function module in the operation manual must retain visible screenshot reservation text, such as:

【截图预留：请在此处插入“项目管理”页面或操作结果截图。】

. Do not use HTML comments as screenshot placeholders, because they cannot be seen in the official Word document.

After user selection, first record the gate:

bash

python3 scripts/confirm_stage.py \
  --workdir 软件著作权申请资料 \
  --stage screenshot-method \
  --method <chrome-devtools|computer-use|user-supplied|skip> \
  --note "<用户选择>"

Then check the current capability and execute according to the user's selection:

Select Chrome DevTools MCP: First use tool discovery capability to check whether the current environment has
```
list_pages
```
,
```
take_snapshot
```
,
```
take_screenshot
```
of
```
mcp__chrome_devtools__
```
. When available, first
```
list_pages
```
to confirm the current browser page, then take screenshots according to pages/routes and save to
```
软件著作权申请资料/截图/
```
; when unavailable, stop and inform the user to reselect the screenshot method or provide screenshots manually.
Select Codex Computer Use: First use tool discovery capability to check whether the current environment has
```
get_app_state
```
,
```
click
```
,
```
press_key
```
of
```
mcp__computer_use__
```
. When available, first
```
get_app_state
```
to view the current state of the target application or browser, then navigate and take screenshots according to the operation manual needs; if the current Computer Use can only return in-session screenshots but cannot directly save image files, explain the limitation and let the user switch to Chrome DevTools MCP or put screenshots into
```
用户截图/
```
.
Select user-provided screenshots: Create
```
软件著作权申请资料/用户截图/
```
, prompt the user to put screenshot files into this directory; after the user puts them in, run the following organization command to copy the images to
```
软件著作权申请资料/截图/
```
and generate
```
截图清单.json
```
.
Select skip screenshots: Do not run screenshot tools, continue to retain visible screenshot reservation text in the operation manual; explain in the generation report that the user chose to skip screenshots temporarily, and the official operation manual has reserved screenshot positions.

bash

python3 scripts/capture_screenshots.py \
  --manual-dir 软件著作权申请资料/用户截图 \
  --out-dir 软件著作权申请资料/截图

After successful screenshots, add screenshot references to

草稿/操作手册.md

; if screenshots fail or the user chooses not to provide screenshots temporarily, continue to generate the text version with screenshot reservation positions, and explain in the report that "operation manual screenshots are not generated or inserted, and screenshot reservation positions have been retained".

9. User Confirm Markdown

Before generating Word, must let the user confirm the Markdown files under

软件著作权申请资料/草稿/

Key checks:

Whether the software name and version number are consistent
Whether the software name in the header of the first 30 pages and last 30 pages of code materials matches the "Full Software Name" in
```
申请表信息.md
```
Whether the version number in the header of the first 30 pages and last 30 pages of code materials matches the "Version Number" in
```
申请表信息.md
```
Whether
```
业务理解.md
```
accurately reflects the software's real business, industry and target users
Whether the fields "to be confirmed by user" in
```
申请表信息.md
```
have been confirmed
Whether code materials only come from files/line segments confirmed by the user
Whether the operation manual is suitable for the reviewer reading scenario, whether ordinary readers can understand the module purpose and operation method
Whether each chapter of the operation manual has paragraph content, whether core modules clearly write the module purpose, operation process and result feedback, whether overly technical language is avoided
Whether screenshots are correct; if the user skips screenshots, whether the official operation manual retains visible screenshot reservation positions

After user confirmation, must record the

markdown

gate; official Word/TXT cannot be generated without recording.

bash

python3 scripts/confirm_stage.py \
  --workdir 软件著作权申请资料 \
  --stage markdown \
  --note "<用户确认内容>"

10. Generate Official Word/TXT

After user confirmation, run:

bash

python3 scripts/build_docx_from_md.py \
  --workdir 软件著作权申请资料 \
  --software-name "<软件全称>" \
  --version "<版本号>"

The official generation script must re-read the confirmed "Full Software Name" and "Version Number" in

草稿/申请表信息.md

, and use them to generate official material file names, code Word headers and operation manual Word. If the command parameters

--software-name

--version

are different from the application form fields, the application form fields shall prevail, and a prompt shall be recorded in

正式资料/生成报告.md

Output:

```
正式资料/申请表信息.txt
```

If code reaches or exceeds 60 pages:

正式资料/<软件全称>-代码(前30页).docx

正式资料/<软件全称>-代码(后30页).docx

If code is less than 60 pages:

正式资料/<软件全称>-代码(全部).docx

正式资料/<软件全称>_操作手册.docx

```
正式资料/生成报告.md
```

11. Three Rounds of Verification

Execute at least three rounds of verification and fix found problems:

File integrity: Whether the target Word/TXT exists and is non-empty.
Code authenticity: Sampling check that code fragments can be traced back to project source code.
Business authenticity: The industry, target users, main functions and operation processes in the application form and operation manual can be traced back to
```
业务理解.md
```
and project documents.
Consistency and format: Whether the software name, version number, pagination rules, application form fields, operation manual title and screenshot references are consistent.

Available commands:

bash

python3 -m py_compile scripts/*.py
bash vendor/docx-toolkit/scripts/docx_preview.sh <生成的docx>

Complete DOCX environment check and installation must directly restore/build

vendor/docx-toolkit/scripts/dotnet/DocxToolkit.Cli/DocxToolkit.Cli.csproj

, do not perform implicit restore/build on the

vendor/docx-toolkit/scripts/dotnet

directory or

.slnx

files.

环境检查.md

vendor/docx-toolkit/scripts/env_check.sh

shows that

.NET SDK

is missing, it means the complete DOCX OpenXML verification environment is not ready. After the user clearly chooses not to install and records the

environment

gate, continue to generate Markdown, TXT and basic DOCX, and explain in the report that the current fallback path is used.

When to Ask the User

Must ask and stop in the following scenarios, wait for user input before continuing:

Multiple candidate project directories need to be selected.
When the initial environment check finds that the complete DOCX environment is missing, ask the user whether to install the complete environment.
After the business understanding draft is generated, ask the user to confirm the software purpose, industry, target users, core functions and application caliber.
Registration fields such as full software name, copyright holder, date, hardware/system environment need to be confirmed.
After the code file candidate list is generated, the user needs to confirm or modify
```
代码文件选择.json
```
.
Before taking screenshots for the operation manual, the user needs to choose one of the three methods: Chrome DevTools MCP, Codex Computer Use, user-provided screenshots; check whether the corresponding tool is available after selection.
Whether the user confirms the Markdown draft and proceeds to Word generation.

software-copyright-materials

NPX Install

Tags

SKILL.md Content (Chinese)

Software Copyright Application Materials Generation

Mandatory User Confirmation Gates

Workflow

1. Initiate Environment Check

2. Locate Project

3. Analyze Project

4. Form Business Understanding

5. Guide User to Confirm Fields

6. Confirm Code File Selection

7. Generate Markdown Drafts

8. Select and Obtain Screenshots

9. User Confirm Markdown

10. Generate Official Word/TXT

11. Three Rounds of Verification

When to Ask the User