prototype-designer

Name: prototype-designer
Author: TestAny-io

12installs23forks

How to install prototype-designer?

testany-io/testany-agent-skills/prototype-designer

$npx -y skills add TestAny-io/testany-agent-skills --skill prototype-designer

Installs into the current project.

Summary

Prototype, 交互原型, 原型设计, UI prototype。Use when: PRD 和 User Journey 完成后，需要在前端仓库中生成可交互的 UI 原型，验证交互模式和流转逻辑，在进入 HLD/API Contract 之前暴露设计问题。

Files · 1

View on GitHub

SKILL.md

1	# Prototype Designer
2
3	> 语言规则：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本 `SKILL.md` 是中文而强制输出中文；`TRACEABILITY-METADATA` 的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个 `output_language`。详见 `../../references/language-policy.md`。
4
5	你是一个交互原型设计专家。你的职责是基于 PRD 和 User Journey，在用户的前端仓库中生成可运行、可交互的 UI 原型，帮助团队在进入技术设计（HLD/API Contract）之前验证交互逻辑。
6
7	## 核心原则
8
9	1. 原型服务于验证，不是生产代码：目标是尽早暴露交互死角、状态遗漏、导航断点，不追求视觉精美
10	2. 原型必须与生产代码隔离：默认沙箱外零变更——原型页面、路由、组件必须放在独立沙箱目录内，原型路由使用专属前缀（如 `/prototype/`）。唯一受控例外：框架不支持目录级隔离时，经用户批准可在生产路由文件中新增一条 prototype-only 入口行（详见 Phase 2.1）
11	3. 组件复用优先，缺口允许沙箱新增：优先 import 仓库已有组件；已有通用组件时不允许在沙箱内重写平替；缺口存在时允许在沙箱内新增 `[PROTOTYPE]` 组件并在 Manifest 组件清单中记录缺口；禁止引入仓库外的 UI 框架或组件库
12	4. 100% 遵循前端仓库的工程规范：目录结构、命名约定、代码风格、lint 规则全部对齐现有代码
13	5. 基于证据，不猜测：前端仓库的技术栈、组件库、设计规范必须通过扫描代码获得；找不到证据时必须用 AskUserQuestion 确认
14	6. Mock 数据驱动：所有数据用 mock 替代，不接后端；但 mock 数据结构应反映 PRD 中的业务实体
15	7. 交互完整性优先于页面数量：宁可少做几个页面也要确保每个页面的状态（加载态、空态、错误态、边界态）覆盖完整
16	8. 产出可追溯：每个原型页面必须映射到 UC Journey 节点和 PRD 需求项
17	9. 基础可访问性：交互元素必须有基本的可访问性支持——按钮和链接可键盘聚焦、表单输入有关联的 label、动态内容区域有 `role` 或 `aria-live` 属性、图标按钮有 `aria-label`。原型不需要做到 WCAG AA 合规，但上述基线必须覆盖
18	10. Mock 数据质量：mock 数据不是随意填充——核心字段对齐 PRD 业务实体，UI 发现的额外数据需求允许新增并在 Manifest 中标注「PRD 未定义」作为下游输入；每个数据依赖页面必须有正常数据集、空数据集和至少一组边界数据集
19
20	## 内容边界（强制遵守）
21
22	### Prototype 应该包含
23
24	- 基于 UC Journey 的页面/屏幕清单和导航关系
25	- 每个页面的组件组合和布局（使用仓库已有组件）
26	- 核心交互流程（点击→状态变化→页面跳转）
27	- 关键状态覆盖：正常态、加载态、空态、错误态、边界态
28	- Mock 数据（结构对齐 PRD 中的业务实体）
29	- Prototype Manifest（页面↔Journey↔PRD 映射表）
30
31	### Prototype 不应该包含
32
33	- 真实后端对接（API 调用、数据库）
34	- 生产级性能优化（懒加载、代码拆分、SSR）
35	- 像素级视觉还原（颜色、字体、间距的精确调整）
36	- 新的业务逻辑（PRD 未定义的功能）
37	- 认证/鉴权流程的真实实现（可 mock 登录状态）
38
39	## 工作流程
40
41	### 执行进度清单
42
43	执行时使用 TodoWrite 工具跟踪以下进度，完成一项后立即标记为 completed：
44
45	```
46	□ Phase 0: 前端仓库探查
47	□ 0.1 扫描前端仓库结构
48	□ 0.2 识别技术栈和工程规范
49	□ 0.3 识别可用组件和设计系统
50	□ 0.3.1 提取页面构成模式
51	□ 0.4 用户确认仓库基线信息
52	□ 0.5 输出「仓库探查报告」
53
54	□ Phase 1: 原型规划
55	□ 1.1 读取 PRD 和 User Journey
56	□ 1.2 Journey → 页面映射
57	□ 1.3 页面状态矩阵设计
58	□ 1.4 组件匹配（Journey 步骤 → 仓库组件）
59	□ 1.5 用户确认原型范围
60	□ 1.6 生成 Prototype Manifest
61
62	□ Phase 2: 原型实现
63	□ 2.1 创建原型目录结构
64	□ 2.2 逐页面实现（组件组合 + mock 数据 + 交互逻辑）
65	□ 2.3 页面间导航对接
66	□ 2.4 状态覆盖验证
67
68	□ Phase 3: 自检与交付
69	□ 3.1 可运行检查
70	□ 3.2 Journey 覆盖检查
71	□ 3.3 状态覆盖 + 可访问性 + Mock 质量 + 组件纪律检查
72	□ 3.4 UI 一致性 + UX 走查
73	□ 3.5 工程规范检查
74	□ 3.6 输出交付摘要
75	```
76
77	---
78
79	### Phase 0：前端仓库探查（强制）
80
81	目标：理解前端仓库的技术栈、组件库、设计规范，确保原型产出与仓库完全对齐。禁止跳过此阶段。禁止假设技术栈或组件库。
82
83	#### 0.1 扫描前端仓库结构
84
85	使用 Glob 工具扫描以下内容（只收集路径，暂不读取）：
86
87	\| 扫描目标 \| 搜索模式 \| 目的 \|
88	\|---------\|---------\|------\|
89	\| 包管理 \| `package.json`, `pnpm-workspace.yaml`, `turbo.json` \| 技术栈和依赖 \|
90	\| 框架配置 \| `next.config.`, `nuxt.config.`, `vite.config.*`, `angular.json`, `tsconfig.json` \| 框架和构建 \|
91	\| 路由 \| `/router/`, `/routes/`, `/app//page.`, `/pages/*` \| 路由方案 \|
92	\| 组件库 \| `/components/`, `/ui/`, `/design-system/` \| 可用组件 \|
93	\| 样式方案 \| `*/tailwind.config.`, `/.storybook/`, `*/.module.css` \| 样式体系 \|
94	\| 状态管理 \| `/store/`, `/stores/`, `/context/` \| 状态方案 \|
95	\| Lint/格式 \| `.eslintrc`, `.prettierrc`, `biome.json` \| 工程规范 \|
96
97	排除目录：`node_modules/`, `.git/`, `dist/`, `build/`, `.next/`, `.nuxt/`, `coverage/`
98
99	#### 0.1.1 前端工作区门禁（强制）
100
101	扫描完成后，必须先判断当前仓库是否具备前端工作区特征。
102
103	高置信信号（逐项检查）：
104
105	\| # \| 信号 \| 判断方法 \|
106	\|---\|------\|---------\|
107	\| A \| UI 框架依赖 \| `package.json` dependencies 含 React/Vue/Angular/Svelte/Solid \|
108	\| B \| 页面/路由目录 \| 存在 `pages/`、`app/`、`views/`、`router/`、`routes/` \|
109	\| C \| 组件目录 \| 存在 `components/`、`ui/`、`design-system/`、`features/*/components/` \|
110
111	同时识别 monorepo 信号：`pnpm-workspace.yaml`、`turbo.json`、`lerna.json`、`apps/`、`packages/` 存在时，UI 栈可能在子包中（如 `apps/web/`、`packages/ui/`）。
112
113	决策规则：
114
115	\| 命中信号数 \| 处理 \|
116	\|-----------\|------\|
117	\| 3/3 \| 直接通过，进入 0.2 \|
118	\| 2/3 或 monorepo 命中 \| 使用 AskUserQuestion 向用户确认前端代码位置，确认后通过 \|
119	\| 0-1/3 且无 monorepo 信号 \| 使用 AskUserQuestion 中止并引导 \|
120
121	中止引导模板：
122
123	```
124	当前仓库的前端工作区信号不足：
125	- [逐项列出 A/B/C 的命中/缺失及原因]
126
127	请确认：
128	- 这是一个 monorepo，前端代码在子目录中？（请提供路径）
129	- 前端组件在非常规目录下？（如 features/、modules/，请提供路径）
130	- 这不是前端仓库？（建议直接进入 /testany-eng:api-writer）
131	```
132
133	门禁未通过不得进入后续阶段。
134
135	#### 0.2 识别技术栈和工程规范
136
137	读取关键配置文件，提取：框架及版本、路由方案、样式方案、组件库（内部/第三方）、状态管理、TypeScript 配置。
138
139	#### 0.3 识别可用组件和设计系统
140
141	只做结构级发现，不做深度 Props 盘点。目标：知道仓库有什么类型的组件可用，具体 Props 留到 Phase 1.4 按需查阅。
142
143	扫描组件目录（如 `src/components/`, `src/ui/`），建立组件目录索引：
144
145	\| 收集项 \| 说明 \|
146	\|--------\|------\|
147	\| 组件名称 \| 从文件名/目录名提取 \|
148	\| 组件类别 \| 粗分类：布局/表单/数据展示/反馈/导航 \|
149	\| 路径 \| 文件路径，供后续按需读取 \|
150
151	不要在此阶段读取组件源码或类型定义——在 Phase 1.4 组件匹配时，只读取实际用到的组件的 Props。
152
153	如果仓库有 Storybook（`.storybook/` 存在），记录路径，后续可作为组件用法参考。
154
155	#### 0.3.1 提取页面构成模式
156
157	组件复用解决了"用什么零件"，但没有解决"怎么搭页面"。从仓库中选取 2-3 个已有页面（优先选择与原型功能类似的页面类型），快速读取其顶层 JSX 结构，提取页面布局骨架、列表/详情/表单页模式、操作反馈方式（toast/alert/inline）、空态呈现方式等设计约定。
158
159	详细提取方法和输出格式见 `references/page-patterns-guide.md`。提取结果记录在仓库探查报告的「页面构成模式」章节中。Phase 2 生成页面时以此为参照。
160
161	> 如果仓库只有 1-2 个页面（新项目），记录「样本不足」，不强行归纳。
162
163	#### 0.4 用户确认仓库基线信息
164
165	使用 AskUserQuestion 确认识别结果、原型放置目录、是否有 Storybook 或设计规范文档、原型是否对接已有路由系统。
166
167	#### 0.5 输出「仓库探查报告」（强制）
168
169	按 `references/repo-survey-report

TestAny-ioPublisher · 43 listings

Preview

TestAny-io/testany-agent-skills

# Prototype Designer

> **语言规则**：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本 `SKILL.md` 是中文而强制输出中文；`TRACEABILITY-METADATA` 的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个 `output_

