Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/lukasrepublic/agentic-foundry/playwright-e2enpx skills add lukasrepublic/agentic-foundry --skill playwright-e2egit clone --depth 1 https://github.com/lukasrepublic/agentic-foundryWhat 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 | $0.00000 | $0.01508 |
| Opus 5 | $0.00000 | $0.00754 |
| Sonnet 5 | $0.00000 | $0.00302 |
| Haiku 4.5 | $0.00000 | $0.00151 |
Grade A, and why
playwright-e2e 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 2d 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 — 79 lines — stays where its author put it; the contents beside it link to each section on GitHub.
When to trigger
- Authoring an e2e test for a user-facing flow cited in a spec's acceptance criteria.
- Selector-strategy decisions (testid vs. role vs. label vs. text).
- Network-mocking decisions: mocking at the route level for deterministic test data.
- CI workflow changes for parallel e2e execution.
- Flaky-test diagnosis.
- Adding shared fixtures or test helpers for an e2e suite.
Procedure
-
Place the test under the target package's
e2e/<surface>/<feature>.spec.ts—<surface>is the web surface under test. Read the existinge2e/directory for naming and structure conventions before adding new files. -
Selector strategy (in priority order): a.
page.getByTestId('<data-testid>')— preferred; stable, intention-declaring. b.page.getByRole('<role>', { name: '<accessible-name>' })— second choice; semantically meaningful. c.page.getByLabel('<label-text>')— for form inputs with associated labels. d. CSS-class selectors — banned. Classes change with styling refactors; tests must survive style changes. -
Network mocking via
page.route: mock API responses at the network boundary — not at the function boundary. Usepage.route('**/api/<resource>/**', handler)at the fixture or test level. The handler defines the response body; actual network traffic is intercepted. This keeps tests deterministic without a running backend. -
Fixture composition via
test.extend:- Create shared fixtures for setup that multiple tests need (e.g., authenticated state, seeded data).
- Never share mutable state between tests. Each test starts from a known fixture state.
- Use
test.use({ storageState: 'auth.json' })for auth-state reuse across a suite.
-
Parallelism: tests are parallel-safe by default. If a test mutates global state (e.g., writes to a shared DB that affects other tests), isolate it with
test.describe.serial. Mark the reason with a comment. -
Run command:
{{ profile.test_recipe.e2e }}from the project root. For a targeted run, scope to a surface: appende2e/<surface>/to the run command.
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.
- 2d ago First seen · 79 lines · 0 tokens per session scan A 745fb6ff37ba
playwright-e2e is a skill published in the GitHub repository lukasrepublic/agentic-foundry (1 stars, last pushed 2d ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 1,508 tokens. 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
agent-production-validator
Agent skill for production-validator - invoke with $agent-production-validator.
inspector-workbench
Runs Inspector UI work on the standalone Threads state lab so the agent can see the overlay. Use when a CopilotKit employee asks an agent to fix, polish, add, or debug Inspector UI, chrome, panes, overlay actions, launcher, Home, Threads, Playground, Memory, or any visual behavior in @copilotkit/web-inspector. Don't…
tutti-record-agent-session-replay
From a Tutti checkout, run, audit, freshly replay, publish, or diagnose Session Replay cassettes that are driven by case-repository scenario scripts (CDP), not by interactive UI recording. Use for real-Provider capture while a scenario.mjs executes, cassette transport or semantic-state mismatches, fresh replay…
pod-e2e
ONLY for developing Kiro Crew itself -- if the project you are working on is anything else, ignore this skill: it drives Kiro Crew's own pod tooling, which does not exist in another repository. Runs end-to-end tests (backend API + frontend Playwright) for a Kiro Crew feature worktree against an ISOLATED throwaway pod…
browserstack
../../../engineering-team/playwright-pro/skills/browserstack/SKILL.md.
android-emulator
Verify and debug native, React Native, Expo, or Flutter apps on an Android Emulator with agent-device. Use when an agent needs to launch an app, inspect its live UI, tap, type, scroll, validate a code change, collect failure evidence, or reproduce a workflow on an Android virtual device.