Prompt for Antigravity

OUTCOME: [user-visible behaviour] works in the running app at [URL/port].

ENVIRONMENT
- Start the app with `[command]`, it serves on [port].
- Test account: [credentials source — never a real secret in the prompt].
- Seed data: `[command]` if the database is empty.
- Feature flag: [name] must be [on/off].

IMPLEMENT
- [Requirement 1]
- [Requirement 2]
- Edge cases: [empty state], [validation failure], [slow network]

BOUNDARIES
- Only modify files under [paths].
- Do not touch [migrations / generated code / third-party config].
- No new dependencies without asking first.

VERIFY (all of these before reporting done)
1. `[build]`, `[lint]`, `[test]` pass.
2. In the browser: [step-by-step user journey], confirming [expected result at each step].
3. Check at 360px width and confirm no layout overflow.
4. Confirm the browser console has no new errors.

REPORT BACK
- A short plan before you start.
- What changed, by file, and why.
- Screenshots of the verified journey.
- Anything you could not verify, stated plainly.

STOP AND ASK IF: the change requires a schema migration, a new dependency, or touching [sensitive area].

BUG: [what users see] — expected [correct behaviour].

REPRODUCE
1. Run the app with `[command]`.
2. [Step], [step], [step].
3. Observe [wrong behaviour].

EVIDENCE
"""
[paste error output, console log or failing test]
"""

TASK
1. Reproduce it first and confirm you have seen the failure. Report what you observed.
2. Diagnose the root cause and name the specific line before proposing a fix.
3. Add a regression test that fails on the current code.
4. Apply the smallest fix that makes it pass.
5. Re-run the reproduction steps in the browser to confirm.

CONSTRAINTS
- Minimal diff. No refactoring around the fix.
- If the root cause sits in [area I care about], stop and explain before changing it.
- Report other defects you notice rather than fixing them.

TASK: Upgrade [dependency] from [current version] to [target version] in this repository.

BEFORE CHANGING ANYTHING
1. Inventory every usage, grouped by the API involved, with file references.
2. Read the upstream changelog and list the breaking changes that actually affect us.
3. Give me a step plan ordered by risk, lowest first.

THEN, ONE STEP AT A TIME
- Apply the step, run `[test command]`, and report the result before continuing.
- If a step needs an API change with no direct equivalent, stop and ask.

CONSTRAINTS
- No unrelated formatting or version bumps.
- Keep behaviour identical; note anything that cannot stay identical.
- Do not touch lockfiles for other packages.

DONE MEANS: build, lint and full test suite pass, and the app runs and serves [key page] correctly in the browser.

Review [page] of the running app for responsive and accessibility issues.

SETUP: start with `[command]`, page is at [URL]. Log in as [test account source] if needed.

CHECK AT THESE WIDTHS: 360px, 480px, 768px, 1024px, 1440px.

FOR EACH WIDTH REPORT
- Horizontal overflow or clipped content.
- Text that wraps badly or drops below 14px effective size.
- Touch targets under 44px.
- Images without dimensions causing layout shift.
- Navigation usability, including whether the mobile menu opens and closes.

ALSO CHECK
- Keyboard-only navigation: focus order, visible focus, no traps.
- Whether every interactive element has an accessible name.
- Console errors and failed network requests.

REPORT: a table of issue, width, severity, location, suggested fix, with a screenshot per issue. Say clearly which items need manual testing with assistive technology rather than being verifiable from the browser alone.