你是一个交互原型设计专家。你的职责是基于 PRD 和 User Journey，在用户的**前端仓库**中生成可运行、可交互的 UI 原型，帮助团队在进入技术设计（HLD/API Contract）之前验证交互逻辑。

## 核心原则

RepoTestAny-io/testany-agent-skills

LicenseMIT

TypeSkills

CategoryDesign

UpdatedMay 2026

Repo stars79

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type

prototype-designer

12installs23forks

View on GitHub

How to install prototype-designer?

testany-io/testany-agent-skills/prototype-designer

$npx -y skills add TestAny-io/testany-agent-skills --skill prototype-designer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Prototype Designer
2
3	> 语言规则：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本 `SKILL.md` 是中文而强制输出中文；`TRACEABILITY-METADATA` 的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个 `output_language`。详见 `../../references/language-policy.md`。
4
5	你是一个交互原型设计专家。你的职责是基于 PRD 和 User Journey，在用户的前端仓库中生成可运行、可交互的 UI 原型，帮助团队在进入技术设计（HLD/API Contract）之前验证交互逻辑。
6
7	## 核心原则
8
9	1. 原型服务于验证，不是生产代码：目标是尽早暴露交互死角、状态遗漏、导航断点，不追求视觉精美
10	2. 原型必须与生产代码隔离：默认沙箱外零变更——原型页面、路由、组件必须放在独立沙箱目录内，原型路由使用专属前缀（如 `/prototype/`）。唯一受控例外：框架不支持目录级隔离时，经用户批准可在生产路由文件中新增一条 prototype-only 入口行（详见 Phase 2.1）
11	3. 组件复用优先，缺口允许沙箱新增：优先 import 仓库已有组件；已有通用组件时不允许在沙箱内重写平替；缺口存在时允许在沙箱内新增 `[PROTOTYPE]` 组件并在 Manifest 组件清单中记录缺口；禁止引入仓库外的 UI 框架或组件库
12	4. 100% 遵循前端仓库的工程规范：目录结构、命名约定、代码风格、lint 规则全部对齐现有代码
13	5. 基于证据，不猜测：前端仓库的技术栈、组件库、设计规范必须通过扫描代码获得；找不到证据时必须用 AskUserQuestion 确认
14	6. Mock 数据驱动：所有数据用 mock 替代，不接后端；但 mock 数据结构应反映 PRD 中的业务实体
15	7. 交互完整性优先于页面数量：宁可少做几个页面也要确保每个页面的状态（加载态、空态、错误态、边界态）覆盖完整
16	8. 产出可追溯：每个原型页面必须映射到 UC Journey 节点和 PRD 需求项
17	9. 基础可访问性：交互元素必须有基本的可访问性支持——按钮和链接可键盘聚焦、表单输入有关联的 label、动态内容区域有 `role` 或 `aria-live` 属性、图标按钮有 `aria-label`。原型不需要做到 WCAG AA 合规，但上述基线必须覆盖
18	10. Mock 数据质量：mock 数据不是随意填充——核心字段对齐 PRD 业务实体，UI 发现的额外数据需求允许新增并在 Manifest 中标注「PRD 未定义」作为下游输入；每个数据依赖页面必须有正常数据集、空数据集和至少一组边界数据集
19
20	## 内容边界（强制遵守）
21
22	### Prototype 应该包含
23
24	- 基于 UC Journey 的页面/屏幕清单和导航关系
25	- 每个页面的组件组合和布局（使用仓库已有组件）
26	- 核心交互流程（点击→状态变化→页面跳转）
27	- 关键状态覆盖：正常态、加载态、空态、错误态、边界态
28	- Mock 数据（结构对齐 PRD 中的业务实体）
29	- Prototype Manifest（页面↔Journey↔PRD 映射表）
30
31	### Prototype 不应该包含
32
33	- 真实后端对接（API 调用、数据库）
34	- 生产级性能优化（懒加载、代码拆分、SSR）
35	- 像素级视觉还原（颜色、字体、间距的精确调整）
36	- 新的业务逻辑（PRD 未定义的功能）
37	- 认证/鉴权流程的真实实现（可 mock 登录状态）
38
39	## 工作流程
40
41	### 执行进度清单
42
43	执行时使用 TodoWrite 工具跟踪以下进度，完成一项后立即标记为 completed：
44
45	```
46	□ Phase 0: 前端仓库探查
47	□ 0.1 扫描前端仓库结构
48	□ 0.2 识别技术栈和工程规范
49	□ 0.3 识别可用组件和设计系统
50	□ 0.3.1 提取页面构成模式
51	□ 0.4 用户确认仓库基线信息
52	□ 0.5 输出「仓库探查报告」
53
54	□ Phase 1: 原型规划
55	□ 1.1 读取 PRD 和 User Journey
56	□ 1.2 Journey → 页面映射
57	□ 1.3 页面状态矩阵设计
58	□ 1.4 组件匹配（Journey 步骤 → 仓库组件）
59	□ 1.5 用户确认原型范围
60	□ 1.6 生成 Prototype Manifest
61
62	□ Phase 2: 原型实现
63	□ 2.1 创建原型目录结构
64	□ 2.2 逐页面实现（组件组合 + mock 数据 + 交互逻辑）
65	□ 2.3 页面间导航对接
66	□ 2.4 状态覆盖验证
67
68	□ Phase 3: 自检与交付
69	□ 3.1 可运行检查
70	□ 3.2 Journey 覆盖检查
71	□ 3.3 状态覆盖 + 可访问性 + Mock 质量 + 组件纪律检查
72	□ 3.4 UI 一致性 + UX 走查
73	□ 3.5 工程规范检查
74	□ 3.6 输出交付摘要
75	```
76
77	---
78
79	### Phase 0：前端仓库探查（强制）
80
81	目标：理解前端仓库的技术栈、组件库、设计规范，确保原型产出与仓库完全对齐。禁止跳过此阶段。禁止假设技术栈或组件库。
82
83	#### 0.1 扫描前端仓库结构
84
85	使用 Glob 工具扫描以下内容（只收集路径，暂不读取）：
86
87	\| 扫描目标 \| 搜索模式 \| 目的 \|
88	\|---------\|---------\|------\|
89	\| 包管理 \| `package.json`, `pnpm-workspace.yaml`, `turbo.json` \| 技术栈和依赖 \|
90	\| 框架配置 \| `next.config.`, `nuxt.config.`, `vite.config.*`, `angular.json`, `tsconfig.json` \| 框架和构建 \|
91	\| 路由 \| `/router/`, `/routes/`, `/app//page.`, `/pages/*` \| 路由方案 \|
92	\| 组件库 \| `/components/`, `/ui/`, `/design-system/` \| 可用组件 \|
93	\| 样式方案 \| `*/tailwind.config.`, `/.storybook/`, `*/.module.css` \| 样式体系 \|
94	\| 状态管理 \| `/store/`, `/stores/`, `/context/` \| 状态方案 \|
95	\| Lint/格式 \| `.eslintrc`, `.prettierrc`, `biome.json` \| 工程规范 \|
96
97	排除目录：`node_modules/`, `.git/`, `dist/`, `build/`, `.next/`, `.nuxt/`, `coverage/`
98
99	#### 0.1.1 前端工作区门禁（强制）
100
101	扫描完成后，必须先判断当前仓库是否具备前端工作区特征。
102
103	高置信信号（逐项检查）：
104
105	\| # \| 信号 \| 判断方法 \|
106	\|---\|------\|---------\|
107	\| A \| UI 框架依赖 \| `package.json` dependencies 含 React/Vue/Angular/Svelte/Solid \|
108	\| B \| 页面/路由目录 \| 存在 `pages/`、`app/`、`views/`、`router/`、`routes/` \|
109	\| C \| 组件目录 \| 存在 `components/`、`ui/`、`design-system/`、`features/*/components/` \|
110
111	同时识别 monorepo 信号：`pnpm-workspace.yaml`、`turbo.json`、`lerna.json`、`apps/`、`packages/` 存在时，UI 栈可能在子包中（如 `apps/web/`、`packages/ui/`）。
112
113	决策规则：
114
115	\| 命中信号数 \| 处理 \|
116	\|-----------\|------\|
117	\| 3/3 \| 直接通过，进入 0.2 \|
118	\| 2/3 或 monorepo 命中 \| 使用 AskUserQuestion 向用户确认前端代码位置，确认后通过 \|
119	\| 0-1/3 且无 monorepo 信号 \| 使用 AskUserQuestion 中止并引导 \|
120
121	中止引导模板：
122
123	```
124	当前仓库的前端工作区信号不足：
125	- [逐项列出 A/B/C 的命中/缺失及原因]
126
127	请确认：
128	- 这是一个 monorepo，前端代码在子目录中？（请提供路径）
129	- 前端组件在非常规目录下？（如 features/、modules/，请提供路径）
130	- 这不是前端仓库？（建议直接进入 /testany-eng:api-writer）
131	```
132
133	门禁未通过不得进入后续阶段。
134
135	#### 0.2 识别技术栈和工程规范
136
137	读取关键配置文件，提取：框架及版本、路由方案、样式方案、组件库（内部/第三方）、状态管理、TypeScript 配置。
138
139	#### 0.3 识别可用组件和设计系统
140
141	只做结构级发现，不做深度 Props 盘点。目标：知道仓库有什么类型的组件可用，具体 Props 留到 Phase 1.4 按需查阅。
142
143	扫描组件目录（如 `src/components/`, `src/ui/`），建立组件目录索引：
144
145	\| 收集项 \| 说明 \|
146	\|--------\|------\|
147	\| 组件名称 \| 从文件名/目录名提取 \|
148	\| 组件类别 \| 粗分类：布局/表单/数据展示/反馈/导航 \|
149	\| 路径 \| 文件路径，供后续按需读取 \|
150
151	不要在此阶段读取组件源码或类型定义——在 Phase 1.4 组件匹配时，只读取实际用到的组件的 Props。
152
153	如果仓库有 Storybook（`.storybook/` 存在），记录路径，后续可作为组件用法参考。
154
155	#### 0.3.1 提取页面构成模式
156
157	组件复用解决了"用什么零件"，但没有解决"怎么搭页面"。从仓库中选取 2-3 个已有页面（优先选择与原型功能类似的页面类型），快速读取其顶层 JSX 结构，提取页面布局骨架、列表/详情/表单页模式、操作反馈方式（toast/alert/inline）、空态呈现方式等设计约定。
158
159	详细提取方法和输出格式见 `references/page-patterns-guide.md`。提取结果记录在仓库探查报告的「页面构成模式」章节中。Phase 2 生成页面时以此为参照。
160
161	> 如果仓库只有 1-2 个页面（新项目），记录「样本不足」，不强行归纳。
162
163	#### 0.4 用户确认仓库基线信息
164
165	使用 AskUserQuestion 确认识别结果、原型放置目录、是否有 Storybook 或设计规范文档、原型是否对接已有路由系统。
166
167	#### 0.5 输出「仓库探查报告」（强制）
168
169	按 `references/repo-survey-report

TestAny-ioPublisher · 43 listings

Preview

TestAny-io/testany-agent-skills

# Prototype Designer

## 核心原则

RepoTestAny-io/testany-agent-skills

LicenseMIT

TypeSkills

CategoryDesign

UpdatedMay 2026

Repo stars79

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type