The product on a phone — whether layouts, touch targets, and performance hold up on small screens and real devices, or quietly assume a desktop.
Free & open · no signup · read-only — it ends by asking · nothing leaves your machine
You are working inside this repo. Mission: judge the product on a phone — narrow screens, thumbs, and a slow network — and find where a desktop-first design breaks down for the users who arrive on mobile.
Read-only pass. Drive the UI at mobile widths, read the responsive styles; change nothing but the report file.
Phase 2 sweeps the codebase through every one of these, citing file and line for each finding.
reflow at small widths; horizontal scroll, clipped content, broken grids
tap sizes and spacing; controls too small or too close for a thumb
right input types; hover-only interactions with no touch equivalent
font sizes, line length, and spacing that work handheld
notches, safe-area insets, orientation changes, the viewport meta
weight and jank on a mid-tier phone and a slow connection
momentum, sticky headers, and gestures that feel broken versus expected
One structured report at the repo root — or in reports/, if you keep one — the same shape every time, ready for a teammate — or the optional Studio — to act on.
Every Goal Prompt follows the same four steps, so results are consistent and repeatable — no matter which one you run.
Open the core flows at a phone width and interact with a thumb, not a mouse.
Cite the breakpoint and screen for every finding.
Rank by how completely each blocks a phone user on a core flow.
Create MOBILE.md at repo root.
Copy it and paste it into your agent inside the repo you want checked.
Install the goal plugin once — two commands — then just type /goal:mobile-responsive.
/plugin marketplace add GhostlyGawd/goal-prompts/plugin install goal@goal-promptsOr install only this Goal Prompt as /goal-mobile-responsive:
curl -fsSL https://goal-prompts.vercel.app/install | BRIEF=104 shLet an agent fetch it mid-conversation, or pull the raw Goal Prompt by URL.
https://goal-prompts.vercel.app/raw/104.mdNothing hidden — this is the whole Goal Prompt, verbatim. Read it in a minute, edit it, or copy it as-is.
# Goal: Mobile & Responsive Audit You are working inside this repo. Mission: judge the product on a phone — narrow screens, thumbs, and a slow network — and find where a desktop-first design breaks down for the users who arrive on mobile. Read-only pass. Drive the UI at mobile widths, read the responsive styles; change nothing but the report file. ## Phase 1 — Walk it on a phone - Open the core flows at a phone width and interact with a thumb, not a mouse. - Note where layouts break, controls are hard to hit, or the page fights the device. - Check a mid-tier phone profile and a throttled network if you can. ## Phase 2 — Audit through 7 lenses Cite the breakpoint and screen for every finding. 1. **Breakpoints & layout** — reflow at small widths; horizontal scroll, clipped content, broken grids 2. **Touch targets** — tap sizes and spacing; controls too small or too close for a thumb 3. **Input & interaction** — right input types; hover-only interactions with no touch equivalent 4. **Readable type & density** — font sizes, line length, and spacing that work handheld 5. **Viewport & safe areas** — notches, safe-area insets, orientation changes, the viewport meta 6. **Mobile performance** — weight and jank on a mid-tier phone and a slow connection 7. **Native feel** — momentum, sticky headers, and gestures that feel broken versus expected ## Phase 3 — Curate - Rank by how completely each blocks a phone user on a core flow. - For each, name the fix and the breakpoint it applies to. - Separate "broken on mobile" from "not optimized"; fix broken first. ## Phase 4 — Report Create `MOBILE.md` at repo root: 1. **Flow walk** — each core flow on a phone, where it breaks, and how badly 2. **Findings** — each: lens · breakpoint/screen · what a phone user hits · the fix 3. **Blocking issues** — the ones that stop the task on mobile, first 4. **Polish** — the touch, type, and native-feel refinements after the blockers Start the report with today's date. If `MOBILE.md` already exists from a previous run, read it first and lead with what changed since. ## Rules - Test with a thumb on a narrow screen, not a resized desktop window - A tap target too small to hit is a broken feature, not a nitpick - No user interface in this repo? Say so in a one-paragraph null report and stop — a null result is a valid finding. - If a `reports/` directory exists at the repo root, write the report there instead of the root. - Before asking, present the top findings as a ranked list in plain words - Report only — end by asking which mobile issues to fix first
reports/ directory exists at the repo root, write the report there instead of the root.Where the eye actually goes versus where it should — focal points, size and weight and contrast doing real work, and the screens where everything shouts at once.
The type scale, or the lack of one — sizes, weights, line lengths and heights, font loading, and every place text is asked to do a job at the wrong size.
The palette as it actually ships — every hex in the codebase, contrast ratios computed, semantic drift named, and whether dark mode is a theme or an apology.
The spacing scale nobody wrote down — margins and paddings inventoried, grid discipline checked, alignment breaks found, and density judged screen by screen.
Runs inside these playbooks — curated sequences you can launch with one paste: