30 Claude Prompts for Frontend Developers

You are an accessibility specialist who tests components with real screen readers before signing off on them. <context> I built a component and I am not confident it announces correctly to screen reader users, and I want a review before it ships. </context> <inputs> - Component code: [PASTE COMPONENT MARKUP AND JS] - Screen readers used in QA: [VOICEOVER, NVDA, JAWS] - Component purpose: [SHORT DESCRIPTION, E.G. DROPDOWN MENU] </inputs> <task> Review the markup for missing or incorrect semantics, and describe exactly what a screen reader user would hear at each interaction step. </task> <constraints> Base findings only on standard accessibility APIs, not assumptions about a specific screen reader's quirks, cite the relevant WAI-ARIA pattern if one exists for this component type, and separate blocking issues from minor improvements. </constraints> <format> Return a table with columns issue, why it matters, and fix, ordered from blocking to minor, followed by the corrected markup. </format>

You are a frontend accessibility engineer who specializes in keyboard interaction patterns. <context> Users who navigate by keyboard have reported that they get stuck or cannot reach certain controls in a widget I own, and I need to fix the tab order and key handling. </context> <inputs> - Widget code: [PASTE COMPONENT CODE] - Reported problem: [DESCRIBE WHAT THE USER COULD NOT DO] - Expected keys: [TAB, ARROW KEYS, ESCAPE, ENTER] </inputs> <task> Identify every place the tab order or key handling breaks expected behavior, and rewrite the code so keyboard users can complete the same actions mouse users can. </task> <constraints> Follow the standard keyboard pattern for this widget type from the WAI-ARIA Authoring Practices, do not trap focus unless the widget is a modal, and preserve all existing mouse behavior. </constraints> <format> Return a short list of what was broken, then the corrected code with comments marking each keyboard handling change. </format>

You are an accessibility engineer who writes ARIA attributes for complex interactive widgets. <context> I have a custom widget that has no native HTML equivalent, and I need correct ARIA roles, states, and labels so assistive technology understands it. </context> <inputs> - Widget markup: [PASTE HTML STRUCTURE] - Widget behavior: [DESCRIBE WHAT IT DOES, E.G. MULTI SELECT COMBOBOX] - Dynamic states: [LIST STATES THAT CHANGE, E.G. EXPANDED, SELECTED, LOADING] </inputs> <task> Add the correct ARIA roles, states, and properties to the markup, and explain what each one communicates to assistive technology. </task> <constraints> Use native HTML elements and attributes wherever possible instead of ARIA, only add ARIA where no native equivalent exists, and keep all dynamic states updated through actual attribute changes, not just visual styling. </constraints> <format> Return the updated markup with inline comments explaining each ARIA attribute, followed by a short note on which JavaScript events must update which attributes. </format>

You are an accessibility auditor who reviews visual designs against WCAG contrast requirements. <context> I am about to ship a new UI and I want to confirm the text and interactive elements meet contrast requirements before a designer signs off. </context> <inputs> - Color pairs to check: [LIST FOREGROUND AND BACKGROUND HEX PAIRS] - Text sizes involved: [LIST FONT SIZES AND WEIGHTS] - Target conformance level: [WCAG AA OR AAA] </inputs> <task> Calculate the contrast ratio for each color pair, state whether it passes the target conformance level for its text size, and suggest an adjusted color for any pair that fails. </task> <constraints> Use the WCAG contrast ratio formula, treat large text and normal text thresholds separately, and keep suggested color adjustments close to the original brand color rather than replacing it entirely. </constraints> <format> Return a table with columns color pair, ratio, pass or fail, and suggested fix if needed. </format>

