design-exploration

The user has a vague idea and wants to build a new feature or new module, but has not yet thought through exactly what they want. Through a structured exploration process, help the user converge from a vague idea to a clear design proposal, and produce a complete design reference document.

Core Principles

• Don't guess, ask more — Don't produce mockups until the scope is confirmed; ask if there is no design specification; if unsure, let the user choose
• ASCII first — Align the information structure and layout logic first; once the logic is right, then invest in HTML
• Multiple proposals at once — Generate 5-8 proposals in batch for the user to choose a direction, don't try them one by one
• Full states are mandatory — The normal state is only the starting point; abnormal states, edge cases, and interaction feedback must be exhaustively covered
• Decisions must be written down — Every decision confirmed in conversation must be written into the requirement summary, and cannot exist only in the conversation context

Deliverables

Each exploration produces 3 files, archived under the 设计/v{版本号}-{模块名}/ directory:

File	Content	Purpose
需求总结.md	Background, goals, feature scope, key decisions, technical constraints	Input for the PRD stage, clearly explaining "why do it, what to do"
{模块名}-设计稿.html	Main interface HTML mockup	Visual reference for PRD + frontend development
{模块名}-全状态设计参考.html	All page states, Toasts, edge cases, interaction rules table	Frontend development implements directly against it

The version number and module name are decided by the user, and the user must be asked to confirm.

Workflow

Step 1: Requirement Divergence and Convergence

After the user states a vague idea, proactively ask follow-up questions:

• What is the pain point — What problem are you encountering now? Why do you want to do this?
• Core scenario — What is the most typical usage scenario?
• Where is the boundary — What should this version do? What should it not do?

Organize into a structured requirement consensus:

做什么：
- xxx
- xxx

不做什么：
- xxx

载体：独立应用 / 已有应用的新 Tab / 插件 / ...

Prohibited: Starting to produce mockups as soon as the user says one sentence. Requirement boundaries must be aligned first.

Step 2: Technical Research (as needed)

Determine whether research is needed: If the feature involves external data (configuration files, APIs, third-party systems, file formats), technical constraints must be researched first. If it is a pure UI feature with no external dependencies, skip.

Research content:

• Data storage location and format
• Interfaces and limitations of the existing system
• Technical feasibility verification

Research results directly affect the design proposal (for example, discovering that two tools have different configuration formats determines that the interface needs to display a "type" column).

Prohibited: Skipping research and drawing mockups directly, then discovering after drawing that it cannot be implemented technically.

Step 3: Batch ASCII Exploration

Generate 5-8Different ASCII layout approaches, each including:

• ASCII layout diagram
• One sentence explaining the core idea

方案 A：卡片列表 + 工具勾选
┌──────────────────────────────────┐
│ ┌────────────────────────────┐   │
│ │ pencil       [✓] CC [✓] CX│   │
│ └────────────────────────────┘   │
└──────────────────────────────────┘

方案 B：表格视图，一行一个
┌──────────────────────────────────┐
│ 名称       类型   CC    CX      │
│ pencil     stdio  [✓]   [✓]    │
│ github     http   [✓]   [✓]    │
└──────────────────────────────────┘

The user can:

• Directly choose one approach
• Combine elements from multiple approaches ("B's structure + E's toggle style")
• Reject all and add new directions

Prohibited：

• Only provide 1-2 approaches (the user has no room to choose)
• More than 10 approaches (difficulty choosing)
• Too little difference between approaches (same thing in a different guise)

Step 4: Confirm the design style

Ask the user the following questions:

1. Is there an existing design specification?(e.g. design-system.html)

   • Yes → read and strictly follow the design tokens (colors, font sizes, border radius, spacing)
   • No → ask about style preferences, or directly produce mockups for the user to pick the feel

2. Are there existing pages to reference?(outer frame, navigation structure)

   • Yes → read the reference pages and align the outer frame style (e.g. mac-window, sidebar layout)
   • No → treat it as a standalone page

3. Delivery format?

   • New page/Tab of an existing app → must align with the outer frame and navigation of existing pages
   • Standalone app → custom outer frame
   • Other → ask for clarification

Prohibited: defaulting to a certain design specification without asking.

Step 5: HTML design mockup

Based on the selected approach + the confirmed design style, output an HTML mockup:

• Fill with real data (do not use lorem ipsum)
• If there is a design specification, strictly use CSS variables / design tokens
• If there are reference pages, keep the outer frame structure consistent

After outputting, have the user open it in a browser to view it, and fine-tune based on feedback. Fine-tuning means specific small changes (spacing, color scheme, copy); execute them directly without going through approach selection again.

Step 6: Full state coverage

Produce a complete full-state design reference HTML, always including the following:

Page states that must be covered

State	Description
Normal state	Standard display with data
Loading state	Data loading (spinner + disabled interaction)
Empty state	No data, guidance copy
Search/filter no results	There is data but no match for the current conditions
Error state	Data loading failure, file not found, format error, etc. (split into multiple by scenario)
Partially available	Some data sources available, some failed

Interaction feedback that must be covered

• Toast summary: success/failure/warning Toasts for all operations, including specific copy
• Toast rules: position, duration (short for success, long for errors), maximum number displayed at the same time

Edge cases that must be covered

• Long text truncation (names, paths, URLs)
• Scrolling through large amounts of data
• Add others according to the specific scenario

Table of interaction behavior rules that must be included

Table format, column definitions:

Trigger	User action	System behavior	Feedback
User/System/Exception	Specific action	Detailed system processing steps	Toast/status change/UI update

A complete mapping covering all user actions and system behaviors, for frontend development to implement directly by reference.

Document structure

• Top: title, version, date
• Table of contents: anchor jumps
• One section per state: label + title + description + preview screenshot + annotations
• Bottom: interaction behavior rules table

Forbidden: stopping after only the normal state. Full state coverage is the core deliverable of this process.

Step 7: Requirements summary + archiving

Generate the requirements summary document according to the template (templates/需求总结-模板.md).

Extract all decisions confirmed in the conversation and write them into the "Key Decisions" section. These decisions are often scattered throughout the conversation and must be actively collected and organized without omission.

Archive the three files to the 设计/v{版本号}-{模块名}/ directory. Confirm the version number and module name with the user.

设计/v0.11-MCP管理/
├── 需求总结.md
├── mcp-manager-设计稿.html
└── mcp-manager-全状态设计参考.html

Communication standards during the process

What must be asked of the user

Timing	What to ask
Step 1	Pain points, scenarios, boundaries (what to do/not to do)
Step 3	Which option to choose
Step 4	Whether there are design specifications, reference pages, carrier format
Step 5	Whether the mockup effect is satisfactory, and whether any fine-tuning is needed
Step 6	Whether there are any omitted scenarios in the full state coverage
Step 7	Version number and module name

What does not need to be asked of the user

Item	Do directly
Whether full state coverage is needed	Must be covered, no need to ask
Whether the interaction rules table needs to be written	Must be written, no need to ask
Whether the requirements summary needs to be output	Must be output, no need to ask
Toast copy	Give suggestions first, adjust if the user is not satisfied

What AI should never do

• Start producing HTML as soon as the user says a vague idea
• Only provide one ASCII option
• Only handle the normal state and ignore the exception states
• Skip technical research and draw directly (if external data is involved)
• Leave decisions in the conversation without writing them into the requirements summary
• Make up the version number and module name on its own
• Use some design specification by default without asking