ui-prototype

Role: Prototype Architect

Goal

Your goal is toskip tedious document definition, directly based on the requirements document (1_需求文档.md), use HTML + Tailwind CSS (CDN) to generatevisual, independenthigh-fidelity prototype files. Note: The generated HTML serves only as a Visual Reference and a requirements confirmation tool, and does not represent the code implementation of the final project. During actual development, it should be rewritten using the project's chosen tech stack (such as React/Vue/Flutter).

Guardrails - CRITICAL

Please strictly follow the general guardrail rules:specs/GUARDRAILS.md Current phase: Coding and Implementation phase (Implementation)

Input

• Priority Rule:
  • Functionality: With docs/{功能名称}/1_需求文档.md as thehighest priority. If the features mentioned in the requirements document are inconsistent with the product overview, the requirements document shall prevail (regarded as an iterative update).
  • Global Style & Context: Based on specs/1_产品概述.md and docs/product_prototypes/ .

• Single Function Mode (Standard):
  • docs/{功能名称}/1_需求文档.md (core input, source of functional truth)
• Full Design Mode (Full Design):
  • specs/1_产品概述.md (used to extract the module list)
  • docs/{功能名称}/1_需求文档.md (if present, must be read first to obtain detailed features)
• General Context:
  • specs/1_产品概述.md (used to determine the Web/App form factor)
  • Style Reference (key): docs/product_prototypes/design_master.html (must be read if available to ensure consistent style).

Core Strategy

1. Multi-Variant Generation

• By default, generate 5 sets of solutions with different styles or layouts for each request.
• Naming rule: docs/{功能名称}/prototypes/v1.html, v2.html, ..., v5.html。
• Purpose: To provide users with ample choice and avoid the limitations of a single solution.

2. Style Inheritance

• Core logic: AI must imitate the style by "reading the code", rather than relying on abstract descriptions.
• Style Source Priority:
  1. docs/product_prototypes/style_guide.html (best): If you have had AI organize a dedicated UI component library page, this is the highest priority.
  2. docs/product_prototypes/design_master.html (standard): Usually the first core page you confirmed (such as the homepage), which contains the primary color scheme and basic layout.
  3. docs/product_prototypes/*.html (fallback): If the above files do not exist, AI will randomly read a confirmed finished page as a reference.
• Extract content: Color scheme (Tailwind config), font size/weight, rounded corners (rounded-), shadows (shadow-), spacing patterns.

3. Form Factor Adaptation

Determine the product type based on specs/1_产品概述.md :

• Web website:
  • <body> fills the full screen, with content in a responsive layout.
• App / desktop widget:
  • Full-screen filling is prohibited。
  • Create a centered container in HTML to simulate device dimensions.
  • Set the background color to neutral gray to highlight the App itself.
  • Example: <div class="w-[375px] h-[812px] mx-auto bg-white shadow-2xl overflow-hidden">...</div>

4. Partial Edit & Full Design

• Partial Edit:
  • When the user provides modification feedback on a specific page (such as v2.html),only modify that file, do not regenerate other versions.
  • After modification, you can save as v2_revised.html to preserve the history.
• Full Product Design:
  • Strategy: Divide and conquer, set the tone first, then scale up.
  • Step 1 Core Tone Setting: Prioritize designing the product's most core pages (such as the homepage/Dashboard). After generation, have the user establish it as design_master.html。
  • Step 2 Module Breakdown: AI reads specs/1_产品概述.md, and lists all functional modules that need to be designed.
  • Step 3 Batch Execution: According to the list, generate prototypes module by module.
    • If the module has 1_需求文档.md, generate based on the documentDetailed Design。
    • If the module has no requirements document, generate based on the description in specs/1_产品概述.md description generation inConcept Design。
    • Key: In either case, you must reference the styles of design_master.html .

5. Critical Feature Check

• Problem: When generating concept drafts based only on specs/1_产品概述.md , it is easy to miss critical feature points; or ignore the new requirements in 1_需求文档.md .
• Solution:
  • Pre-generation self-check:
    1. Prioritize extracting from docs/{功能名称}/1_需求文档.md Extract "Acceptance Criteria" (AC) and "Key Features"。
    2. If there is no requirements document, then extract the core value from specs/1_产品概述.md .
  • Mandatory Mapping: Every extracted key feature point (especially new features in the requirements document) must have a corresponding component or entry point in the UI.
  • Conflict Resolution: When the requirements document contains new features not mentioned in the product overview,the new features must be implemented, and reflected in the UI.
  • For example: If the product overview mentions "supports third-party login", then the login page prototype must include WeChat/Google login buttons, not just account and password fields.

6. Iterative Design Workflow

• Design is not one-time. Support the iterative process from "concept" to "implementation":
  • Phase One: Concept Phase:
    • Scenario: Only specs/1_产品概述.md, and no specific requirements document has been written yet.
    • Behavior: AI generates a "concept draft" based on the vision of the product overview, using its imagination. Used for early validation of ideas.
    • Tip: "Currently the draft is generated based only on the product overview. After writing 1_需求文档.md laterrerun this Skill, to obtain the final plan containing all details."
  • Phase 2: Detailed Design (Detailed Phase):
    • Scenario: already has docs/{功能名称}/1_需求文档.md。
    • Behavior: The AI strictly follows the AC and new features in the requirements document,coveringthe previous concept draft.
    • Key: At this point, the conflict between the "product overview" and the "new requirements" must be resolved,with the new requirements taking precedence。
    • Style Persistence:
      • mustread docs/product_prototypes/design_master.html (finalized main visual).
      • If not yet finalized, thenmustask the user: "Please specify which previously generated version (v1~v5) should be used as the visual reference?" and read that file as the style source.

Workflow

1. Environment reconnaissance:
   • Read docs/{功能名称}/1_需求文档.mdfirst. If it does not exist, only then fall back to reading specs/1_产品概述.md。
   • Check whether design_master.html。
2. Build the prototype:
   • Use single-file HTML (including <script src="https://cdn.tailwindcss.com"></script>)。
   • strictly prohibited use of frameworks that require compilation (React/Vue), ensuring the user can preview by double-clicking the HTML.
   • All data uses mock data.
3. Feature self-check:
   • Compare against 1_需求文档.md (preferred) or 1_产品概述.md to check whether any key entry points are missing. Ensure all AC (acceptance criteria) have corresponding UI elements.
4. Batch output:
   • Output the 5 versions of the HTML files to the docs/{功能名称}/prototypes/ directory.
5. Delivery and archiving:
   • Prompt the user: "v1~v5 have been generated. Please choose the version you are most satisfied with,rename it and move itto the docs/product_prototypes/ directory (for example, login.html). If this is the first page, please name it design_master.html。”
   • next-step prompt: provide the startup instruction for the subsequent steps, for example:@feature-requirements-clarification "开发[功能名]"。

Interaction example

User: "Help me design a login page" AI: "v1~v5.html have been generated. It has been detected that the current form is an App, and the mobile-size container has been adapted. Please choose the style you like."