requirements-analysis

Requirements Analysis (Chinese version)

English version: See the corresponding English skill.

When to use

You need to handle requirements analysis related tasks in a real project.
You need a result that can be directly used for execution, review, or follow-up.

Read and follow the main prompt in "Load on demand" (coverage checklist, output structure, quality requirements).
Only supplement project context that truly affects the result: scope, environment, constraints, risks, dependencies, expected deliverables.
When information is incomplete, first provide a usable initial version and explicitly mark assumptions and information gaps.
Default to Markdown; switch only when the user specifies another format.

Prioritize by risk/business impact; do not spread effort evenly.
Write "confirmed facts" and "current assumptions" separately.
Do not fabricate interfaces, fields, environments, or root cause details that the user did not provide.
The result must be actionable: scenarios specific, prioritized, and able to guide the next step.

Before producing output, you must read and follow prompts/requirements-analysis.md(minimum coverage checklist, output structure, quality requirements).
When Excel/CSV/JSON/Word or other formats are needed: read output-formats.md, and output according to the user's format requirements.
When a ready-made template needs to be applied: read the matching template in output-templates/ , and do not invent a conflicting structure.
When the user wants examples or to benchmark against existing assets: read the relevant samples in examples/ .
When deep materials such as framework specifications, troubleshooting, or report schema are needed: only read the files in references/ that are relevant to the current problem; do not read through the entire directory.
When format conversion or auxiliary validation is needed: prefer using the existing scripts in scripts/ rather than rewriting them.
When evaluating/regressing this skill: use evals/, and validate and run with skill-up.
When the user only wants the shortest onboarding path: read quick-start.md。

The main prompt's output structure has been followed
Minimum coverage focus: scope summary, business goals, clear and unclear requirements, missing rules, boundaries and exception conditions, testability gaps, dependencies and impacts, risk priority… (details are subject to the main prompt)
The minimum checklist has been covered, or it is indicated why it was omitted
High-risk items have clear priorities
No details were fabricated that the user did not provide
Assumptions and information gaps have been marked

When both scope and context are unclear, do not pretend it is already complete and usable.
Do not write all items as equally important.
Do not skip assumptions and information gaps.
Do not output large sections of vague theory unrelated to the current toolchain.