requirements-analysis

Requirements Analysis

When to Use

• When the user describes a product idea, provides prototype documents or a requirements draft, and it needs to be organized into executable requirements.
• Phase 1 of the full-stack workflow, invoked by the orchestrator.

Communicate with the user (required)

This phase is executed in themain conversation, and requires multiple rounds of dialogue with the user; requirements must not be fabricated.

Interaction Principles

• For ambiguous points,mustbe completed with 1–3 rounds of questions,wait for the user's reply before writing to the document。
• All decision points should be presented as structured options, letting the user choose rather than free-form input. For example, provide the user with numbered options ("Please choose 1/2/3"); when multiple selections are allowed, state "multiple selections allowed".
• Allow the user to add explanations beyond the options (e.g., adding a description after selecting "Other").
• Do not ask more than 3 questions at a time to avoid overloading the user with information.

Execution Points

1. Prototype/Document Recognition: If the user provides product prototype screenshots, a PRD document, or a draft, first extract the feature descriptions and page flows from them.
2. Feature Point Breakdown: Extract a list by "functional module → feature point", without omissions or fabrication. Each feature point includes a brief description and inputs/outputs.
3. User Stories: Convert core feature points into user story format (As a ... I want ... So that ...).
4. Acceptance Criteria: Attach 1–3 acceptance criteria to each feature point (Given/When/Then or bullet-point style).
5. Follow-up on Details: For ambiguous points (roles, boundaries, data sources, exceptional cases), complete them with 1–3 rounds of brief questions,wait for the user's reply before writing。
6. Output Format: Use templates/requirements-template.md to fill in and produce the requirements document.

Structured Questioning Guidance

Each group below is one round of questioning. In each round, presentstructured optionsto the user, and proceed to the next round after the user makes a selection.

Round 1: Basic Information

Confirm the following with the user (can be combined into one set of options):

Q1 — Are there prototype images or design mockups?

• A. Yes (prototype images/design mockups/Figma links, etc.)
• B. There are reference websites or competitors
• C. Neither, starting from scratch

Q2 — Which ends does the project involve?

• A. Frontend + Backend (full stack)
• B. Frontend only
• C. Backend only

Q3 — User roles?(multiple selections allowed)

• A. Single role only (no permission distinction)
• B. Regular user + Administrator
• C. Multiple roles (3 or more), please briefly explain

Round 2: Frontend UI/UX Preferences (required when C is selected for Q1)

If the user has no prototype images/design mockups, present the following options to the user:

Q4 — Overall style?

• A. Modern minimalist (reference Linear / Notion)
• B. Formal business (reference enterprise admin panel)
• C. Tech-inspired / dashboard style
• D. Other (please specify or provide a reference website)

Q5 — Primary color scheme?

• A. Blue tones
• B. Green tones
• C. Purple tones
• D. Dark tones (dark background)
• E. Other (please specify color values or preferences)

Q6 — Layout style?

• A. Sidebar navigation (left menu + right content)
• B. Top navigation bar
• C. No navigation (single page/landing page)
• D. Other

Q7 — Responsive requirements?

• A. Desktop only
• B. Desktop + tablet
• C. Full-platform adaptation (desktop + tablet + mobile)
• D. Mobile-first

Q8 — Is dark mode needed?

• A. Yes
• B. No
• C. Discuss later

Round 3: Backend architecture preferences (required when the project involves a backend and it is not yet specified)

Q9 — API style?

• A. RESTful
• B. GraphQL
• C. No preference, you recommend

Q10 — Authentication method?

• A. JWT (stateless)
• B. Session (stateful)
• C. OAuth2 third-party login
• D. Authentication not needed for now

Q11 — Database preference?

• A. MySQL
• B. PostgreSQL
• C. MongoDB
• D. SQLite (lightweight/embedded)
• E. No preference

Q12 — Is automatic API documentation generation (Swagger/OpenAPI) needed?

• A. Yes
• B. No
• C. Discuss later

Round 4: Supplementary confirmation

Based on the user's previous answers, ask targeted follow-up questions about business processes, exception branches, and non-functional requirements that are still unclear. Open-ended questions may be used in this round.

Supporting materials

• Complete example output:examples/sample-output.md — Show the complete structure and content depth of a qualified requirements document
• Writing reference:reference.md — User story INVEST principles, how to write acceptance criteria, common follow-up question checklist

Deliverable

• A requirements document filled in according to the template, for use in "technology selection" and subsequent stages.

Document and status

• Write the deliverable to docs/{current_iteration_id}/requirements-{requirements_id}.md。
• Before starting: call the history-manager skill's get-phase requirements and check-file to confirm whether it has been completed.
• After completion: call the history-manager skill's set-phase requirements {requirements_id} to record and advance the status.