B. Quality, Speed & Resilience · Prompt 15

Mobile Layout & Responsive Testing

Get the free PDF

Why it matters

A layout that looks finished on a laptop can be unusable on a phone, which is where many first visits happen.

Modeled on

Browser device emulation and Lighthouse mobile audits.

How to run this prompt

Switch to a mode that does not edit files. In Cursor that is Ask or Plan. In Claude Code that is Plan mode.
Paste the audit prompt. Wait for the report. It must stop and ask which IDs to fix.
Read the report. Keep the IDs you agree with.
Switch to a mode that can edit. Paste the fix prompt and the IDs you chose.
Switch back to the read-only mode and paste the same audit prompt again. Confirm those IDs are gone.

Cursor: audit in Ask mode or Plan mode. Fix in Agent mode.
Claude Code: audit in Plan mode (Shift+Tab cycles to it). Fix in Normal mode, which can edit.
Any other tool: audit in Chat, Discuss, or Plan mode, whichever answers without editing files. If the tool has no such mode, the prompt itself forbids edits. Fix in the mode that is allowed to edit files.

The audit prompt

MODE: AUDIT ONLY. Do not create, edit, or delete any file. Do not run commands
that change anything: no installs, migrations, git commits, deploys, or "--fix" flags.
If your tool has an Ask, Plan, Chat, or Discuss mode, use it for this prompt.

Before you start:
- Tell me the stack you detect (framework, language, database, auth, hosting,
  payment provider) and which folders you will review.
- If a check below does not apply to this stack, write "Not applicable" and why.
- If you can run read-only commands, run the ones listed. If you cannot, list them
  so I can run them and paste the output.

Mobile Layout & Responsive Testing: what to check
Review layouts for phones and tablets from the code and styles. If you can open the app, also look at 320, 360, 390, 768, 1024, and 1440. If you cannot, say which screens I should check.
1. Confirm a viewport meta tag exists and that layout uses flexible widths, not a fixed page width that forces sideways scrolling.
2. Flag horizontal overflow, overlapping elements, cut-off text, and images wider than their container. Name the component.
3. Check tap targets. WCAG 2.2 AA asks for at least 24 by 24 CSS pixels. 44 by 44 is a stricter AAA target and Apple's Human Interface Guidelines recommendation. Flag controls smaller than 24px, and hover-only actions with no tap equivalent.
4. Check mobile forms: input types (email, tel, number), autocomplete attributes, labels that stay visible, and whether a sticky bar can cover the submit button when the keyboard is open.
5. Check fixed headers and bottom bars against notches and safe-area insets. A bar that covers the last button is a bug.
6. Check base font size and line length. Text should be readable without pinch zoom, and not only inside an image.
7. Check tables, code blocks, and wide content. They should scroll inside their own box, not stretch the page.
8. Say what to recheck in landscape and at 200% browser zoom. If you did not render the page, mark those Needs manual check.

Evidence rules:
- Every finding cites a file path and line number, or the exact command output used.
- Mark each finding Confirmed (seen in the code) or Needs manual check (depends on
  something outside the repo, such as a dashboard setting or production data).
- Never print a full secret. Show the first 4 characters and the location only.
- If you are not sure, say so. Do not invent files, settings, or results.

Severity: Critical = exploitable now, or leaks real data or money. High = serious
with little effort. Medium = weakens defenses or needs a second bug. Low = hygiene.

Report:
- Summary: count of findings by severity.
- Table: ID | Severity | Confirmed? | Finding | Evidence | Why it matters | Suggested fix | Effort
  (IDs for this prompt use the prefix P15, for example P15-1, P15-2.)
- Checked and fine: what you verified is already OK.
- Could not check: what I need to look at myself, and where.

Then stop. Do not fix anything. Ask me which IDs I want fixed.

Get the free PDF

Related prompts

Share this prompt

WhatsApp LinkedIn X

How to run this prompt

Switch to a mode that does not edit files. In Cursor that is Ask or Plan. In Claude Code that is Plan mode.

Paste the audit prompt. Wait for the report. It must stop and ask which IDs to fix.

Read the report. Keep the IDs you agree with.

Switch to a mode that can edit. Paste the fix prompt and the IDs you chose.

Switch back to the read-only mode and paste the same audit prompt again. Confirm those IDs are gone.

Cursor: audit in Ask mode or Plan mode. Fix in Agent mode.

Claude Code: audit in Plan mode (Shift+Tab cycles to it). Fix in Normal mode, which can edit.

Any other tool: audit in Chat, Discuss, or Plan mode, whichever answers without editing files. If the tool has no such mode, the prompt itself forbids edits. Fix in the mode that is allowed to edit files.

The audit prompt

MODE: AUDIT ONLY. Do not create, edit, or delete any file. Do not run commands that change anything: no installs, migrations, git commits, deploys, or "--fix" flags. If your tool has an Ask, Plan, Chat, or Discuss mode, use it for this prompt. Before you start: - Tell me the stack you detect (framework, language, database, auth, hosting, payment provider) and which folders you will review. - If a check below does not apply to this stack, write "Not applicable" and why. - If you can run read-only commands, run the ones listed. If you cannot, list them so I can run them and paste the output. Mobile Layout & Responsive Testing: what to check Review layouts for phones and tablets from the code and styles. If you can open the app, also look at 320, 360, 390, 768, 1024, and 1440. If you cannot, say which screens I should check. 1. Confirm a viewport meta tag exists and that layout uses flexible widths, not a fixed page width that forces sideways scrolling. 2. Flag horizontal overflow, overlapping elements, cut-off text, and images wider than their container. Name the component. 3. Check tap targets. WCAG 2.2 AA asks for at least 24 by 24 CSS pixels. 44 by 44 is a stricter AAA target and Apple's Human Interface Guidelines recommendation. Flag controls smaller than 24px, and hover-only actions with no tap equivalent. 4. Check mobile forms: input types (email, tel, number), autocomplete attributes, labels that stay visible, and whether a sticky bar can cover the submit button when the keyboard is open. 5. Check fixed headers and bottom bars against notches and safe-area insets. A bar that covers the last button is a bug. 6. Check base font size and line length. Text should be readable without pinch zoom, and not only inside an image. 7. Check tables, code blocks, and wide content. They should scroll inside their own box, not stretch the page. 8. Say what to recheck in landscape and at 200% browser zoom. If you did not render the page, mark those Needs manual check. Evidence rules: - Every finding cites a file path and line number, or the exact command output used. - Mark each finding Confirmed (seen in the code) or Needs manual check (depends on something outside the repo, such as a dashboard setting or production data). - Never print a full secret. Show the first 4 characters and the location only. - If you are not sure, say so. Do not invent files, settings, or results. Severity: Critical = exploitable now, or leaks real data or money. High = serious with little effort. Medium = weakens defenses or needs a second bug. Low = hygiene. Report: - Summary: count of findings by severity. - Table: ID | Severity | Confirmed? | Finding | Evidence | Why it matters | Suggested fix | Effort (IDs for this prompt use the prefix P15, for example P15-1, P15-2.) - Checked and fine: what you verified is already OK. - Could not check: what I need to look at myself, and where. Then stop. Do not fix anything. Ask me which IDs I want fixed.