jaballer

React accessibility (WCAG 2.2 AA) — semantic HTML first, ARIA only when needed, focus management, keyboard navigation, screen reader support, color contrast, prefers-reduced-motion. Use when building any user-facing UI, forms, modals, menus, tabs, carousels, or when accessibility is in scope. Critical for Senior UX Engineer interview signal. Triggers on "a11y", "accessibility", "WCAG", "ARIA", "keyboard", "screen reader", "focus", "semantic".

Building a React frontend against an external REST API — TanStack Query setup, the standard fetch wrapper with typed errors, loading/error/empty/refetching states, paginated lists with keepPreviousData, optimistic updates, retry policy, query keys, Vite dev proxy for CORS, normalizing third-party API quirks (boxed values, inconsistent envelopes, missing filters), the "verify the response shape with curl before typing it" rule. Use whenever a React app talks to a remote API — public REST, internal microservice, headless CMS, third-party SaaS. Triggers on "API", "REST", "fetch", "TanStack Query", "react-query", "SWR", "CORS", "headless CMS", "data fetching", "loading state", "pagination", "optimistic update", "retry", "error boundary", "stale-while-revalidate", "endpoint".

Project scaffolding for the first 5 minutes of a React interview build — Vite + React + TypeScript + Tailwind as the primary scaffold, Next.js App Router as alternate, "they gave me a starter repo" path (most likely Netlify scenario), file structure recommendations, useful dependencies (clsx + tailwind-merge + zod), App.tsx skeleton with brief-restate header, README starter, Tailwind config, what NOT to set up. Use at the start of any interview build to skip 5–10 minutes of setup decisions. Triggers on "scaffold", "bootstrap", "project setup", "first 5 minutes", "vite", "create vite", "package.json", "tailwind config", "App.tsx", "start a project", "new project", "set up", "initial setup", "starter repo".

30-second component-tree decision recipes for common interview prompts. When the brief drops, look it up here and get tree + state-ownership + must/should/won't + one "wow" detail. Covers pricing card, hero + signup, multi-step onboarding, FAQ, modal, tabs, combobox, comparison table, newsletter, sticky nav, sidebar nav, code block, dashboard card, testimonial carousel, feature grid. Load this skill FIRST when starting any interview build. Triggers on "interview build", "what should I build", "component tree", "where to start", "brief recipe", "pricing card", "hero", "build a form", "build a modal", "build tabs", "build accordion", "build navigation", "build dashboard".

React component architecture and API design — composition, compound components, headless patterns, prop interfaces, controlled vs uncontrolled, polymorphic components, TypeScript prop typing, slot patterns. Use when designing component APIs, building reusable components, structuring a component library, or refactoring component structure. Triggers on "component API", "reusable", "compound component", "headless", "polymorphic", "props", "design a component".

