mcpField
P
product-designer

product-designer

github.com/blink-new设计与 UI39 次安装
代码仓库

关于 product-designer

面向产品设计与开发工作的技能，先探索代码库并梳理用户需求，再通过 ASCII 原型设计完整界面流程，最后编写 PRD。适用于需要贴合现有代码、组件和计费逻辑的新功能。

主要功能

  1. 01并行探索前端、后端与基础设施
  2. 02整理用户需求和用户故事
  3. 03通过提问澄清设计决策
  4. 04绘制含状态的 ASCII 界面原型
  5. 05将最终设计写入 PRD

适用场景

  1. 01为新功能梳理端到端用户流程
  2. 02设计包含空白、加载和错误状态的界面
  3. 03规划适用功能的订阅计费逻辑
  4. 04基于现有组件形成设计与 PRD

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/blink-new/claude --skill product-designer

安装后在 Claude Code 中输入/product-designer确认已加载。

详细介绍

产品设计师 Skill

该 Skill 的作用

端到端构建功能，包括计费逻辑、UI/UX 设计，以及通过 pgboss 实现的周期性计费逻辑。

使用 ASCII 绘制 UI 设计图。 确保达到一流的 Linear/Stripe UI/UX 水准。复用现有组件和设计布局——在适用的情况下，确保完全沿用现有的部署 claw Agent 和部署生产环境托管模态框。让整个体验流畅顺畅。考虑整个流程中的所有用户需求和用户故事。先列出用户需求，以及支持这些需求的所有屏幕和流程，再用 ASCII 进行设计。反复迭代，直到达到一流的 Linear/Stripe/Vercel 风格 UI/UX，并符合现有框架和导航逻辑的品牌风格。然后展示给用户。

首先探索代码库，了解所有相关文件和现有逻辑流程。前端、后端、基础设施，全部都要检查。 然后，使用 askUserQuestions 工具向用户提出重要问题，以统一设计决策。

最后，根据功能名称（kebab case）写入现有或新建的 .todo/[feat-name]/PRD.md 文件。

工作流

阶段 1：探索代码库

使用并行子 Agent 同时探索前端、后端和基础设施：

  • 查找与该功能最相似的现有模态框、流程和组件
  • 确认现有计费、pgboss 任务模式和 API 结构
  • 记录当前使用的导航模式、布局组件和设计系统令牌
  • 查找可复用的现有相关逻辑

重点检查以下位置：

  • src/components/ — 现有模态框、对话框、UI 基础组件
  • src/app/api/ — 现有 API 路由和模式
  • src/lib/ — 计费、任务、业务逻辑工具
  • blink-apis/ — 后端服务模式
  • .todo/ — 任何现有的 PRD 或待办事项上下文
阶段 2：列出用户需求和用户故事

在进行任何设计之前，列出：

USER NEEDS:
1. [Primary need — the "why" behind this feature]
2. [Secondary need — what else supports their goal]
3. ...

USER STORIES:
- As a [persona], I want to [action] so that [outcome]
- As a [persona], I want to [action] so that [outcome]
- ...

SCREENS & FLOWS:
1. [Screen name] — [what it does, which user story it serves]
2. [Screen name] — [what it does, which user story it serves]
3. ...
阶段 3：提出对齐问题

在设计之前，使用 askUserQuestions 工具澄清关键设计决策。重点关注：

  • 范围（v1 版本包含和不包含哪些内容）
  • 计费模式的具体细节（如适用）
  • 目标用户角色或边缘情况
  • 需要严格遵循或避免的现有 UX 模式
  • 时间有限时各屏幕的优先级
阶段 4：ASCII 原型

使用 ASCII 设计每个屏幕和状态。反复迭代，直到达到一流品质。

设计标准：

  • 匹配 Linear/Stripe/Vercel 的风格：简洁、极简、信息密度高
  • 精确复用现有模态框外壳、按钮样式和布局基础组件
  • 展示所有状态：空状态、加载中、错误、成功和边缘情况
  • 在有意义的地方标明悬停/焦点/激活状态

ASCII 格式约定：

┌─────────────────────────────────────────┐
│ Modal Title                         [X] │
├─────────────────────────────────────────┤
│                                         │
│  Section header                         │
│  ┌───────────────────────────────────┐  │
│  │ Input field               [icon]  │  │
│  └───────────────────────────────────┘  │
│                                         │
│  [Secondary action]     [Primary CTA →] │
└─────────────────────────────────────────┘

将完整流程设计为相互连接的屏幕：

[Screen A] ──→ [Screen B] ──→ [Screen C: Success]
                    │
                    └──→ [Screen B2: Error state]
阶段 5：编写 PRD

将最终设计写入 .todo/[feat-name]/PRD.md：

# [Feature Name] PRD

## Overview
[1-2 sentence summary]

## User Needs
[List from Phase 2]

## User Stories
[List from Phase 2]

## Screens & Flows
[List with descriptions]

## ASCII Designs
[All ASCII prototypes from Phase 4]

## Component Reuse
[Which existing components/modals/patterns to reuse]

## API & Backend
[Required endpoints, pgboss jobs, billing logic]

## Open Questions
[Unresolved decisions or edge cases]

质量标准

展示之前，自行检查：

  • 所有用户故事都有对应的屏幕/流程
  • 已设计空状态、加载中和错误状态
  • 明确复用了现有组件（而非重新设计）
  • 如适用，已完整梳理计费/周期性计费逻辑
  • ASCII 设计在等宽字体渲染下清晰易读
  • PRD 已编写并保存到 .todo/[feat-name]/PRD.md

评论

支持 Markdown