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.mdCODEX.mdAGENTS.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:
- Which file was created or updated
- The exact browser-verification rule added
- Whether any existing instructions were preserved
- How future Claude/Codex/Cursor agents should follow this rule
- 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.