browser-test-loop
Skill378 starsChanged 52 days agoMITView on GitHub
Use to actually verify a web change in a real browser instead of assuming it works — click through a flow, catch console errors, check a form submits, confirm a fix on the page. Trigger when a UI change needs proof, a bug only reproduces in the browser, or the user asks to test, check, or screenshot the running app.
- Installs packages
In this repository229 other files it gives its agents.
- accessibility-auditorSkill
- agent-armySkill
- agent-eval-harnessSkill
- agent-swarm-deployerSkill
- agent-team-builderSkill
- agent-to-agentSkill
- ai-coding-guardrailsSkill
- ai-readiness-assessmentSkill
- animateSkill
- api-documentation-writerSkill
- api-endpoint-scaffolderSkill
- api-load-testerSkill
- athlete-social-media-managerSkill
- before-you-buildSkill
- bi-measure-builderSkill
- board-deck-generatorSkill
- bookkeeping-closeSkill
- bracket-predictorSkill
- brand-consistency-checkerSkill
- brand-voice-analyzerSkill
- budget-optimizerSkill
- cash-flow-forecasterSkill
- champion-identifierSkill
- churn-autopsySkill
- claude-design-criticSkill
- claude-design-system-architectSkill
- claude-landing-composerSkill
- claude-md-writerSkill
- client-health-dashboardSkill
- client-proposal-generatorSkill
- code-review-proSkill
- cold-email-sequence-generatorSkill
- color-palette-extractorSkill
- commercial-lease-analyzerSkill
- company-announcement-writerSkill
- competitor-content-analyzerSkill
- competitor-intel-agentSkill
- competitor-price-trackerSkill
- compliance-checkerSkill
- contact-hunterSkill
- content-repurposerSkill
- context-budgetSkill
- contract-analyzerSkill
- contract-redlinerSkill
- conversation-archaeologistSkill
- cowork-calendar-defragSkill
- cowork-contract-renewal-radarSkill
- cowork-data-room-builderSkill
- cowork-deal-roomSkill
- cowork-expense-auditSkill
- cowork-folder-organizerSkill
- cowork-hiring-screenerSkill
- cowork-home-inventorySkill
- cowork-inbox-triageSkill
- cowork-invoice-chaserSkill
- cowork-medical-bill-auditorSkill
- cowork-qbr-builderSkill
- cowork-rfp-responseSkill
- cowork-sop-writerSkill
- cowork-tax-prep-organizerSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 23
Start the app first and hold the port — a test suite against a dead server produces a wall of timeouts that tells you nothing:
- Distinctive: line 34
Run it: Read the failure, not the summary.
- Very specific: line 77
Never fix flake with waitForTimeout.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Browser Test Loop
Code that compiles is not code that works. This is the loop that closes the gap between "the diff looks right" and "the page does the thing".
Core Behavior
Drive a real browser against the running app, assert on what actually rendered, and fix what fails. Never report a UI change as working on the strength of the diff alone.
Setup
Playwright is the default. It installs its own browsers and runs headless in CI.
npm i -D @playwright/test && npx playwright install chromiumStart the app first and hold the port — a test suite against a dead server produces a wall of timeouts that tells you nothing:
npm run dev > /tmp/dev.log 2>&1 &
npx wait-on http://localhost:3000The Loop
- Name the assertion in one sentence. "After submitting the contact form with a valid email, a success message appears and no console error fires." Vague goals produce vague tests.
- Write the smallest script that proves it. One flow per file.
- Run it. Read the failure, not the summary.
- Fix the app, not the test — unless the test encoded the wrong expectation, in which case say so out loud.
- Re-run until green, then run it once more from a cold start to catch state that leaked between runs.
What to Assert
- The user-visible outcome: text on screen, a URL change, a row that appeared.
- Zero unexpected console errors. Collect them explicitly; a silent React error boundary looks like a blank success.
- Network calls that should have fired, and their status codes.
- The empty, loading, and error states — not just the happy path.
const errors = []
page.on('console', m => m.type() === 'error' && errors.push(m.text()))
page.on('pageerror', e => errors.push(e.message))
// ... drive the flow ...
expect(errors).toEqual([])Selector Rules
Query the way a person looks at a page: role, label, and visible text. getByRole('button', { name: 'Send' }) survives a restyle; .btn-primary > span:nth-child(2) does not. Add data-testid only where the visible text is genuinely ambiguous.
Screenshots
Take one on failure automatically, and one at the end of a flow when a human needs to eyeball the result. Full-page for layout questions, element-scoped for a component. Save under /tmp unless the user wants them kept.
npx playwright test --reporter=line 2>&1 | tail -30Pipe the output. A full Playwright HTML reporter dump is thousands of tokens of nothing.
Common Failure Modes
| Symptom | Real cause |
| Every test times out | App never started, or wrong port |
| Passes locally, fails headless | Animation or viewport size, not logic |
| Flaky on CI only | Waiting on a timeout instead of a condition |
| Blank page, no error | Client-side exception swallowed by an error boundary |
| Works once, fails on re-run | Test wrote state it never cleaned up |
Never fix flake with waitForTimeout. Wait for the condition — a selector, a response, a URL.
Reporting
Say what flow was driven, what was asserted, and the result. If something is still unverified, name it. Screenshots go with the answer when the question was visual.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

