Interface & polish

Here is my page: <paste>

Make it work from 320px wide upwards. Specifically:
- Nothing scrolls sideways at any width.
- Tap targets at least 44px, with space between them.
- Text stays readable without zooming — no fixed pixel font sizes.
- Tables and wide blocks handled deliberately, not just squashed.

Tell me which changes were structural and which were cosmetic, and
what to check by hand on a real phone.

Audit this for accessibility: <paste>

Check, and fix what's broken:
- Can I do everything with only a keyboard? Is focus always visible?
- Real headings in real order, not divs styled to look like headings.
- Labels tied to inputs. Alt text that says something useful.
- Colour contrast at 4.5:1 for body text.
- Anything that changes without a click — is it announced?

List what you fixed, then what still needs a human to test.

Add a dark theme to this: <paste the CSS>

- Pull every colour into CSS custom properties first, then override
  only those properties for dark. Don't duplicate the stylesheet.
- Follow prefers-color-scheme by default.
- Pure black and pure white are both wrong. Say what you used instead.
- Check contrast in both themes, and tell me anything that fails.

Watch for colours hidden in shadows, borders and SVG fills.

This screen currently only handles the case where data exists: <paste>

Add the other three:
- Loading. No layout jump when the content arrives.
- Empty, for a genuinely new user. Say what this screen will show and
  give them the one action that fills it.
- Error. Say what went wrong in human words and offer a way forward.

Write the actual copy for each. Not "Loading..." and "No data".

Here are the messages my app shows when things go wrong: <paste them>

Rewrite each one to answer three questions in one or two sentences:
what happened, why, and what I should do now.

Rules: no error codes as the main text, no blame, no apologising twice,
never expose a stack trace or a database error to a user. If there is
genuinely nothing the user can do, say so and tell them who can.

Here is every piece of text in my interface: <paste>

Tighten it. Rules:
- Buttons say what happens when you press them. Not "Submit" or "OK".
- Cut hedging: "please", "simply", "just", "try to".
- Say "you", not "the user". Say what it does, not what it is.
- Consistent terminology — if it's a "project" once it's a "project"
  everywhere. Flag every place I drifted.

Show old and new side by side so I can reject the ones you overcooked.

My tool does <this>. The moment someone "gets it" is when they
<the payoff>.

Design the shortest path from landing on the page to that moment.
- What is the fewest number of steps? Can any be removed entirely?
- What can I default, guess, or pre-fill instead of asking?
- Where does someone give up, and what do I do about it there?

Tell me which of my current steps exist for my benefit, not theirs.

Add keyboard shortcuts to <describe the app>. The most common actions
are: <list them>

- Follow conventions people already know. Don't reassign Ctrl+S,
  Ctrl+F or Escape to something surprising.
- Never fire while the user is typing in an input, unless it's a
  modifier combination.
- A discoverable list — "?" opens a shortcuts panel — and hints on
  the buttons themselves.
- Escape closes whatever is open, always.
- Work on both platforms: Cmd on Mac, Ctrl elsewhere.

Then tell me which of my actions genuinely deserve a shortcut and
which would just be clutter.

Review this form for usability: <paste>

Check all of:
- Real labels above fields, always visible. Placeholders are not
  labels — they vanish exactly when needed.
- Correct input types and autocomplete attributes, so phones show the
  right keyboard and browsers can fill it in.
- Errors next to the field, in words, on blur — not all at once at
  the top after submitting.
- Typed values survive a failed submit. Losing them is unforgivable.
- Required fields marked, optional ones too if there are few.
- Submit disabled while in flight so a double tap doesn't double post.
- Enter submits.

Then: which fields could I remove entirely, or infer?

Here's my interface: <paste>

Every action should visibly acknowledge itself. Add:
- Immediate press feedback on buttons — within one frame.
- A loading state on anything asynchronous, on the element that was
  clicked, not a full-page overlay.
- A clear success state that lasts long enough to notice.
- Smooth transitions on things that appear and disappear, so nothing
  pops into existence.

