Senior UX Engineer-level React orchestrator — opening moves, decision framework, and routing to specialized React skills (component design, a11y, styling, performance, marketing patterns, onboarding/docs, interview narration). Use when starting any React component build, UI feature, technical interview task, marketing-site work, product onboarding, or documentation site work. Triggers on "React", "component", "UX engineer", "interview build", "landing page", "onboarding", "docs site", or any prompt that mixes UI + code judgment.
react-senior-ux — Orchestrator
This skill is the entry point for any React work that's framed as UX engineering (not pure data/logic). It sets the mental model, routes to specialized skills, and prevents the most common interview failure mode: writing code before deciding what "done" looks like.
When to use this skill (vs. jump straight to a sub-skill)
Invoke this orchestrator first when:
The brief is open-ended ("build X component", "make this landing page")
You're starting a build session for an interview or take-home
You need to decide what to optimize for before writing code
Skip to a sub-skill when:
The task is narrow and named (e.g. "fix this a11y issue" → react-a11y directly)
The 4 senior-engineer opening moves
Before writing a single line of JSX, do these in order:
1. Restate the brief in your own words
Out loud or as a comment at the top of the file:
// Brief: Build a pricing card component used on the marketing site.
// Must: 3 tiers, monthly/yearly toggle, CTA per tier, responsive.
// Implied: a11y, design tokens, hover/focus states, mobile-first.
Why this matters: in a "solo build + review" format, this comment becomes your narration anchor.
2. Identify the "UX Engineer signal map"
For any UI brief, at least three of these should be visible in your code by the end:
Semantic HTML — <button> not <div onClick>, <nav> for nav, real <form>
Accessibility — keyboard nav works, focus visible, labels associated, contrast
Component API — props are minimal, intent-revealing, typed
Responsive — works at 320px, 768px, 1280px without breaking
Design tokens — no magic numbers; spacing/colors via tokens or theme
States — hover, focus, active, disabled, loading, error, empty
Performance — no layout shift, no janky animation, no oversized images
Polish — micro-interactions, transitions, attention to spacing
If you only ship "it works", you're a mid-level. If you ship 5+ of the above visibly, you're senior.
3. Scope: MoSCoW the build
Write three lists before coding:
Must (will fail without): core happy path, the visible UI matching the brief
Should (will mention but maybe skip): error states, edge cases, one extra a11y polish
Won't (will explicitly call out in review): testing, theming abstraction, motion library
In the walkthrough, naming the "Won't"s is a senior signal. It shows you saw them and made a call.
4. Pick one "wow" detail (conditional — see Calibrate section below)
Choose ONE thing you'll over-invest in — the thing the reviewer will remember.
Good candidates for Netlify Marketing:
A keyboard-perfect interactive (combobox, tabs, carousel)
An accessibility detail nobody asks for (live region for form errors, skip link, prefers-reduced-motion)
A micro-interaction that respects motion preferences
A precisely-implemented design token system
Important: skip or downplay this step if the brief signals simplicity. See "Calibrate to the brief" below.
Calibrate to the brief — when simple beats clever
The "pick a wow detail" advice is calibrated for performative interviews (live coding, "impress us"). For deliverable interviews where the brief explicitly says things like:
"Keep it simple"
"We're not testing optimization or cleverness"
"Documentation is part of the evaluation"
"Don't worry about completeness"
...flip the strategy. Solid working code + clear documentation + 1–2 defensible decisions beats a flashy demo with rough edges.
The Netlify Senior UX Engineer technical project is in the second category. The recruiter said verbatim: "we're not looking for completeness and this is not a test of cleverness or optimization, so we encourage you to keep it simple. The goal of this project will be to allow you to write code, showcase your problem-solving skills, and demonstrate your ability to create clear documentation."
Translation: ship working, well-documented, well-considered code. Don't add a roving-tabindex tabs component if a <details>-based FAQ would deliver the brief.
Senior-signal recalibration for simplicity-signaled briefs
Cut your "wow" to zero or one. Don't over-invest visibly.
Invest the saved time in documentation (see the react-docs-writing skill).
Prefer native HTML + simple state over compound components and headless hooks (see react-html-platform).
Resist adding libraries. Each dep is a decision you'll have to defend.
Make 2–3 decisions you can clearly justify in the next-day review. That's senior signal — not the number of advanced patterns you used.
Senior-signal that stays the same for both kinds of briefs
Regardless of calibration:
Semantic HTML. Always.
Real <label>, real <button>, real <form>. Always.
Keyboard works, focus is visible, errors are announced. Always.
No magic numbers; every spacing/color is a token. Always.
TypeScript that types intent, not just shape. Always.
These are baseline; they're not the "wow." If they're missing, no calibration saves you.
Routing to specialized skills
Once you've done the 4 opening moves, the work routes naturally:
Building against a REST API (TanStack Query, fetch wrapper, normalization)
react-api-consumer
Multi-route SPA (data router, focus on route change, scroll restoration)
react-routing
Third-party media embeds (YouTube, SoundCloud, Vimeo, X-Frame-Options)
react-embeds
These can be invoked together — a pricing card touches design, a11y, styling, and marketing patterns simultaneously.
Polish phase — after the build, before the ship
The "wow detail" lives in the build. Polish is a different mode — production hardening of something that already works. Reach for these when the brief said "deploy this" or you're past MVP and entering the "make it shippable" stage.
Polish-phase routing
If the polish is about...
Load this skill
Tests (E2E, unit, a11y assertions, CI)
react-testing
Favicon, OG/Twitter card, social meta, theme-color
react-performance (Social + brand assets section)
README badges, Tests section, live demo link, deploy notes
react-docs-writing (Production-OSS extensions)
Known-quirks index for a specific API the app consumes
The API-specific skill (e.g. kratecms-api)
Looking up the canonical spec for OG / WCAG / manifest / theme-color
react-resources
Polish checklist (run before declaring "shipped")
Repo hygiene: LICENSE present, README is accurate, .gitignore doesn't leak .claude / .idea / test artifacts
Repo discoverability: GitHub topics set, homepage URL points at the live deploy
Social surface: favicon (SVG + apple-touch-icon), OG card (1200×630), Twitter Card, theme-color, canonical link
Test surface: at least one happy-path E2E spec + a "no console errors" spec; CI runs them on PR
Production deploy: deploy config in repo (netlify.toml / vercel.json), SPA fallback wired, long-cache on hashed assets
Deployed URL works: hard-navigate to a deep route, refresh — no 404 from the host
Production smoke: same E2E suite passes against the deployed URL (E2E_BASE_URL pattern)
No dev-only assumptions in production: no localhost hardcoded, no DDEV / dev-cert references, no console.log in shipped code
No TODO/FIXME that aren't tracked: either resolve, or file an issue and link to it from the code
This checklist is separate from the build-time "before done" checklist further down — it covers the production layer.
Static-first thinking — server components / SSG where possible, hydrate sparingly
Component reusability — pages share primitives; the right component fits the system
If you're given a choice and don't know the convention, bias toward: static, accessible, fast, restrained, reusable.
Frame work in user + business outcomes, not just craft
The JD emphasizes "strategic thinker," "human-centered," "conversion-focused." Don't just describe what you built — describe what user friction it removes or what business outcome it serves.
Bad framing: "I built a multi-step form."
Good framing: "I built a multi-step form because a single long form had 60% abandonment. Each step has one job, one CTA, and a progress indicator so the user can see the end."
Bad framing: "I used semantic HTML."
Good framing: "I started with semantic HTML — accessibility is a Netlify product value, and <button> ships keyboard behavior for free, which means I spend interview time on the hard parts."
Bad framing: "I added Framer Motion."
Good framing: "Motion guides the eye from the headline to the CTA. I gated it on prefers-reduced-motion so we don't trade conversion for inclusion."
Three frames to keep in your back pocket:
Conversion / friction — "This removes a click; this clarifies the next action."
Consistency / system — "This reuses the system's primitive; this would belong in the design system."
Inclusion / craft — "This works for keyboard, screen reader, low-vision; the craft level matches the brand."
AI-collaboration mindset (the JD explicitly wants this)
The JD calls out: "Growth mindset: curious, adaptable, and eager to explore new technologies, tools, and methods—including AI for code generation." That phrasing is rare — they're saying it on purpose.
Translation: don't be apologetic about using AI tools. If you used Claude / Copilot / etc. during the build, mention it confidently. Frame it as a senior engineer's force multiplier, not as a crutch.
What that sounds like in the walkthrough:
"I used Claude to scaffold the form a11y wiring quickly so I could spend the time on the validation UX and design-token integration."
"I leaned on AI for the boilerplate, then hand-edited the parts that needed real judgment — prop API, error copy, focus management."
"I treat AI like a fast pair: it drafts, I review and reject. The senior call is what to keep."
What NOT to say:
"I let Claude write it." (passive — sounds like you didn't own it)
"Sorry, this is AI-generated." (apologetic — they don't want that)
"I would have done it differently myself." (undermines your own output)
If they ask "what role did AI play?" have a real answer: where you used it, where you didn't, and why.
The senior-engineer "before done" checklist
Before you say "I'm finished" in the review:
Keyboard: I can tab through every interactive element in sensible order, and focus is always visible
Screen reader: every control has an accessible name (label, aria-label, or visible text)
Responsive: works at 320px wide without horizontal scroll
useEffect for things that aren't side effects (computing, transforming)
Inline arrow functions in render when memoization matters (rare — but call it out)
Magic numbers in CSS (margin: 17px)
Class names like red-button instead of button-primary
aria-label on something that already has a visible label
Animating width/height/top instead of transform
Forgetting prefers-reduced-motion
Forgetting loading="lazy" on below-the-fold images
Forgetting width/height on images (causes CLS)
When in doubt, articulate the tradeoff
The senior move when uncertain isn't to pick correctly — it's to make the tradeoff visible:
"I went with controlled input here because the parent needs the value for validation. If this were used in a form library context, I'd switch to uncontrolled with a ref to avoid the rerender."
"I'm using useMemo here because the filter runs on every keystroke against a 200-item list. For a 10-item list I wouldn't bother — the memo overhead would cost more than the recompute."
That's the senior-level signal: you saw the tradeoff, you made a call, you can defend it.