You are a frontend engineer who specializes in accessible form design. <context> Our current form only shows validation errors as red text near the field, and screen reader users are not being told an error happened at all, so I need to redesign the validation flow. </context> <inputs> - Form fields: [LIST FIELD NAMES AND TYPES] - Current validation code: [PASTE EXISTING VALIDATION LOGIC] - Framework: [REACT, VUE, PLAIN HTML AND JS] </inputs> <task> Design an accessible validation flow that announces errors to screen readers, associates error text with its field, and moves focus appropriately on submit. </task> <constraints> Do not rely on color alone to indicate an error, use aria-live regions or aria-describedby correctly rather than both in conflicting ways, and keep the error messages specific enough that a user knows how to fix the field. </constraints> <format> Return the updated form code, then a short list explaining which accessibility technique solves which part of the original problem. </format>

You are a frontend performance engineer who sets and enforces performance budgets. <context> We are building a new page and I want to define a performance budget up front so the team has a target instead of fixing problems after launch. </context> <inputs> - Page type: [LANDING PAGE, DASHBOARD, CHECKOUT] - Target device profile: [LOW END MOBILE, TYPICAL LAPTOP] - Business goal for the page: [DESCRIBE, E.G. SIGNUP CONVERSION] - Current similar page metrics if any: [LCP, TBT, BUNDLE SIZE NUMBERS] </inputs> <task> Propose a performance budget for this page covering load time metrics and asset size limits, and explain why each threshold was chosen. </task> <constraints> Base thresholds on the stated device profile, not a generic best case, tie each metric to a user facing consequence rather than an abstract score, and keep the total number of tracked metrics to five or fewer so the team can actually monitor them. </constraints> <format> Return a table with columns metric, budget, and reason, followed by a short paragraph on how to monitor these in CI. </format>

You are a web performance engineer who diagnoses rendering bottlenecks. <context> A page I own has a slow first contentful paint according to real user monitoring, and I need to find the likely cause before I start changing code. </context> <inputs> - Waterfall or trace summary: [PASTE KEY REQUEST TIMINGS OR DESCRIBE THEM] - Current FCP value: [NUMBER IN SECONDS] - Rendering approach: [SERVER RENDERED, CLIENT RENDERED, STATIC] - Known render blocking resources: [LIST SCRIPTS OR STYLESHEETS IN HEAD] </inputs> <task> Analyze the likely causes of the slow first contentful paint based on the given data, and rank them by probable impact. </task> <constraints> Do not suggest a fix that is not supported by the data provided, distinguish between server response time issues and render blocking resource issues, and note if more data would be needed to confirm a suspected cause. </constraints> <format> Return a ranked list of likely causes with the supporting evidence for each, followed by the single highest impact fix to try first. </format>

You are a frontend architect who plans bundle splitting for large single page applications. <context> Our main JavaScript bundle has grown too large and users on slow connections wait too long before the app is interactive, so I need a code splitting plan. </context> <inputs> - Framework and bundler: [REACT WITH WEBPACK, VUE WITH VITE, ETC] - Current bundle size: [SIZE IN KB] - Route or feature list: [LIST MAIN ROUTES OR FEATURES] - Which features are used by most users vs rarely: [DESCRIBE USAGE PATTERNS] </inputs> <task> Propose a code splitting plan that separates rarely used features from the main bundle, including which routes should lazy load and which shared code should stay in the main chunk. </task> <constraints> Do not split so aggressively that common navigation triggers many small network requests, account for the given usage patterns rather than splitting purely by route, and flag any shared dependency that would end up duplicated across chunks. </constraints> <format> Return a proposed chunk structure as a list, with each chunk's contents and the reason it was grouped that way. </format>

You are a frontend engineer focused on JavaScript bundle size reduction. <context> A specific feature in our app is adding more to the bundle than expected, and I want to find what can be trimmed without removing functionality. </context> <inputs> - Feature code or import list: [PASTE IMPORTS OR KEY CODE] - Bundle analyzer output: [PASTE RELEVANT SIZE NUMBERS] - Dependencies used: [LIST LIBRARY NAMES AND VERSIONS] </inputs> <task> Identify which imports or dependencies contribute the most to this feature's size, and suggest lighter alternatives or partial import strategies for each. </task> <constraints> Only suggest a replacement library if it covers the same functionality currently used, note any dependency that could be replaced with a small amount of custom code instead, and flag any import that is pulling in the whole library instead of a single function. </constraints> <format> Return a table with columns dependency, current size impact, suggested fix, and estimated savings. </format>

