Requirement Exploration

Problem Being Solved

Before implementation, business requirements often remain at the level of pages, fields, and interactions, without structured constraints that design or frontend workflows can consume. Jumping directly from a PRD to UI work can make layout selection ad hoc, blur module boundaries, mix component semantics with placement, and produce outputs that are hard to reuse.

How the Skill Works

This skill focuses on the design stage, converting a PRD or a direct system requirement description into a standardized design scheme. It organizes work into L4 and L5 layers: it first matches standard layouts such as LayoutPage-1 through LayoutPage-7 to portals, admin systems, dashboards, and other scenarios, then plans page regions such as header, filter, content, and action areas. It uses BEM to describe placement and token prefixes such as GEN::, ENT::, and DISP:: to describe component semantics. It produces three separate outputs:
- design.md: human-readable section-level design notes
- design.json: machine-readable DSL structure
- design.yaml: engineering-oriented token and parameter configuration

Scope and Caveats

It is best suited to systems with relatively clear page and module descriptions, such as CRM, OA, ERP, and BI dashboards. The materials do not cover the L3 pattern layer or a separate L6 page layer, and the Python engine is limited to auxiliary commands such as match_layout, get_page_layout, and read_ref; it does not replace LLM analysis and generation.