New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Playwright E2E Authoring

by fmflurry in fmflurry/settings-opencode

Scaffold and extend Playwright E2E tests for the gc.platform suite (tests/playwright), wiring every artifact to the real frontend (localhost:4200) + real .NET backend — never mocks.

MITAuto-check passedTesting & QA

Install Playwright E2E Authoring

skills CLI
$ npx skills add fmflurry/settings-opencode --skill playwright-e2e-authoring -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install fmflurry/settings-opencode playwright-e2e-authoring --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/fmflurry/settings-opencode.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/playwright-e2e-authoring .claude/skills/playwright-e2e-authoring && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
playwright-e2e-authoring
GitHub stars
171
Token cost
~2.4k tokens
SKILL.md length
1,041 words
Files
5 (incl. references)
Skills in repo
20
Repo updated
First seen
Licence
MIT

At a glance

Scaffold and extend Playwright E2E tests for the gc.platform suite (tests/playwright), wiring every artifact to the real frontend (localhost:4200) + real .NET backend — never mocks.

  • Works in 4 steps: Confirm the stack is meant to be live.… → Find the frontend module under… → Understand test accounts: The default… → …
  • The user wants to add
  • SKILL.md covers When to activate, The four rules (non-negotiable…, Before you start and Workflow, plus 7 more sections
  • Calls npx, npm and docker-compose; needs PLAYWRIGHT_KC_PASSWORD

What it does

Playwright E2E Authoring is an agent skill from fmflurry/settings-opencode. Scaffold and extend Playwright E2E tests for the gc.platform suite (tests/playwright), wiring every artifact to the real frontend (localhost:4200) + real .NET backend — never mocks. Use whenever the user wants to add or write E2E / end-to-end tests, cover a new frontend feature module or screen, create a .spec.ts, add a Page Object Model (POM) or a Playwright fixture, or says things like "test the invoices page", "add an e2e test for <flow", or "write Playwright tests for <feature" — even when they do not mention…

Its SKILL.md is about 2.4k tokens, which your agent loads only when the skill is triggered. The skill folder holds 5 other files, including reference files (for example `references/data-setup.md`, `references/fixtures.md` and `references/pom.md`).

It sits in Testing & QA, covering End-to-end testing, Browser testing and Forms and invoices. It works with Playwright and .NET. The repository describes itself as: Custom OpenCode settings. The licence is MIT.

When your agent uses it

  • The user wants to add
  • Write E2E / end-to-end tests
  • Cover a new frontend feature module
  • Create a .spec.ts

Example prompts

  • “test the invoices page”
  • “add an e2e test for <flow”
  • “write Playwright tests for <feature”
  • “/playwright-e2e-authoring”

Requirements

  • Node.js
  • Docker

Workflow steps

4 steps, taken from the first numbered list in SKILL.md.

  1. Confirm the stack is meant to be live. Tests assume docker-compose up is running (frontend + backend healthy). You don't have to start it…
  2. Find the frontend module under frontend/src/app/modules/ so the test folder name mirrors it exactly (Rule 4). If unsure of the name, ask…
  3. Understand test accounts: The default authenticated session uses tenant-a-user (seeded identity for tenant TEN-A via env vars…
  4. Decide public vs authenticated — this picks which base fixture you extend. This is the single most important choice; see the table below…

What it can do on your machine

Read from SKILL.md and the folder at commit 0e6c33c. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • npx
    • npm
    • docker-compose

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use npx and npm, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names these keys or tokens, usually read from environment variables:

    • PLAYWRIGHT_KC_PASSWORD

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Playwright E2E Authoring loads about 2.4k tokens when it runs, and up to ~9k if it reads all its reference files. Until then it costs about 167 tokens; SKILL.md has 1,041 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~167
When it runs · the whole SKILL.md, loaded when a task matches
~2.4k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~9k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from fmflurry/settings-opencode at commit 0e6c33c, republished under its MIT licence (© fmflurry). 1,041 words, ~2,384 tokens.

Download SKILL.mdSave it as .claude/skills/playwright-e2e-authoring/SKILL.md (or your agent's skills folder). This skill also uses 4 other files; get the full folder from GitHub.
name
playwright-e2e-authoring
description
Scaffold and extend Playwright E2E tests for the gc.platform suite (tests/playwright), wiring every artifact to the real frontend (localhost:4200) + real .NET backend — never mocks. Use whenever the user wants to add or write E2E / end-to-end tests, cover a new frontend feature module or screen, create a `.spec.ts`, add a Page Object Model (POM) or a Playwright fixture, or says things like "test the invoices page", "add an e2e test for <flow>", or "write Playwright tests for <feature>" — even when they do not mention the POM / fixture / no-mocks conventions. Produces a POM + module fixture + spec that follow the suite's four hard rules.

Playwright E2E Authoring — gc.platform

This suite tests the live gc.platform stack end-to-end: the real Angular frontend (http://localhost:4200) plus the real GcPlatform.Api .NET backend, orchestrated by docker-compose at the repo root. Tests drive the full stack — there are no mocks, no stubs, no fake data.

Path convention: All paths in this document are relative to tests/playwright/ (the test suite root).

Your job when this skill is active: turn a request like "add E2E tests for the <feature> screen" into a correct POM + module fixture + spec, colocated under tests/<module>/, that compiles under strict TypeScript and follows the conventions the existing auth and invoices modules already demonstrate.

When to activate

  • Adding E2E coverage for a new frontend feature module or screen.
  • Writing a new .spec.ts, a Page Object Model, or a module fixture.
  • Extending an existing module with another screen/POM.
  • Any "test the X page/flow with Playwright" request, even when the conventions aren't named.

The four rules (non-negotiable — they are project law)

These come from tests/playwright/CLAUDE.md. Everything this skill generates must honour them.

#RuleWhat it means in practice
1No mocksReal frontend + real backend + real DB. No page.route()/context.route(), no MSW/sinon/nock, no fixture stubs, no page.waitForTimeout() or arbitrary sleeps. Create/clean test data via real API or UI.
2Page Object ModelEvery screen is a POM class under tests/<module>/pages/ extending BasePage. Specs never call raw page.locator() — all DOM access flows through a POM.
3Work by fixturePOMs are injected via Playwright fixtures (test.extend). Specs import test/expect from their module fixture, never from @playwright/test. Never new SomePage() inside a spec.
4Per application moduleOne test folder per frontend feature: frontend/src/app/modules/<module> → tests/<module>/. POM, fixtures, and specs stay colocated. Cross-module helpers live in support/.

Before you start

  1. Confirm the stack is meant to be live. Tests assume docker-compose up is running (frontend + backend healthy). You don't have to start it to author files, but never compensate for a missing backend with a mock.
  2. Find the frontend module under frontend/src/app/modules/<module> so the test folder name mirrors it exactly (Rule 4). If unsure of the name, ask or inspect the frontend tree.
  3. Understand test accounts: The default authenticated session uses tenant-a-user (seeded identity for tenant TEN-A via env vars PLAYWRIGHT_KC_USERNAME/PLAYWRIGHT_KC_PASSWORD, defaults: Nova-Delta-17!). Avoid reusing this account in password-reset specs — provision a disposable account via support/identity-accounts.ts. The dev-user identity has no tenant_id claim, so tenant-scoped screens (dunning, notifications, payments) render empty; use it only for session/logout tests.
  4. Decide public vs authenticated — this picks which base fixture you extend. This is the single most important choice; see the table below and references/fixtures.md.
Route kindExampleModule fixture extendsPOMs bound toExtra step
Authenticated (behind authSessionGuard)/invoicessupport/fixtures/auth.fixtureauthenticatedPageAdd the route to the warm-up loop in support/auth.setup.ts
Public/login, /activersupport/fixtures/base.fixturepagenone

Workflow

Create the folder structure, then the artifacts in dependency order (POM → fixture → spec). Read the matching reference file before writing each kind — they hold the exact templates and the reasoning behind each convention.

  1. Scaffold the folders

    tests/<module>/
├─ pages/        # one <screen>.page.ts per screen
├─ fixtures/     # <module>.fixture.ts
└─ <feature>.spec.ts

  2. Write the POM(s) — one per screen. → read references/pom.md

    • Extend BasePage (import { BasePage } from '../../../support/pages/base.page';).
    • Declare private readonly Locators, assign them in the constructor.
    • Prefer getByRole() / getByLabel() / getByTestId() over CSS/XPath.
    • Expose actions (goto, clicks, fills) and high-level assertions (expectLoaded, expect…).

  3. Write the module fixture — fixtures/<module>.fixture.ts. → read references/fixtures.md

    • Extend base (public) or auth (authenticated) per the table above.
    • Provide every POM as a fixture key.
    • Re-export expect.

  4. Write the spec(s) — <feature>.spec.ts. → read references/spec.md

    • import { test, expect } from './fixtures/<module>.fixture';
    • Group with test.describe, share setup with test.beforeEach.
    • Use web-first assertions only; no sleeps, no network interception.
    • If the test creates data (not just reads seeded fixtures), read references/data-setup.md for API-based setup/teardown patterns.

  5. If the routes are authenticated, append them to the route warm-up loop in support/auth.setup.ts so the dev server's lazy compile is paid once, serially, before workers fan out.

Show full SKILL.md (402 more words)Show less

Shared helpers in support/

When setting up test data or managing test state across modules, reach for these helpers:

HelperPurpose
keycloak-token.tsFetch a fresh access token via Authorization Code + PKCE flow for API calls from specs.
identity-accounts.tsProvision a disposable account (email + password + accountId) via POST /identity/accounts for password-reset flows.
keycloak-admin.tsRevoke a Keycloak session server-side (admin API); used to trigger session-loss tests.
mailpit.tsPoll Mailpit SMTP for password-reset emails and extract the reset link.
dunning-report-supply.tsPoll the dunning report generation status and check when lines appear.

Time budgets

The config (playwright.config.ts) sets generous defaults for the real stack:

  • timeout: 90_000 — per-test wall-clock limit (90s for frontend + backend round-trips + lazy compile).
  • expect.timeout: 15_000 — auto-retry window for assertions (15s for Transloco fetch + transforms).
  • CI: retries: 1, workers: 2 — one safety retry, two parallel workers.

Raise limits only for tests that legitimately need extra time (e.g., AI report generation: test.setTimeout(20 * 60 * 1000);) with a comment explaining why.

Admitted exceptions

See references/spec.md#admitted-exceptions for bounded fault injection, multi-context, and alternate-tenant patterns. All three are strict, justified-only uses; never extend beyond their examples.

Multiple fixtures per module

A module may hold several fixture files when specs need genuinely different base states. Example: tests/auth/fixtures/ has three:

  • auth.fixture.ts — unauthenticated journey (public routes like login, sign-up).
  • session.fixture.ts — extends the shared support/fixtures/auth.fixture, reusing the storageState.
  • stay-connected.fixture.ts — simulates a browser restart by clearing storageState mid-flow.

Each fixture explains its purpose in a JSDoc; never duplicate a fixture without documenting why the separation is necessary.

Routing

The e2e-runner agent and /e2e command hand Playwright work to this skill. After implementation, the playwright-e2e-review skill audits the result against the four rules.

Reference files

Read the one that matches what you're writing — don't write from memory:

  • references/pom.md — Page Object Model template, locator strategy, the BasePage contract, annotated real example.
  • references/fixtures.md — base vs auth fixtures, the authenticatedPage mechanism, the Record<never, never> gotcha, module-fixture templates, mergeTests.
  • references/spec.md — spec structure, web-first assertions, real-data setup/teardown, naming conventions.
  • references/data-setup.md — creating and cleaning test data via the real API, seeded vs. transient data, extracting auth tokens, defensive teardown patterns.

Verify before done

The suite is strict TypeScript (tsc with strict: true, noImplicitAny) and the repo bans the any type. Before reporting success:

bash
cd tests/playwright
npx tsc --noEmit --pretty false      # must be clean

If the stack is up, you can also run the new module:

bash
npm run test:e2e -- tests/<module>

Note: the suite runs against system Chrome (channel: 'chrome' in playwright.config.ts) because the Playwright browser CDN is firewall-blocked here. Don't add firefox/webkit projects expecting downloaded browsers.

© fmflurry, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 4 other files (references) in skills/playwright-e2e-authoring of fmflurry/settings-opencode.

  • SKILL.md
  • references/data-setup.md
  • references/fixtures.md
  • references/pom.md
  • references/spec.md

Open the folder on GitHubat commit 0e6c33c

Compare with similar skills

Playwright E2E Authoring next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Playwright E2E Authoring compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Playwright E2E Authoring this skillfmflurry/settings-opencode171—~2.4kAutomated safety check: PassMIT
Dotnet Testingnovotnyllc/dotnet-artisan233—~972Automated safety check: PassMIT
Dotnet Testingmacalbert/envilder138—~1.6kAutomated safety check: PassMIT
Web Application Testinganthropics/skills180k51 repos~966Automated safety check: PassApache-2.0
Playwright CLIsanity-io/sanity6.4k18 repos~1.9kAutomated safety check: PassMIT
playwright-cli Browser Automationgithub/gh-aw5.4k24 repos~2.8kAutomated safety check: PassMIT

Similar skills

  • Dotnet Testing

    novotnyllc/dotnet-artisan

    Defines .NET test strategy and implementation patterns across xUnit v3 (Facts, Theories, fixtures, IAsyncLifetime), integration testing (WebApplicationFactory, Testcontainers), Aspire testing…

    233 GitHub stars~972 tokensUpdated today
    Testing & QAAuto-check passed

  • Dotnet Testing

    macalbert/envilder

    Mandatory testing conventions for .NET (xUnit, AwesomeAssertions).

    138 GitHub stars~1.6k tokensUpdated 3 days ago
    Testing & QAAuto-check passed

  • Web Application Testing

    anthropics/skills

    Official

    Tests local web applications with Python Playwright scripts, checking frontend behavior, capturing screenshots and reading browser console logs.

    180k GitHub starsUsed in 51 repos~966 tokens
    Testing & QAAuto-check passed

  • Playwright CLI

    sanity-io/sanity

    Official

    Automates browser interactions for web testing, form filling, screenshots, and data extraction.

    6.4k GitHub starsUsed in 18 repos~1.9k tokens
    Testing & QAAuto-check passed

  • playwright-cli Browser Automation

    github/gh-aw

    Official

    Drives a real browser from the command line with playwright-cli to open pages, interact, mock requests, save state and work with Playwright tests.

    5.4k GitHub starsUsed in 24 repos~2.8k tokens
    Testing & QAAuto-check passed

  • Write and Verify Playwright Tests

    appsmithorg/appsmith

    Writes a Playwright end-to-end test from a prompt, runs it against a live Appsmith deployment and retries with fixes up to three times until it passes.

    41k GitHub stars~2.9k tokensUpdated today
    Testing & QAAuto-check: notes

More from fmflurry/settings-opencode

All 20 skills in this repo

  • Show Your Work

    fmflurry/settings-opencode

    Keep a reviewable decision trail for long-running or unattended work: a TSV log with one row per decision (what, why, evidence, result).

    171 GitHub stars~1.8k tokensUpdated yesterday
    Auto-check passed

  • Why

    fmflurry/settings-opencode

    A skill your agent uses for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds.

    171 GitHub stars~2k tokensUpdated yesterday
    Auto-check passed

  • Angular Accessibility

    fmflurry/settings-opencode

    Audit and fix common accessibility issues in Angular templates and Angular Material components.

    171 GitHub stars~2.7k tokensUpdated yesterday
    Auto-check passed

  • Angular Clean Architecture

    fmflurry/settings-opencode

    Scaffolds and extends Angular standalone feature MODULES under src/app/modules/{name} using Clean Architecture layering (presentation/application/core/infrastructure), a self-registering module…

    171 GitHub stars~3.6k tokensUpdated yesterday
    Auto-check passed

  • Angular Cop

    fmflurry/settings-opencode

    Pre-merge code review for Angular + TypeScript pull requests.

    171 GitHub stars~1.4k tokensUpdated yesterday
    Auto-check passed

  • API Spec Openapi

    fmflurry/settings-opencode

    Generate OpenAPI 3.1 specs that follow the Zalando RESTful API Guidelines (kebab-case naming, cursor pagination, RFC 9457 problem+json errors, URL versioning, idempotency), one YAML file per bounded…

    171 GitHub stars~3.8k tokensUpdated yesterday
    Auto-check passed

Works with

Categories

Questions about Playwright E2E Authoring

What does Playwright E2E Authoring do?

Scaffold and extend Playwright E2E tests for the gc.platform suite (tests/playwright), wiring every artifact to the real frontend (localhost:4200) + real .NET backend — never mocks. Playwright E2E Authoring is an agent skill from fmflurry/settings-opencode.NET backend — never mocks.

When should I use Playwright E2E Authoring?

Playwright E2E Authoring fits situations like: the user wants to add; write E2E / end-to-end tests; cover a new frontend feature module; create a .spec.ts.

How do I install Playwright E2E Authoring in Claude Code?

Run `npx skills add fmflurry/settings-opencode --skill playwright-e2e-authoring -a claude-code`. Or copy the skill folder (skills/playwright-e2e-authoring in fmflurry/settings-opencode) into .claude/skills/playwright-e2e-authoring in your project. Claude Code loads it when a task matches its description.

How do I install Playwright E2E Authoring in Codex?

Run `npx skills add fmflurry/settings-opencode --skill playwright-e2e-authoring -a codex`. Or copy the skill folder (skills/playwright-e2e-authoring in fmflurry/settings-opencode) into .agents/skills/playwright-e2e-authoring in your project. Codex loads it when a task matches its description.

Can I use Playwright E2E Authoring in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add fmflurry/settings-opencode --skill playwright-e2e-authoring -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/playwright-e2e-authoring, .gemini/skills/playwright-e2e-authoring, .github/skills/playwright-e2e-authoring and .opencode/skills/playwright-e2e-authoring in your project.

What does Playwright E2E Authoring need to run?

Going by SKILL.md and its folder, Playwright E2E Authoring needs the command-line tools its instructions call (npx, npm and docker-compose) and credentials named PLAYWRIGHT_KC_PASSWORD. Our summary lists: Node.js; Docker.

Does Playwright E2E Authoring access the network?

SKILL.md contains no URLs. Its commands use npx and npm, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Playwright E2E Authoring safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Playwright E2E Authoring use?

Playwright E2E Authoring is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Playwright E2E Authoring use?

About 2.4k tokens (SKILL.md is roughly 9.5k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 6.7k tokens, read only when the agent opens those files.

What are the alternatives to Playwright E2E Authoring?

Skills that share tags, products or a category with Playwright E2E Authoring: Dotnet Testing (novotnyllc/dotnet-artisan, 233 stars), Dotnet Testing (macalbert/envilder, 138 stars), Web Application Testing (anthropics/skills, 180k stars) and Playwright CLI (sanity-io/sanity, 6.4k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Playwright E2E Authoring?

fmflurry (a GitHub user) maintains it in fmflurry/settings-opencode, which has 171 GitHub stars. The repository holds 20 skills in this directory. The repository was last updated on October 7, 2026.

Source: fmflurry/settings-opencode on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.