You are a frontend performance engineer who specializes in image delivery. <context> Images are a large share of our page weight and I want a loading strategy that improves perceived speed without hurting image quality. </context> <inputs> - Page type: [PRODUCT GALLERY, BLOG POST, DASHBOARD] - Current image setup: [FORMAT, SIZES, WHETHER LAZY LOADED] - Hosting or CDN: [NAME OF IMAGE CDN OR HOSTING SETUP] - Largest contentful paint element: [DESCRIBE IF IT IS AN IMAGE] </inputs> <task> Propose an image loading strategy covering format choice, responsive sizing, and lazy loading, tailored to this page type. </task> <constraints> If the largest contentful paint element is an image, it must not be lazy loaded, specify concrete width and format targets rather than general advice, and account for the stated CDN's actual capabilities rather than assuming features it may not support. </constraints> <format> Return a short strategy summary, then a table of image types on the page with format, sizing, and loading attribute recommendations for each. </format>

You are a frontend architect who has shipped and maintained several large scale CSS systems. <context> We are starting a new project and I need to decide between CSS modules, a utility framework, and CSS in JS before the team writes the first component. </context> <inputs> - Team size: [NUMBER OF DEVELOPERS] - Team CSS experience level: [BEGINNER, MIXED, EXPERT] - Framework: [REACT, VUE, ANGULAR, SVELTE] - Project type: [MARKETING SITE, INTERNAL TOOL, CONSUMER APP] </inputs> <task> Recommend a CSS architecture for this project, and explain the tradeoffs against the two next best options given the team's size and experience. </task> <constraints> Weigh long term maintenance cost as much as initial setup speed, name specific risks for a team with the stated experience level, and avoid recommending a solution just because it is currently popular. </constraints> <format> Return a short recommendation paragraph, a comparison table of the three options, and a minimal starter file structure for the chosen approach. </format>

You are a senior frontend engineer who specializes in incremental CSS refactors. <context> Our stylesheet has grown into a tangle of overrides and duplicate rules over several years, and I need a plan to migrate it to a cleaner system without a full rewrite. </context> <inputs> - Current stylesheet sample: [PASTE A REPRESENTATIVE SECTION OF CSS] - Target architecture: [CSS MODULES, UTILITY CLASSES, BEM] - Constraints on rewrite time: [DESCRIBE HOW MUCH TIME IS AVAILABLE] - Pages that cannot break: [LIST HIGH TRAFFIC OR REVENUE PAGES] </inputs> <task> Propose a phased migration plan from the current CSS to the target architecture, prioritizing low risk sections first and isolating the pages that cannot break. </task> <constraints> Do not propose a big bang rewrite, keep each phase small enough to ship and verify independently, and call out any global selector in the sample that will be risky to touch. </constraints> <format> Return a numbered list of migration phases, each with scope, risk level, and a rollback approach if something breaks. </format>

You are a frontend engineer who specializes in responsive layout systems. <context> I am building a page layout that needs to work across phone, tablet, and desktop widths, and I want a consistent grid approach rather than one off breakpoints per component. </context> <inputs> - Page sections: [LIST MAIN SECTIONS, E.G. HEADER, SIDEBAR, CARD GRID] - Breakpoints currently used: [LIST PIXEL VALUES IF ANY EXIST] - CSS approach: [CSS GRID, FLEXBOX, UTILITY FRAMEWORK] - Content that must reflow: [DESCRIBE ANY TRICKY CONTENT, E.G. LONG TABLES] </inputs> <task> Design a grid layout strategy for this page that defines consistent breakpoints and explains how each section reflows at each width. </task> <constraints> Use a small, consistent set of breakpoints rather than one per component, prefer intrinsic sizing techniques over fixed pixel breakpoints where possible, and address how the tricky content will reflow specifically. </constraints> <format> Return a breakpoint table, then a short description of the layout behavior for each page section at each breakpoint, then example CSS for the grid container. </format>

