Getting it into your agent
It runs from inside its repository, so the clone comes first — what it calls does not travel with the file alone.
git clone --depth 1 https://github.com/FaisalNoman/playwright-skillsnpx agentmods add skills/faisalnoman/playwright-skills/playwright-setupWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/faisalnoman/playwright-skills/playwright-setup)<a href="https://agentmods.dev/skills/faisalnoman/playwright-skills/playwright-setup"><img src="https://agentmods.dev/badge/skills/faisalnoman/playwright-skills/playwright-setup.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00029 | $0.08802 |
| Opus 5 | $0.00015 | $0.04401 |
| Sonnet 5 | $0.00006 | $0.01760 |
| Haiku 4.5 | $0.00003 | $0.00880 |
Grade A, and why
playwright-setup scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 7d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 710 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Playwright Setup Generator
Goal
Produce a complete, ready-to-run Playwright E2E test suite for any project by:
- Mining existing docs and source code for user flows
- Interviewing the user to fill gaps and confirm scope
- Presenting a test plan for approval
- Writing all required files
Do NOT write any files until the user approves the plan.
Phase 0 — Mode Detection
Runs first, before any document scanning. Determine whether this project already has a Playwright suite:
- Check whether
playwright.config.ts(or.js) exists at the project root, AND at least one*.spec.ts/*.spec.jsfile exists anywhere under the project. - Config and spec files not BOTH present → fresh-generation mode. This covers three cases: neither exists, only
playwright.config.tsexists (a mid-setup or config-only project), or only spec files exist with no config. Proceed to Phase 1 exactly as documented below — nothing about the existing flow changes in shape. If aplaywright.config.tsalready exists in this fresh-generation path, call this out explicitly in the Phase 3 plan ("Note: this will replace the existingplaywright.config.ts") so the approval gate in Phase 3 (Do NOT write any files until approved) gives the user a chance to object before it's overwritten. - Both found → ask the user, in ONE message, which of three things they want (use the
AskUserQuestiontool, single-select):- Run the existing suite — re-verify what's already there through the fix loop; no new spec files are written. This routes straight to Phase 4.5 (Verify & Fix), skipping Phases 1-4 entirely. This is run-existing mode.
- Add tests for new/uncovered areas — read the existing suite first, then scan/interview/plan/write only the gaps. This routes through Phases 1-4 with the incremental-mode behavior described in Phase 1 below, then Phase 4.5 as normal. This is add-tests mode.
- Regenerate from scratch — falls through into fresh-generation mode above; nothing is discarded until Phase 3's approval gate, same as today.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 7d ago First seen · 710 lines · 29 tokens per session scan A c698fe52f6aa
playwright-setup is a skill published in the GitHub repository FaisalNoman/playwright-skills (1 stars, last pushed 2d ago), licensed MIT. It adds 29 tokens to every session and 8,802 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
ui-aqa-flow
Workflow for automated QA: integration and end-to-end UI test automation, page objects, etc.
qa-knowledge
To run QA engineering — requirements/gap analysis, scenario & spec design, test implementation, failure triage — over the QA knowledge base.
browser-check
Drive a real browser and come back with a MEASUREMENT rather than an impression - console errors and >=400 responses as counts, computed styles as JSON when appearance is disputed. Use when work touches UI, when a review must verify one, or when fidelity-gate asks for its measurement.
e2e
Add durable end-to-end tests for user/API-visible behavior. Detect or scaffold the E2E framework, write tests, run the app, and store evidence. Use for E2E, Playwright/Cypress, regression tests, or quality gates. Not exploratory QA.
acceptance
A skill for writing, running, and repairing human-written acceptance checks stored in an `acceptance/ACCEPTANCE.md` file. Acceptance checks are executable tests of whether the finished result matches the requested outcome.
fec-testing-strategy
A frontend testing strategy maps different risks to different checks, such as type checking, unit tests, component tests, integration tests, end-to-end tests, accessibility, security, and performance checks. It explains end-to-end testing as testing a complete user journey in a real browser.