---
name: product-requirement-analysis
description: Use when converting structured requirement intake and product fact source context into a product requirement analysis for Web admin consoles or mobile apps. Produces analysis.md with problem definition, goals, scenarios, options, recommended solution, MVP/non-goals, risks, PRD writing instructions, and HTML prototype design instructions. Use after intake.md and product-fact-context.md exist; do not use for PRD writing, prototype design, version management, or product fact source maintenance.
---

# Product Requirement Analysis

## Purpose

Use this skill as the stage 2 requirement analysis engine in a Codex product-design workflow.

It turns:

- `intake.md`: clarified requirement input
- `product-fact-context.md`: current-system facts, constraints, impact candidates, and product fact source gaps

Into:

- `analysis.md`: the upstream analysis used by PRD writing, HTML prototype design, Multica review packaging, and later product-fact-source maintenance

This skill analyzes product requirements. It does not write the final PRD, design the HTML prototype, manage versions, retrieve the product fact source, or update the product fact source unless the user explicitly asks for that separate work.

## Required Inputs

Before producing `analysis.md`, require these inputs or explicitly mark missing parts:

- Product type: Web admin console, mobile app, cross-end, B-end, C-end, regulated product, internal tool
- Target users or roles
- Business goal or KPI
- Original request and source
- Known constraints: time, resources, policy, compliance, data, technical dependencies
- Existing materials: screenshots, old PRD, prototype, tickets, customer feedback, interview notes
- Decision deadline or urgency
- `product-fact-context.md` facts and gaps

Processing mode:

- 5 or more input fields present: produce a standard analysis.
- 3-4 input fields present: produce an assumption-based analysis and mark inferred conclusions with `[假设]`.
- Fewer than 3 input fields present: ask concise clarification questions before analysis.

## Workflow

1. Restate the original request in neutral product language.
2. Diagnose the scenario: product type, stage, risk level, affected end, requirement source, and main uncertainty.
3. Read relevant references only as needed:
   - Use [framework-selection.md](references/framework-selection.md) to choose 2-4 analysis frameworks.
   - Use [scenario-branches.md](references/scenario-branches.md) for Web admin console, mobile app, cross-end, regulated, data, permission, state-machine, or Multica feedback cases.
   - Use [analysis-output-contract.md](references/analysis-output-contract.md) before writing `analysis.md`.
   - Use [quality-gates.md](references/quality-gates.md) before finalizing.
4. Apply the selected frameworks. Each framework must produce a concrete conclusion, not just a label.
5. Calibrate every key conclusion against `product-fact-context.md`.
6. Separate facts, assumptions, gaps, and decisions.
7. Converge to a recommended solution, MVP scope, non-goals, risks, and confirmation questions.
8. Produce PRD writing instructions and HTML prototype design instructions.
9. Run the quality gate.

## Product Fact Source Calibration

Treat `product-fact-context.md` as the source of truth for current-system facts.

- Do not invent existing pages, roles, permissions, fields, states, rules, or historical decisions.
- If the user input conflicts with `product-fact-context.md`, record the conflict and ask for confirmation when it affects scope, permissions, data, compliance, or system state.
- If information is missing but analysis can continue, mark the conclusion as `[假设]`.
- If the gap blocks PRD or prototype design, list it as a blocking question.

## Framework Use

Select only the frameworks that help this requirement become buildable. Do not stack frameworks for show.

Common defaults:

- Unclear problem: JTBD + Problem-Solution Fit + 5 Why
- Web admin console or B-end workflow: Service Blueprint + User Story Mapping + RICE/MoSCoW
- Data, rule, or status changes: Event Storming + State/Risk Analysis + User Story Mapping
- Mobile task flow: JTBD + User Journey + MVP Scope + Kano
- Feedback rework: Feedback Classification + 5 Why/Problem Tree + Revision Instructions

High-risk limits:

- For finance, compliance, assets, sensitive data, or strong regulatory scenarios, do not use MVP to justify skipping necessary compliance, audit, permission, or data-accuracy requirements.
- For forced, low-frequency, approval-heavy B-end tasks, do not default to growth or habit frameworks such as AARRR, Hook, or Fogg unless the requirement is explicitly about growth behavior.

## Output Requirements

Write or update `analysis.md` using the contract in [analysis-output-contract.md](references/analysis-output-contract.md).

The analysis must include:

- One-sentence conclusion
- Original request restatement
- Problem definition
- User, business, and system goals
- Current state from `product-fact-context.md`
- Scenarios and user paths
- Solution options
- Recommended solution
- MVP, later scope, and explicit non-goals
- Impact scope
- Risks, constraints, and open questions
- PRD writing instructions
- HTML prototype design instructions
- Decision records
- Analysis gate results

## User Confirmation

Ask the user before finalizing when:

- Two or more solution directions are both plausible.
- The split between Web admin console and mobile app responsibilities is unclear.
- Roles, permissions, data objects, states, or core business rules would change.
- `product-fact-context.md` conflicts with user input.
- A compliance or strong-risk scenario has an unresolved shortcut or exception.
- Multica feedback requires changing the frozen scope or approved direction.

## Done Definition

The analysis is done only when it can directly guide both:

- PRD writing: pages, flows, fields, states, permissions, rules, acceptance standards
- HTML prototype design: pages, key paths, interaction states, role differences, endpoint-specific behavior

If either downstream instruction is vague, continue analysis or ask targeted questions.