use-profiles
Using Playwright Authentication Profiles
Purpose
Load saved Playwright storageState authentication profiles before browser automation work. This eliminates the need to log in manually at the start of every browser session.
When This Applies
This skill applies when ALL of the following are true:
- The current project has a
.playwright/profiles.jsonfile - Browser automation work is about to begin (using Playwright CLI via Bash)
- The target page requires authentication
Profile Discovery
Check for .playwright/profiles.json at the project root. Read it to discover available profiles. The file contains entries like:
{
"profiles": {
"admin": {
"loginUrl": "https://example.com/login",
"description": "Full permissions",
"createdAt": "2026-03-31T12:00:00Z"
}
}
}
Each profile has a corresponding storageState file at .playwright/profiles/<role-name>.json.
Profile Selection
Determine which profile to use based on conversation context:
- If the user mentions a specific role (e.g., "test the admin dashboard", "check the speaker view"), match it to a profile name from the config.
- If the user does not specify a role and only one profile exists, use it automatically.
- If the user does not specify a role and multiple profiles exist, ask which one to use. Present the available profiles with their descriptions.
Loading a Profile
Before navigating to any authenticated page, load the profile using playwright-cli via the Bash tool. The {session} placeholder below refers to the current named session (e.g., runner-desktop, qa-ux — set by the invoking skill or command).
-
Verify the storageState file exists at
.playwright/profiles/<role-name>.json. If it does not exist, inform the user and suggest running/setup-profilesto create it. -
Load the profile's cookies and localStorage into the browser session:
playwright-cli -s={session} state-load ".playwright/profiles/<role-name>.json"This restores all cookies and per-origin localStorage from the storageState JSON — the same format used by Playwright's
storageState(). -
If the profile JSON contains a
sessionStoragefield (not part of standard storageState — added by/setup-profiles), restore it separately after navigating to the target origin:playwright-cli -s={session} goto "<origin>"Then for each sessionStorage entry:
playwright-cli -s={session} sessionstorage-set "<name>" "<value>" -
Navigate to the target authenticated page. Cookies are sent with the request, localStorage is already populated, and sessionStorage is restored — so server-side, client-side, and SPA auth libraries (Supabase, Firebase, Auth0) will recognize the session.
Test Data Files & Acceptance Criteria
After loading a profile, check whether it has a files array and/or acceptance object in profiles.json. These are optional fields — many profiles will not have them.
Surfacing available files
If the profile has files, inform the caller with a summary:
This profile has N test data file(s) available:
- valid-deck.pptx — Clean deck, passes all checks
- profanity-deck.pptx — Profanity in notes, should flag
- (cloud) oversized-deck.pptx — 200MB deck, tests size limit
Profile acceptance criteria: upload accepted, processing completes
Mark cloud-hosted files (those with url instead of path) with (cloud) for clarity.
This information is surfaced but not acted on by this skill — the consumer (workflow generator, runner, agent) decides whether and how to use it.
File path validation
For each file entry with a path field, verify the file exists at the given path relative to the project root. If a file is missing, warn:
Profile "speaker" references test file "test-fixtures/valid-deck.pptx" which does not exist. The file may have been moved or deleted.
Do not fail or block on missing files — just warn. Files with url are not validated (they may require authentication or be on private networks).
Acceptance criteria summary
If the profile has acceptance, include a human-readable summary of the configured criteria. Map the fields as follows:
| Field | Summary text |
|---|---|
uploadAccepted: true |
upload accepted |
processingCompletes: true |
processing completes |
resultDownloadable: true |
result downloadable |
errorExpected: true |
error expected |
expectedStatus: "clear" |
expected status: "clear" |
If individual files have acceptance overrides, note which files override the profile defaults:
File "corrupted.pptx" overrides profile acceptance: upload rejected, error expected
Session Expiry Detection
After loading a profile and navigating to the target page, check whether the session is still valid using these heuristics in order:
- URL redirect: If the browser is redirected to a URL matching the
loginUrlfrom the profile config, the session has likely expired. Check the URL in the snapshot output'sPage URLline. - Auth-provider redirect: If the final URL is on a different domain (e.g.,
accounts.google.com,auth0.com), the app redirected to an OAuth provider — the session has expired. - Page content check: Run
playwright-cli -s={session} snapshotvia Bash and look for login-related elements: sign-in forms, "Log in" / "Sign in" buttons, or "session expired" text. If the target page was expected to show authenticated content but instead shows a login UI, the session has expired.
If expiry is detected:
- Inform the user that the session for the profile appears to have expired
- Suggest running
/setup-profilesto refresh it - Do not attempt to log in automatically
These heuristics are best-effort. The user can always run /setup-profiles manually to refresh any profile.
Missing Profiles
If .playwright/profiles.json exists but references profiles whose storageState files are missing (e.g., after a fresh clone), inform the user:
"This project has Playwright profiles configured but the authentication state files are missing (they are gitignored and need to be created locally). Run
/setup-profilesto authenticate."
No Profile Config
If .playwright/profiles.json does not exist, this skill does not apply. Do not suggest creating profiles unless the user is explicitly asking about authenticated browser automation.
More from neonwatty/qa-skills
playwright-runner
Executes workflow markdown files interactively via Playwright CLI, stepping through each workflow action in a real browser. Use when the user says "run workflows", "run playwright", "test workflows", "execute workflows", or wants to interactively test their app against workflow documentation. Supports desktop, mobile, and multi-user workflows with authentication.
5multi-user-workflow-generator
Generates multi-user workflow documentation by interviewing the user about personas, exploring the codebase for multi-user patterns, then walking through the live app with per-persona Playwright CLI named sessions to co-author interleaved, persona-tagged workflows. Use when the user says "generate multi-user workflows", "create multi-user workflows", or "generate concurrent user workflows". Produces persona-tagged workflow markdown that feeds into the multi-user converter and Playwright runner.
5keyword-wedge
Analyzes an app's codebase and cross-references Google Search Console, PostHog, and Google Keyword Planner to identify low-competition keyword footholds and track expansion into adjacent terms. This skill should be used when the user says "keyword wedge", "find keyword opportunities", "seo analysis", "keyword strategy", "find search wedges", "keyword research for my app", "grow organic traffic", "what keywords should I target", "SEO for my app", "organic search strategy", or "how to rank higher". Generates markdown and HTML reports and maintains state across runs for expansion tracking.
4submit-learnings
Filters and submits accumulated QA learnings as a GitHub issue (with optional PR) on the plugin repo. Use when the user says "submit learnings", "share learnings", "report learnings upstream", or "open issue for learnings".
4resilience-audit
Audits web apps for resilience against unexpected user behavior — accidental, edge-case, and chaotic. Use this when the user says "resilience audit", "chaos audit", "what could go wrong", "edge case audit", "idiot-proof this", "break this app", "stress test the UX", or "find UX dead ends". Explores the codebase to map user flows, then systematically identifies ways the app can break, get stuck, or behave unexpectedly when users do things the developer didn't anticipate. Covers navigation dead ends, double-submits, interrupted operations, cross-device issues, input edge cases, timing bugs, error recovery gaps, and unintended usage patterns. Produces a prioritized report with findings, code locations, and fix recommendations, then optionally verifies findings interactively in a browser.
4review-learnings
Synthesizes accumulated QA learnings from .qa-learnings/ledger.md into prioritized, actionable plugin improvements. Use when the user says "review learnings", "what have we learned", "improve the plugin", "learnings report", or "synthesize QA feedback".
4