You are a frontend engineer who has implemented theming systems for production products. <context> We need to add a dark mode to our product and our current styles use hardcoded colors throughout, so I need a plan to introduce theming without rewriting every component at once. </context> <inputs> - CSS approach: [CSS VARIABLES, CSS IN JS, UTILITY FRAMEWORK] - Current color usage: [DESCRIBE HOW COLORS ARE DEFINED TODAY] - Components with the most hardcoded colors: [LIST COMPONENT NAMES] - Theme switching requirement: [SYSTEM PREFERENCE, MANUAL TOGGLE, BOTH] </inputs> <task> Propose a theming plan that introduces semantic color variables, supports the stated switching requirement, and prioritizes which components to migrate first. </task> <constraints> Do not require a full rewrite before dark mode can ship for any component, ensure the switching mechanism does not cause a flash of the wrong theme on load, and keep semantic variable names tied to purpose rather than to light or dark specifically. </constraints> <format> Return the proposed variable structure, the switching mechanism explained in a short paragraph, and a prioritized migration order for components. </format>

You are a frontend engineer who debugs CSS specificity and cascade issues. <context> A style is not applying the way I expect on a page and I suspect a specificity or cascade order conflict rather than a typo, and I want a clear diagnosis before changing anything. </context> <inputs> - Relevant CSS rules: [PASTE THE COMPETING CSS RULES] - HTML structure affected: [PASTE THE RELEVANT MARKUP] - Expected style: [DESCRIBE WHAT SHOULD APPEAR] - Actual style: [DESCRIBE WHAT ACTUALLY APPEARS] </inputs> <task> Calculate the specificity of each competing rule, explain which one wins and why, and propose the smallest possible fix. </task> <constraints> Do not suggest adding an id selector or important as the fix unless there is truly no other option, prefer restructuring selectors or source order over increasing specificity, and explain the cascade order clearly enough that the same bug will not recur. </constraints> <format> Return a short explanation of the specificity calculation for each rule, then the recommended fix as a code diff. </format>

You are a senior frontend engineer who evaluates state management tradeoffs regularly. <context> I am building a new feature and need to decide between local component state, a shared context, or a dedicated state library before writing the data layer. </context> <inputs> - Feature description: [DESCRIBE THE FEATURE] - Data shared across components: [DESCRIBE WHAT DATA MULTIPLE COMPONENTS NEED] - Update frequency: [HOW OFTEN THE DATA CHANGES] - Existing state tools in the app: [REDUX, ZUSTAND, CONTEXT, NONE] </inputs> <task> Recommend a state management approach for this feature specifically, and explain why it fits better than the two next best options given the data sharing and update frequency described. </task> <constraints> Do not recommend introducing a new state library if the existing tools in the app can handle this cleanly, weigh re-render cost for the stated update frequency, and be explicit about when this choice should be revisited as the feature grows. </constraints> <format> Return a short recommendation paragraph, a comparison table of the three options considered, and a minimal code sketch of the chosen approach. </format>

You are a frontend architect who designs application level state stores. <context> Our global store has grown organically and is now hard to reason about, and I want to redesign its shape before adding the next major feature. </context> <inputs> - Current store shape: [PASTE OR DESCRIBE THE CURRENT STATE TREE] - State library: [REDUX, ZUSTAND, PINIA, MOBX] - New feature needing state: [DESCRIBE THE NEW FEATURE] - Known pain points: [DESCRIBE CURRENT ISSUES, E.G. DEEPLY NESTED UPDATES] </inputs> <task> Propose a redesigned store shape that fixes the stated pain points and accommodates the new feature, and explain how updates and selectors change under the new shape. </task> <constraints> Keep normalized data separate from UI only state, avoid deeply nested objects that require multiple spread operations to update, and describe a migration path rather than requiring a rewrite of every reducer or store slice at once. </constraints> <format> Return the proposed store shape as a JSON like structure, then a short migration plan as a numbered list. </format>

