Frontend Engineer

The Frontend Engineer builds everything people see and touch on your site or app. That means the pages, the buttons, the forms, the menus and the lists. It builds them on top of your design system, and it checks each one in the browser before it says the work is done.

Think of the Frontend Engineer as a skilled carpenter. The designer has drawn the room, with the colours, the wood and the finish already chosen. The carpenter builds the shelves, doors and tables to fit that plan, and then runs a hand over every joint before handing the room over. You get pages that match, not pages that each look like a different project.

The problem this member removes is the slow, fiddly part of building screens. Layouts that break on a phone, buttons with no focus outline, forms with no labels and pages that show nothing while they load are all common. The Frontend Engineer knows the checks, runs them, and fixes what fails.

Every page it builds follows a few house standards. Colours come from named design tokens (saved colour values with a clear name, such as "primary") rather than raw colour codes, so dark mode works without extra work. Every page handles three states: loading, when content is on its way; empty, when there is nothing to show yet; and error, when something went wrong. Every page also works on a small phone screen with no sideways scrolling, and every button, link and input shows a clear hover and focus style.

Think of a tailor. Before cutting any cloth, the tailor measures the customer and checks the fabric, then sews every seam to the same standard. The Frontend Engineer works the same way. It reads the design tokens and the data shape first, then builds each screen to the same measured standard, so the finished page fits the rest of the app.

• Build pages and components, from a plain HTML site up to a full web app.
• Follow your design system, so colours, spacing and dark mode stay consistent from page to page.
• Connect screens to the data the Backend Engineer provides, with loading, empty and error states for each one.
• Fix layout breaks, display bugs and accessibility problems, then show the fix working in the browser.
• Make quick changes, such as swapping one layout for another, rearranging sections or adjusting spacing.
• Check each page at desktop and phone widths, with keyboard focus and labels in place, so people using a keyboard or a screen reader are not left out. It also checks that every image has alt text, so a screen reader can describe it.
• Work in the Files, Review, Terminal and Browser panels, so you can see the code and the running page together.
• Use GitHub, Vercel and Figma once you connect your own accounts.

The Frontend Engineer has five skills. Each one is a playbook for a kind of screen work.

modify-ui makes quick look changes. It finds the exact files to touch, so a change to colours or layout does not touch the rest of the app. For example: "Swap the hero section and the feature grid on my home page."

generate writes one piece of code, such as a reusable component or a hook, by copying the team's proven patterns. It does not invent a new style each time. For example: "Make a reusable stat card I can use on three pages."

add-page adds a new page that uses the app's shared navigation and parts, then records the page for the next member. For example: "Add an About page that matches the rest of the site."

project-checks runs guard checks before every write and command. It looks for reused parts, hardcoded secrets and risky commands, and nothing runs without your approval. For example: it stops a password from being typed straight into a page.

clone-build rebuilds an app one screen at a time from a recon map, starting with the app shell and then each screen with all its states. It writes every line fresh. For example: "Build screen S07 of the clone."

1. You type: "Add an About page that matches the rest of the site."
2. The Frontend Engineer reads the project record for the site's colours, fonts and existing pages. It copies what already works and does not guess.
3. It checks the shared parts, such as the navigation bar and the footer. It reuses them rather than building new ones.
4. It writes the About page with a loading state, an empty state and an error state, plus clear headings and a page title for search engines.
5. It checks the page at desktop and phone widths, in light and dark mode. It also tests that you can move through every control with the keyboard.
6. If the page needs a new package, it asks you first. This page needs none, so it carries on without asking. It also asks before deleting files, publishing anything live or changing a page you did not ask it to touch.
7. It records the new page in the project record, so the next member knows the page exists.
8. You get a link to the live page in the browser panel, a short description of how it looks on a phone and on a desktop, and a list of the files it changed.

What you get at the end is a page you can open and try yourself. Use it on your own phone and laptop, move through it with the keyboard, and compare it with the other pages. If anything looks off, say so in the chat, and the Frontend Engineer fixes it and checks it again with the same standards as before.