Introduction

Use this prompt when you want to add strict browser-verification rules to CLAUDE.md, AGENTS.md, CODEX.md, .cursor/rules, or any project instruction file. The goal is to stop AI coding agents from claiming frontend work is “done” based only on source-code inspection.

For any UI, layout, responsive, CSS, JavaScript, routing, browser, or frontend-related task, the agent must verify the result in a real browser using Playwright, Chromium, browser devtools, screenshots, console logs, network checks, or any available browser automation tool. If browser verification is not possible, the agent must clearly say so instead of pretending the work was tested.

Powerful Prompt

You are working on this project as a senior frontend engineer, QA engineer, and AI coding agent.

Your task is to add strict browser-verification rules to this project so future UI, frontend, CSS, JavaScript, responsive, and browser-related work is not marked complete without real browser evidence.

Goal

Tool setup alone is not enough. This project needs written rules that force every AI coding agent to verify browser behavior before saying a task is complete.

Add or update the most appropriate project instruction file:

• CLAUDE.md
• CODEX.md
• AGENTS.md
• .cursor/rules
• or any equivalent AI-agent instruction file already used by this project.

If none exists, create:

AGENTS.md

Add This Section

Add the following section clearly and prominently:

# Browser Verification Rule

For any UI, layout, frontend, responsive, CSS, JavaScript, routing, browser, or visual-design-related task, browser verification is mandatory.

AI agents must not rely only on source-code reading. Source-code inspection is useful, but it is not proof that the browser works correctly.

## Required Verification

Before saying a frontend/browser task is complete, verify the result using Playwright, Chromium, browser devtools, screenshots, browser automation, Jam.dev evidence, or any available browser-verification tool.

At minimum, check:

1. Desktop screenshot
   - 1440x900 or similar desktop viewport

2. Tablet screenshot
   - 768x1024 or similar tablet viewport

3. Mobile screenshot
   - 390x844 or similar mobile viewport

4. Browser console errors
   - JavaScript errors
   - Runtime exceptions
   - Hydration errors
   - Framework errors

5. Failed network requests
   - Failed API calls
   - 4xx responses
   - 5xx responses
   - Missing assets
   - CORS failures

6. Page rendering behavior
   - Broken layout
   - Overflow issues
   - Missing content
   - Broken images
   - Incorrect spacing
   - Hidden or overlapping elements

7. DOM/CSS inspection when layout is broken
   - Applied styles
   - Responsive classes
   - Container width
   - z-index
   - display/flex/grid behavior
   - overflow and positioning

## Completion Rule

Do not say:

- "done"
- "fixed"
- "verified"
- "tested"
- "working"
- "complete"

unless browser verification was actually performed.

## Required Final Response for UI Tasks

For every frontend/browser-related task, the final response must include:

1. What was changed
2. What browser/page was tested
3. Which viewport sizes were tested
4. Whether screenshots were checked
5. Whether console errors were checked
6. Whether failed network requests were checked
7. Any remaining issue or limitation
8. If browser verification was not possible, a clear explanation of why

## If Browser Access Is Unavailable

If browser tools are unavailable, say clearly:

"Browser verification was not performed because browser access/tools are unavailable in this environment."

Then provide the exact command or workflow the user should run locally, such as:

```bash
python tools/browser_check.py --url http://127.0.0.1:3000

or:

npx playwright test

Never pretend browser verification happened.

Recommended Browser Evidence

When possible, generate or inspect:

• Desktop screenshot
• Tablet screenshot
• Mobile screenshot
• Console logs
• Runtime errors
• Failed network requests
• HTTP error responses
• Lighthouse/PageSpeed report for public pages
• Jam.dev or browser bug-report link for visual/user-action issues
• Playwright report for local/private pages

Local Development Preference

For local development, prefer:

Python + Playwright + Chromium

or project-native Playwright tests.

Use http://127.0.0.1 instead of localhost when possible, because it is often more reliable across browser automation environments.

Public Website Preference

For public pages, browser evidence may include:

• WebPageTest report
• PageSpeed Insights report
• Lighthouse report
• GTmetrix report
• DebugBear report
• Jam.dev bug report
• BrowserStack Bug Capture report

Private or Logged-In Page Preference

For private, logged-in, staging, Keycloak-protected, admin, dashboard, or local pages, prefer:

• Local Playwright verification
• Chromium browser automation
• Jam.dev capture using a safe test account
• BrowserStack Bug Capture using a safe test account

Do not use real customer, patient, payment, production, or sensitive data in shared browser reports.

Security Rule

Browser reports may contain sensitive data such as:

• API URLs
• Console logs
• Network responses
• Headers
• User information
• Auth redirects
• Internal route names
• Error payloads

Use test users, staging data, and safe environments whenever possible.
Do not expose secrets, tokens, private medical data, customer data, or production admin data in shared reports.

## Also Add a Short Reminder Near the Top

If the instruction file already has a project overview, add this short reminder near the top:

```md
Important: For frontend, UI, layout, responsive, CSS, JavaScript, and browser-related work, do not mark the task complete unless real browser verification was performed or the limitation was clearly stated.

Final Response Format

After updating the file, respond with:

1. Which file was created or updated
2. The exact browser-verification rule added
3. Whether any existing instructions were preserved
4. How future Claude/Codex/Cursor agents should follow this rule
5. Any recommended next step, such as adding a Playwright browser-check script

Important

Do not remove existing project instructions.
Do not weaken the rule.
Do not make browser verification optional for frontend work.
Do not claim browser testing was performed unless it actually happened.