Senior Frontend SKILL makes Claude Code open your page in a real browser before it says done

// Detect dark theme var iframe = document.getElementById('tweet-2120513853725294751-511'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2120513853725294751&theme=dark" }

A passing typecheck tells you nothing about whether the button can be reached with Tab, or whether a long name breaks the layout on a phone. That gap is the whole reason senior-frontend exists. It is a skill in the Claude Code Templates catalog, 31K downloads, currently v2.0.0, and what it really does is refuse to let Claude call a UI task finished on the strength of a clean build.

What the skill actually changes

Most of the value is ordering. The skill makes Claude read before it writes: the framework and its version, the existing Button and Dialog components, the design tokens, the data layer, the npm scripts. In a project that already has tokens, a new hex value counts as a bug.

Then it forces the states nobody asks for. Loading, empty, error, success, pending action, long and odd content, partial failure. Each one has a required outcome, not a suggestion: the empty state has to say why it is empty and what to do about it, the error has to say what failed and offer a way out, and one row’s failed action must not break the rest of the list.

The build rules are platform first. <button> for actions, <a href> for navigation, never a <div onClick>. Every input gets a visible label, the right type, and autocomplete. Icon-only buttons get an accessible name that says which thing they act on, so you do not end up with twelve buttons all called "Delete". Async results land in an aria-live region.

Install it and look at what lands

npx claude-code-templates@latest --skill development/senior-frontend

That writes 6 files to .claude/skills/senior-frontend/: the SKILL.md, two reference docs (a UI review checklist and a set of React state and effect rules), a NOTICE file, and two scripts. Copy the folder to ~/.claude/skills/ if you want it in every project instead of one.

Only the name and description sit in your context until the skill is invoked. The body loads when it fires, and the reference docs load only when Claude reaches for them. Worth knowing, because the description is deliberately aggressive: it opens with “You MUST use this whenever you build, change or review user interface code, including small UI tweaks and when the user is in a hurry”. That is what makes it catch the one line CSS fix, and also what will make it fire more often than you might want. If that bothers you, disable-model-invocation: true in the frontmatter leaves it available as /senior-frontend and nothing else.

The part that costs you time

// Detect dark theme var iframe = document.getElementById('tweet-2114401602450706524-137'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2114401602450706524&theme=dark" }

Step 6 of the skill is where the 3x execution time comes from. After typecheck, lint, test and build, Claude is told to start the dev server and run the bundled checker against the page it just built:

node .claude/skills/senior-frontend/scripts/check_ui.mjs "http://localhost:5173/#/team" --out .ui-check

The script loads the page at 375 px and 1280 px (those are the defaults, --widths changes them), saves a full page screenshot at each width, and reports console errors, horizontal overflow, controls with no accessible name, inputs with no label, images with no alt or no explicit size, and clickable elements that are not interactive. At the widest width it presses Tab up to 40 times and lists every focus stop, flagging the ones with no visible focus indicator.

One caveat the post leaves out: this step is not free. The script resolves Playwright from your project or a global install and exits with code 2 if it finds neither, so a project without Playwright gets the checklist and no browser pass. axe-core is optional in the same way: if it resolves from your project, WCAG 2.2 AA violations get folded into the report; if not, the report says so and moves on.

The instruction after that one matters more than the script: look at the screenshots, do not just confirm they exist. Then force the error state, search for nothing, remove the last item, submit something invalid, and use only the keyboard.

Is the trade worth it

I measured it on Sonnet 5.5 and browser verification went from 0/8 without the skill to 10/10 with it, at roughly three times the execution time. That is one project and not a benchmark, but the direction is easy to believe: an agent that is told to open the page will open the page, and an agent that is not will tell you it builds.

The honest version of the trade is that you are paying wall clock time to move a class of bugs from your review to the agent’s. If you are prototyping, that is a bad deal and you should skip the skill. If the thing you are building will be used with a keyboard, on a phone, or by someone who will hit the error state, it pays for itself the first time.

The skill also ends every run with a report: what it built, which existing components and tokens it reused, what it verified and how, and what it could not verify. That last part is the one to read.

Where the skills live

// Detect dark theme var iframe = document.getElementById('tweet-2120365886880059433-594'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2120365886880059433&theme=dark" }

• Component page: senior-frontend on aitmpl.com
• Related: systematic-debugging
• Full skills catalog: aitmpl.com/skills
• Everything else: aitmpl.com

You can follow me on my social media:

• Twitter (English): https://x.com/dani_avila7
• LinkedIn (Spanish): https://www.linkedin.com/in/daniel-avila-arias/
• Youtube (Spanish): https://www.youtube.com/@daniiielsan
• Instagram (Spanish): https://www.instagram.com/danielsan_avila/