Build a UI feature that holds upSix steps, from ticket to a reviewed PR

1. 1

   Read the ticket and the codebase

   What exists before you add anything: components, tokens, state, data fetching, how similar features are built and tested. Then a six-line plan, with every state.

   Skills: Frontend Ui Engineering or React Composition Patterns

   Before writing code for [feature], map what this repo already has (components, tokens, state, tests) and write a six-line plan with every state.

2. 2

   Build it on the system

   Semantic HTML, keyboard and focus, labels, and only the codebase's own tokens and components. A distinctive look only where the feature needs one.

   Skills: Frontend Ui Engineering or Frontend Design

   Build [feature] on the existing components and tokens: happy path first, then loading, empty, error and long content. Keyboard and focus included.

3. 3

   First render

   Run it and look at it at desktop and phone width, in light and dark. Does it fit the product, and does the page stay inside the screen on a phone?

   Run the app, screenshot [feature] at 1440 and 390 px wide, and check every state renders and nothing scrolls sideways on mobile.

4. 4

   Fast and correct React

   Measure first. Then the usual suspects: waterfalls, work on every render, state too high up, heavy client bundles, layout shift.

   Skills: React Best Practices or Performance Optimization

   Check [feature] for React performance problems: data waterfalls, unneeded re-renders, bundle size, layout shift. Measure before and after each fix.

5. 5

   Test it in a real browser

   Playwright on the running app: the main flow, every state with stubbed slow and failing responses, keyboard only, phone width, and a clean console.

   Skill: Web App Testing

   Write Playwright tests for [feature]: main flow, each state with stubbed responses, keyboard only, 390 px wide, no console errors. Run them.

6. 6

   Review before the PR

   The diff on five axes: correctness, readability, architecture, security, performance. Then one fresh look at the UI, and a PR description with screenshots.

   Skill: Code Review And Quality

   Review this diff on correctness, readability, architecture, security and performance. Fix what is clearly wrong, then write the PR description.

• Step 3, on a phone: the "Copy all installs" button and the file block were both solid black and competed. On a guided kit the copy button is now an outline.
• Step 5, the browser test, caught a real bug: an empty email still went to the server. It now stops in the browser, with a message and the focus back on the field.
• Step 5 also checked the bar at the bottom of the screen: hidden while the block is in view, shown after scrolling past it, and links you can tab to only when it shows.

• The six stepsSkillHub · leads your AI tool through them
• Frontend UI EngineeringAddy Osmani · MIT
• Frontend DesignAnthropic · Apache-2.0
• Performance OptimizationAddy Osmani · MIT
• Webapp TestingAnthropic · Apache-2.0
• Code Review and QualityAddy Osmani · MIT
• React Best PracticesVercel · linked, not included
• React Composition PatternsVercel · linked, not included

Curated by Teun Somers, tested with Claude. Every skill links to its source and keeps its licence.