Rules: nothing over 200ms, nothing that delays the actual action, and
everything respects prefers-reduced-motion.

Tell me which of my actions currently give no feedback at all.

Here's my modal: <paste>

Make it behave properly:
- Focus moves into it on open, and returns to the trigger on close.
- Focus is trapped inside while open — Tab must not reach the page
  behind.
- Escape closes it. So does clicking the backdrop, unless there's
  unsaved input, in which case confirm.
- The page behind doesn't scroll, and doesn't jump when the
  scrollbar disappears.
- Announced to screen readers as a dialog, with a label.

Consider using the native dialog element rather than building this —
tell me whether it fits my case.

Here's my table: <paste>

Fix the things that make tables unpleasant:
- Horizontal scroll inside the table's own container, so the page
  never scrolls sideways.
- Real table markup with headers — not divs. Screen readers need the
  structure.
- Sortable columns that announce their state, and are operable by
  keyboard.
- A sensible answer for phones: which columns matter, and what
  happens to the rest.
- Sticky header if the table is long.
- An empty state, and a loading state that doesn't collapse the
  layout.

Tell me which columns I could drop entirely — most tables show more
than anyone reads.

I have a long list of <what>, roughly <n> items, and users are trying
to <browse / find something specific / catch up on what's new>.

Recommend infinite scroll, "load more", or numbered pages. Pick one
and defend it against the others for my specific case.

Consider: can someone link to or return to a specific position? Can
they reach the footer? What happens on a slow connection? What happens
when they press back?

Then implement it, including the state in the URL so refreshing and
sharing work.

I need users to reorder <what>: <paste the current markup>

Implement it with:
- Mouse and touch dragging, with a clear drop indicator showing where
  it will land.
- A keyboard alternative — this is mandatory, not optional. Say how it
  works and how a user discovers it.
- Screen reader announcements for pick up, move and drop.
- The new order saved, with the request debounced so dragging three
  items isn't three round trips.
- What happens if the save fails — does the order revert?

Tell me whether a library is worth it here or whether this is small
enough to do directly.

Add print styles to this page: <paste>

- Hide navigation, footers, buttons and anything interactive.
- Full width, black on white, no background colours that eat ink.
- Show link destinations after link text where it's useful.
- Avoid breaking a table row, a heading, or an image across pages.
- Set sensible page margins.

Then tell me what this looks like on A4 and on US Letter, and whether
anything gets cut off.

Review the motion in this: <paste>

Rules I want applied:
- Every animation explains a relationship — where something came
  from, where it went, what changed. Cut anything that's decoration.
- Nothing over 200ms for interface feedback, 300ms for larger
  transitions.
- Ease out for things arriving, ease in for things leaving.
- Animate transform and opacity only. Anything else causes layout
  work and stutters.
- prefers-reduced-motion honoured — and that means removing motion,
  not just shortening it.

Tell me which of my current animations delay the user rather than
informing them.

My site is <one sentence>, built with <stack> and hosted on <host>. Every
page currently repeats its own header and footer.

Create one shared layout, done this stack's usual way:
- A proper document head: title, description, social tags, canonical URL.
- Header with navigation, marking the current page.
- A single main area each page fills in.
- Footer.
- Accessible from the start: a skip link, landmarks, one h1 per page.

Then convert one existing page to use it, and show me the pattern for
the rest.

My site uses <stack> and runs on <host>. Missing pages and errors show
the host's default pages.

Set up:
- A 404 page that matches the site, says what happened, and offers a way
  forward: home, search, popular pages.
- A 500 page that works even when the app itself is broken, so plain HTML
  with no dependencies.
- Both returning the correct status codes, not 200.
- Where this host lets me configure them.

Then tell me how to test each one on the live host.

My site is <stack> on <host>. When I change the CSS, some visitors see
the old version for days.

Set up assets properly, without adding a build tool:
- A version in each asset URL that changes when the file changes.
- Long cache lifetimes for those assets, and none for HTML.
- Images sized for how they're displayed, with width and height set.
- Loading scripts so they don't block the page.

Give me the configuration for this host and the change to my templates.