Documentation patterns for React take-home projects and interview builds where documentation is an explicit deliverable — README structure (Overview / Decisions / Tradeoffs / How to Run / What's Next), in-code "why" comments (sparse, surgical), the brief-restate header at the top of the entry file, DESIGN.md / decisions log format, the "considered and rejected" template, PR description writeups, what NOT to document. Use whenever the project asks for documentation, especially for take-home interviews like the Netlify Senior UX Engineer technical project. Triggers on "README", "documentation", "design doc", "decision log", "DESIGN.md", "PR description", "code comments", "explain my code", "write docs", "take-home", "project deliverable", "Netlify project", "interview docs".

Provider-specific patterns for embedding third-party media in React — YouTube (incl. nocookie), SoundCloud (share URL vs. w.soundcloud.com player), Vimeo, Spotify, Bandcamp, Apple Podcasts, Twitter/X, Mastodon, Bluesky, CodePen, Figma, GitHub Gist. Each provider's iframable URL pattern, X-Frame-Options caveats, sandbox flags, aspect ratio, lazy loading, a11y (title attribute), responsive containers, and privacy-respecting variants (youtube-nocookie, dnt params). Use whenever rendering an iframe to a third-party platform — blog content, CMS embed URLs, social posts, media players. Triggers on "embed", "iframe", "YouTube", "SoundCloud", "Vimeo", "Spotify", "Bandcamp", "oEmbed", "X-Frame-Options", "player URL", "youtube-nocookie", "Twitter embed", "Mastodon", "CodePen", "Figma embed", "GitHub gist".

Comprehensive form patterns for React 19 / Next 15 — Zod schemas with type inference, Server Actions + useFormStatus + useActionState, useOptimistic for instant feedback, react-hook-form when Server Actions aren't on the table, multi-step forms with useReducer + persistence, async validation, file upload with progress, error messages with full a11y wiring (aria-invalid, aria-describedby, role=alert, focus management on errors). Use for any form-heavy interview build — newsletter signup, contact form, login, signup, multi-step onboarding, settings page, file upload. Triggers on "form", "validation", "zod", "react-hook-form", "Server Action", "useFormStatus", "useActionState", "useOptimistic", "controlled vs uncontrolled", "multi-step form", "file upload", "form a11y", "form errors", "newsletter signup".

Polls a pull request on a fixed interval until it reaches a terminal state — approved, changes-requested, merged, or closed — then either notifies you or hands off to /webdev:merge-pr. Use when the user says "watch the PR", "poll PR #X", "tell me when it's approved", "keep checking the PR", "let me know when review comes back", or "auto-merge when it's approved". Takes a PR (number/URL), a check interval, and an on-approval action (notify | merge). Built on ScheduleWakeup: each poll re-arms the next and the loop ends itself on a terminal state or a safety cap. Silence is never reported as approval.

Commits completed work the right way — staging the right files, running tests and the formatter first, a hostile pre-push self-review, a conventional-commits message, push, and (by default) opening a PR. Use when the user says "commit", "let's commit", "commit these changes", "I'm ready to commit", or "commit and push". Trigger any time work is complete and ready to commit — don't wait to be asked about best practices.

Resolves the project's toolchain — package manager, test runner, formatter/linter, framework, and dev/run command — so other webdev skills issue the right commands on any stack. Auto-detects JS/TS and PHP; every other stack is supported through an explicit .claude/webdev.json override. Use at the start of any workflow that needs to run tests, format code, install dependencies, or start the dev server. Other webdev skills invoke this first. Honors an explicit .claude/webdev.json override before falling back to filesystem detection.

Triage and fix a failing CI check on a PR or branch. Use when the user says "CI is failing", "the build is red", "checks failed", "fix the pipeline", "why did CI fail", or any time a PR's checks are red after a push. Reads the failing run's logs via gh, finds the first real error, classifies the failure (caused by this branch / pre-existing on base / flaky or infra), reproduces it locally, fixes the cause, and watches the checks go green. For review COMMENTS on a PR use /webdev:review-pr — the two chain naturally when a PR is both red and commented.

Deep-dive review of a single specific merged PR to catch issues that slipped through code review — bugs, missing tests, inconsistencies, doc gaps. Use when the user wants to review a particular PR after merge or spot-check a specific merge. Trigger on "review PR #123", "check what that PR changed", "post-merge review", "did anything slip through on PR #X". Unlike /webdev:qa-review (which audits all recent merges broadly), this skill focuses on one PR in depth.

Broad QA review of recently merged functionality (not one specific PR). Use when the user wants to review recent work, smoke-test merged features, or audit the latest additions. Trigger on "review recent changes", "QA the latest merge", "smoke test", "review what was merged", "anything need fixing?", "check the recent work", "full review". For a deep-dive on a single PR, use /webdev:post-merge-review instead.

Runs the project's test suite at the smallest scope that proves the change. Use when the user asks to "run tests", "check tests", "make sure tests pass", or before committing or opening a PR. Also trigger automatically after code changes that could affect existing functionality. Resolves the test command via /webdev:detect-stack, so it works on any stack (vitest, jest, phpunit, pest, …).

Proves a change works by exercising the RUNNING app, not just the test suite — start the dev server, drive the changed behavior, observe the result. Use before committing user-facing work (UI, routes, forms, emails-to-preview, API responses), or when the user asks "does it actually work?", "check it in the browser", "try it out", "verify the change". Tests prove the behaviors that have tests; this proves the behavior a user will actually hit. Complements /webdev:run-tests — it does not replace it.

Best practices for committing completed work on the FiveTwoFive WordPress site. Use this skill when the user says "commit", "let's commit", "commit these changes", "I'm ready to commit", or "commit and push". Covers rebuilding theme assets, staging the right files (the deny-all `.gitignore` silently ignores new files), a WordPress-specific hostile-read checklist, writing a good commit message, and opening a PR. Trigger any time work is complete and ready to be committed — don't wait for the user to ask about best practices explicitly.

Address and fix GitHub pull request review comments on the FiveTwoFive WordPress site (incl. Codex bot reviews). Use whenever the user shares a PR URL or says "address the comments", "review the PR", "fix the feedback", "resolve the review", "handle the Codex comments", "address any open comments", or pastes a PR URL with "fix this PR" / "take care of the comments". Handles the full loop: fetch comments → verify each against code → fix or rebut → rebuild assets → commit + push → reply + resolve each thread → recheck for the reviewer's follow-up.

Creates a properly-named git branch before starting any new work on the FiveTwoFive WordPress site. Use this skill at the start of every coding session, feature, bug fix, or task. Trigger whenever the user mentions starting something new, working on an issue, fixing a bug, or any time work is about to begin and no feature branch has been created yet. If the user jumps straight into making changes without creating a branch first, pause and run this skill before proceeding. Phrases like "let's work on X", "can you fix Y", "start on issue #Z", or "I want to add A" are all signals to run this skill first.

Opens a GitHub pull request for the FiveTwoFive WordPress site with a structured, reviewable body. Use this skill whenever the user says "open a PR", "create the PR", "push and open a PR", "ship it", or anytime work is committed and pushed to a working branch but the PR hasn't been opened yet. Also invoke automatically as the final step of `/ftf-commit-feature` after a successful push. Produces a PR description in the standard four-section shape (Summary / Decisions baked in / Test plan / Follow-ups) with checkbox-formatted verification steps.

Returns the local FiveTwoFive repo to a verifiably clean state on the latest `master` before starting the next task. Use after a PR is merged, when switching context between tasks, or any time you want to confirm `master` is up to date and stale local branches are cleaned up. Trigger phrases include "sync master", "clean up", "back to master", "fresh start", "start the next thing", "we just deployed", "PR is merged what's next", or any signal that the previous unit of work is finished and a new one is about to begin. This skill does NOT create a branch — chain to `/ftf-new-branch` when ready to start work.