You are a frontend engineer who specializes in debugging state synchronization issues. <context> Two parts of my UI show different values for what should be the same piece of state, and I need to find where the state gets out of sync. </context> <inputs> - Relevant state code: [PASTE THE STATE DEFINITION AND UPDATE LOGIC] - Components involved: [LIST THE COMPONENTS SHOWING DIFFERENT VALUES] - Steps to reproduce: [DESCRIBE THE USER ACTIONS THAT CAUSE THE MISMATCH] - State library: [REDUX, CONTEXT, ZUSTAND, LOCAL STATE COPIES] </inputs> <task> Trace through the reproduction steps against the given code, and identify the specific point where the two components stop reflecting the same value. </task> <constraints> Do not guess at a fix without tracing the actual data flow described, distinguish between a stale closure, a missed subscription, and a duplicated local copy of state as possible causes, and confirm which one matches the evidence given. </constraints> <format> Return a step by step trace of the data flow during the reproduction steps, then the identified root cause, then the fix as a code diff. </format>

You are a senior frontend engineer who has cleaned up prop drilling in production codebases. <context> A piece of data is being passed through five or more component layers just to reach one deeply nested component, and I want to remove the prop drilling without breaking the components in between. </context> <inputs> - Component tree involved: [DESCRIBE OR PASTE THE NESTED COMPONENT STRUCTURE] - Data being drilled: [DESCRIBE WHAT DATA IS PASSED DOWN] - Framework: [REACT, VUE, SVELTE] - Components that also use the intermediate props for their own logic: [LIST ANY, IF NONE SAY NONE] </inputs> <task> Propose a plan to introduce context or a similar mechanism that removes the prop drilling, while keeping any intermediate components that use the data for their own logic working correctly. </task> <constraints> Do not wrap the entire application in a new context provider if a narrower scope will do, preserve the existing prop interface for any component that is also used elsewhere with different data, and avoid introducing unnecessary re-renders across the whole tree. </constraints> <format> Return the proposed context structure, a list of which components change and how, and one before and after code example for the deepest component. </format>

You are a frontend engineer who writes tests for state logic before it ships. <context> I have state logic with several transitions and edge cases, and I want thorough tests written before I trust it in production. </context> <inputs> - State logic code: [PASTE THE REDUCER, STORE, OR HOOK CODE] - Testing library: [JEST, VITEST, TESTING LIBRARY] - Known edge cases: [LIST ANY EDGE CASES ALREADY KNOWN] - States possible: [LIST THE POSSIBLE STATE VALUES, E.G. IDLE, LOADING, ERROR, SUCCESS] </inputs> <task> Write tests covering every valid state transition, the listed edge cases, and at least one invalid transition that should be rejected or ignored. </task> <constraints> Test behavior through the public interface rather than internal implementation details, cover the invalid transition case explicitly rather than assuming it cannot happen, and keep each test focused on one transition or edge case. </constraints> <format> Return the test file using [TESTING LIBRARY], with a short comment above each test naming the transition or edge case it covers. </format>

You are a senior frontend engineer doing a thorough code review before approving a pull request. <context> A teammate opened a pull request adding a new component and I want a careful review before I approve it, covering more than just style nitpicks. </context> <inputs> - Diff or component code: [PASTE THE PULL REQUEST DIFF OR FILE] - Component purpose: [DESCRIBE WHAT THE COMPONENT DOES] - Team conventions: [DESCRIBE ANY NAMING OR STRUCTURE CONVENTIONS TO FOLLOW] </inputs> <task> Review the code for correctness, prop API design, accessibility, and test coverage, and separate blocking issues from suggestions. </task> <constraints> Do not comment on formatting that a linter would already catch, back every blocking issue with a specific line or snippet reference, and note if a test is missing for a case the code clearly needs to handle. </constraints> <format> Return two sections, Blocking and Suggestions, each as a bullet list referencing the specific code involved. </format>

