Product frontend design
Skill keithhegit/product-frontend-design/skills/product-frontend-design
Product + Frontend Design 是一个面向 Codex 的流程型 skill，用来把 UI/UX 请求变成更稳定的两段式协作： Product Design 先定义用户、任务、体验闭环、词汇表、状态和验收标准。 Frontend Design 再把已确认的体验转成布局、层级、文案、交互细节和截图级打磨。 它刻意保持小而清晰。这个 skill 不替代 Codex Product Design 插件，也不替代 Frontend Design skill。它只负责固定两者的协作顺序和质量标准，避免 UI 工作变成功能堆叠或模板化界面。
npx -y skills add keithhegit/product-frontend-design --skill product-frontend-designAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Run Product Design and Frontend Design as one UI/UX collaboration workflow. Use when the user invokes Product Design + Frontend Design, asks for a UI/UX redesign, asks to make an interface more user friendly, designs a plugin panel, or wants a product flow turned into polished frontend UI.
SKILL.md
2.8 KB, as published. Nobody here has run it
Product + Frontend Design
Use this skill as the shortcut entry for the combined UI/UX workflow.
When this skill is active, also use the underlying Product Design and Frontend Design skills if they are available in the current environment. This shortcut does not replace those skills; it fixes their collaboration order and quality bar.
Required Order
-
Use Product Design first, starting from
product-design:indexwhen available.- Confirm the product, user, core task, design brief, experience loop, interaction states, empty states, error states, and acceptance criteria.
- For new UI without a visual target, run the Product Design brief gate before implementation.
- If visual exploration is needed, present options before coding.
-
Use Frontend Design second.
- Translate the approved experience into concrete layout, visual hierarchy, copy, controls, responsive behavior, and screenshot-level polish.
- Choose one signature element that makes the interface easier to understand.
- Keep the rest of the UI restrained and consistent with the host product.
-
Implement only after the experience direction is clear.
- Follow the existing app design system and local component patterns.
- Avoid exposing implementation terms to non-professional users.
- Verify with screenshots or GUI retest in addition to type/build checks.
Vocabulary Rule
Prefer words users already understand. Hide implementation terms unless the screen is explicitly for developers.
For each product, define a small vocabulary map during Product Design:
- What the system calls the thing internally.
- What the user should see in the UI.
- Which technical terms must stay hidden.
Avoid exposing implementation terms like internal IDs, tool calls, manifests, indexes, provider errors, or storage internals in ordinary UI.
New User Rule
For first-time or non-professional users, the first screen must answer:
- What is this?
- Why should I use it?
- What should I do first?
- What happens after I click the main button?
- How do I recover if nothing is ready yet?
Empty states must include examples, next-step buttons, and a plain-language success path.
Output Contract
Before implementation, produce a concise UI/UX brief with:
- Target user and core job.
- Experience loop.
- Vocabulary map.
- First-screen structure.
- Empty, loading, success, and error states.
- Visual direction and one signature element.
- Verification plan, including screenshot or GUI retest.