You are a senior React engineer reviewing custom hooks for correctness and reuse. <context> A teammate wrote a custom hook and I want to check it for common hook mistakes like stale closures, missing dependencies, and unnecessary re-renders before approving it. </context> <inputs> - Hook code: [PASTE THE CUSTOM HOOK] - Where it is used: [LIST COMPONENTS OR FEATURES USING IT] - React version: [REACT VERSION NUMBER] </inputs> <task> Review the hook for stale closures, incorrect or missing dependency arrays, unnecessary re-renders, and cleanup handling, and explain the impact of each issue found. </task> <constraints> Explain the specific scenario that triggers each bug rather than stating a rule in the abstract, do not flag a missing dependency if omitting it is actually intentional and safe, and note any effect that is missing a cleanup function it needs. </constraints> <format> Return a numbered list of issues, each with the line involved, the triggering scenario, and the suggested fix as a code snippet. </format>

You are a frontend engineer reviewing a CSS change for unintended side effects. <context> A pull request changes shared CSS and I am worried it could affect other pages that use the same classes, so I want a careful review before approving. </context> <inputs> - CSS diff: [PASTE THE CSS CHANGES] - Class names or selectors touched: [LIST THEM] - Pages or components known to use these selectors: [LIST IF KNOWN, OR SAY UNKNOWN] </inputs> <task> Review the diff for changes to shared selectors, identify which other components or pages are likely affected, and flag any change that widens a selector's scope beyond its original use. </task> <constraints> Assume any class name not clearly scoped to one component could be reused elsewhere, recommend scoping the change to a new class if the risk of a shared selector regression is high, and note if visual regression testing should be run before merging. </constraints> <format> Return a risk assessment as high, medium, or low with reasoning, followed by a recommended change if the risk is medium or high. </format>

You are a frontend engineer who checks pull requests for accessibility regressions before they merge. <context> A pull request changes markup or interaction behavior and I want to confirm it has not introduced an accessibility regression before it ships. </context> <inputs> - Diff or changed markup: [PASTE THE RELEVANT MARKUP CHANGES] - What changed functionally: [DESCRIBE WHAT THE PR CHANGES] - Interactive elements affected: [LIST BUTTONS, LINKS, FORM FIELDS INVOLVED] </inputs> <task> Review the changes for lost semantics, removed keyboard support, or broken focus management compared to the likely previous behavior, and state whether the change is safe to merge. </task> <constraints> Compare against the accessibility behavior a reasonable prior version would have had, not an ideal rewrite, be explicit if you cannot tell from the diff alone whether something regressed, and prioritize keyboard and focus issues over minor semantic nitpicks. </constraints> <format> Return a clear verdict of safe to merge, needs changes, or needs manual testing, followed by the specific reasoning. </format>

You are a senior frontend engineer reviewing a change to code that runs on a hot path. <context> A pull request touches code that runs frequently, such as a list render or a scroll handler, and I want to check for performance regressions before approving it. </context> <inputs> - Code diff: [PASTE THE CHANGED CODE] - Where this code runs: [DESCRIBE THE HOT PATH, E.G. RENDERED PER LIST ITEM] - Approximate frequency or scale: [NUMBER OF ITEMS OR CALLS PER SECOND] </inputs> <task> Review the change for new allocations, unnecessary re-renders, or expensive operations introduced on this hot path, and estimate the likely performance impact at the stated scale. </task> <constraints> Base the estimate on the stated frequency or scale rather than a generic statement that something is slow, distinguish between a one time cost and a cost that repeats per item or per call, and suggest a specific alternative for any expensive operation found. </constraints> <format> Return a short impact estimate, then a list of specific lines with the issue and suggested fix for each. </format>