Agent skill

E2E Tester

by PageAI-Pro in PageAI-Pro/ralph-loop

Playwright E2E testing patterns. An agent skill from PageAI-Pro/ralph-loop.

MITAuto-check: notesTesting & QA

Install E2E Tester

skills CLI
$ npx skills add PageAI-Pro/ralph-loop --skill e2e-tester -a claude-code

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

GitHub CLI
$ gh skill install PageAI-Pro/ralph-loop e2e-tester --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/PageAI-Pro/ralph-loop.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agent/skills/e2e-tester .claude/skills/e2e-tester && 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
e2e-tester
GitHub stars
315
Token cost
~4.3k tokens
SKILL.md length
542 words
Files
1
Skills in repo
4
Repo updated
First seen
Licence
MIT

At a glance

Playwright E2E testing patterns. An agent skill from PageAI-Pro/ralph-loop.

  • Works in 7 steps: Navigate to target page → Take snapshot to see page structure and… → Interact with forms/elements to verify… → …
  • Tasks that involve End-to-end testing
  • SKILL.md covers MCP Workflow (MANDATORY If…, Waiting Strategies (CRITICAL), File Structure and Selector Priority (REQUIRED), plus 17 more sections
  • Calls npx

What it does

E2E Tester is an agent skill from PageAI-Pro/ralph-loop. Playwright E2E testing patterns. Trigger: When writing Playwright E2E tests (Page Object Model, selectors, MCP exploration workflow).

Its SKILL.md is about 4.3k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Testing & QA, covering End-to-end testing and Browser testing. It works with Model Context Protocol and Playwright. The repository describes itself as: A long-running AI agent loop. Ralph automates software development tasks by iteratively working through a task list until completion. The licence is MIT.

When your agent uses it

  • Tasks that involve End-to-end testing
  • Tasks that involve Browser testing

Example prompts

  • “/e2e-tester”

Requirements

  • Pre-approved tools (allowed-tools): Read, Edit, Write, Glob, Grep, Bash, WebFetch, WebSearch, Task

Workflow steps

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

  1. Navigate to target page
  2. Take snapshot to see page structure and elements
  3. Interact with forms/elements to verify exact user flow
  4. Take screenshots to document expected states
  5. Verify page transitions through complete flow (loading, success, error)
  6. Document actual selectors from snapshots (use real refs and labels)
  7. Only after exploring create test code with verified selectors

What it can do on your machine

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

  • Tool permissions

    Pre-approves these tools, so the agent can use them without asking each time:

    • Read
    • Edit
    • Write
    • Glob
    • Grep
    • Bash
    • WebFetch
    • WebSearch
    • Task

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • npx

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

  • Network

    No URLs in SKILL.md. Its commands use npx, 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 no API keys, tokens, secrets or passwords.

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

Context cost

E2E Tester loads about 4.3k tokens when it runs. Until then it costs about 36 tokens; SKILL.md has 542 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~36
When it runs · the whole SKILL.md, loaded when a task matches
~4.3k

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: notes

The automated check noted patterns worth knowing about, such as sudo or a known installer.

  • NotePre-approves every shell command (allowed-tools: Bash)SKILL.md
    allowed-tools: Read, Edit, Write, Glob, Grep, Bash, WebFetch, WebSearch, Task

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 PageAI-Pro/ralph-loop at commit eba65eb, republished under its MIT licence (© PageAI-Pro). 542 words, ~4,327 tokens.

Download SKILL.mdSave it as .claude/skills/e2e-tester/SKILL.md (or your agent's skills folder).
name
e2e-tester
description
Playwright E2E testing patterns. Trigger: When writing Playwright E2E tests (Page Object Model, selectors, MCP exploration workflow).
allowed-tools
Read, Edit, Write, Glob, Grep, Bash, WebFetch, WebSearch, Task
metadata.scope
root, ui
metadata.auto_invoke
Writing Playwright E2E tests

Before you start:

  • check if any existing tests cover the functionality you are testing
  • check if a unit tests can cover the feature better
  • analyze if a end to end test brings any value over a unit test

If the answer is yes to any of the above, proceed with the end to end test creation.

MCP Workflow (MANDATORY If Available)

⚠️ If you have Playwright MCP tools, ALWAYS use them BEFORE creating any test:

  1. Navigate to target page
  2. Take snapshot to see page structure and elements
  3. Interact with forms/elements to verify exact user flow
  4. Take screenshots to document expected states
  5. Verify page transitions through complete flow (loading, success, error)
  6. Document actual selectors from snapshots (use real refs and labels)
  7. Only after exploring create test code with verified selectors

If MCP NOT available: Proceed with test creation based on docs and code analysis.

Why This Matters:

  • ✅ Precise tests - exact steps needed, no assumptions
  • ✅ Accurate selectors - real DOM structure, not imagined
  • ✅ Real flow validation - verify journey actually works
  • ✅ Avoid over-engineering - minimal tests for what exists
  • ✅ Prevent flaky tests - real exploration = stable tests
  • ❌ Never assume how UI "should" work

Waiting Strategies (CRITICAL)

typescript
// ❌ NEVER use fixed waits
await page.waitForTimeout(2000);

// ✅ Wait for specific conditions
await expect(element).toBeVisible();
await page.waitForResponse(resp => resp.url().includes('/api/data'));
await page.waitForURL('**/dashboard');
await expect(page.getByText('Success')).toBeVisible({ timeout: 10000 });

// ✅ For SPAs, prefer explicit waits over networkidle
await page.goto('/app', { waitUntil: 'domcontentloaded' });
await expect(page.getByRole('main')).toBeVisible();

File Structure

tests/
├── base-page.ts              # Parent class for ALL pages
├── helpers.ts                # Shared utilities
└── {page-name}/
    ├── {page-name}-page.ts   # Page Object Model
    ├── {page-name}.spec.ts   # ALL tests here (NO separate files!)
    └── {page-name}.md        # Test documentation

File Naming:

  • ✅ sign-up.spec.ts (all sign-up tests)
  • ✅ sign-up-page.ts (page object)
  • ✅ sign-up.md (documentation)
  • ❌ sign-up-critical-path.spec.ts (WRONG - no separate files)
  • ❌ sign-up-validation.spec.ts (WRONG)

Selector Priority (REQUIRED)

typescript
// 1. BEST - getByRole for interactive elements
this.submitButton = page.getByRole("button", { name: "Submit" });
this.navLink = page.getByRole("link", { name: "Dashboard" });

// 2. BEST - getByLabel for form controls
this.emailInput = page.getByLabel("Email");
this.passwordInput = page.getByLabel("Password");

// 3. SPARINGLY - getByText for static content only
this.errorMessage = page.getByText("Invalid credentials");
this.pageTitle = page.getByText("Welcome");

// 4. LAST RESORT - getByTestId when above fail
this.customWidget = page.getByTestId("date-picker");

// ❌ AVOID fragile selectors
this.button = page.locator(".btn-primary");  // NO
this.input = page.locator("#email");         // NO

Scope Detection (ASK IF AMBIGUOUS)

User SaysAction
"a test", "one test", "new test", "add test"Create ONE test() in existing spec
"comprehensive tests", "all tests", "test suite", "generate tests"Create full suite

Examples:

  • "Create a test for user sign-up" → ONE test only
  • "Generate E2E tests for login page" → Full suite
  • "Add a test to verify form validation" → ONE test to existing spec

Page Object Pattern

typescript
import { Page, Locator, expect } from "@playwright/test";

// BasePage - ALL pages extend this
export class BasePage {
  constructor(protected page: Page) {}

  async goto(path: string): Promise<void> {
    await this.page.goto(path);
    await this.page.waitForLoadState("networkidle");
  }

  // Common methods go here (see Refactoring Guidelines)
  async waitForNotification(): Promise<void> {
    await this.page.waitForSelector('[role="status"]');
  }

  async verifyNotificationMessage(message: string): Promise<void> {
    const notification = this.page.locator('[role="status"]');
    await expect(notification).toContainText(message);
  }
}

// Page-specific implementation
export interface LoginData {
  email: string;
  password: string;
}

export class LoginPage extends BasePage {
  readonly emailInput: Locator;
  readonly passwordInput: Locator;
  readonly submitButton: Locator;

  constructor(page: Page) {
    super(page);
    this.emailInput = page.getByLabel("Email");
    this.passwordInput = page.getByLabel("Password");
    this.submitButton = page.getByRole("button", { name: "Sign in" });
  }

  async goto(): Promise<void> {
    await super.goto("/login");
  }

  async login(data: LoginData): Promise<void> {
    await this.emailInput.fill(data.email);
    await this.passwordInput.fill(data.password);
    await this.submitButton.click();
  }

  async verifyCriticalOutcome(): Promise<void> {
    await expect(this.page).toHaveURL("/dashboard");
  }
}

Page Object Reuse (CRITICAL)

Always check existing page objects before creating new ones!

typescript
// ✅ GOOD: Reuse existing page objects
import { SignInPage } from "../sign-in/sign-in-page";
import { HomePage } from "../home/home-page";

test("User can sign up and login", async ({ page }) => {
  const signUpPage = new SignUpPage(page);
  const signInPage = new SignInPage(page);  // REUSE
  const homePage = new HomePage(page);      // REUSE

  await signUpPage.signUp(userData);
  await homePage.verifyPageLoaded();  // REUSE method
  await homePage.signOut();           // REUSE method
  await signInPage.login(credentials); // REUSE method
});

// ❌ BAD: Recreating existing functionality
export class SignUpPage extends BasePage {
  async logout() { /* ... */ }  // ❌ HomePage already has this
  async login() { /* ... */ }   // ❌ SignInPage already has this
}

Guidelines:

  • Check tests/ for existing page objects first
  • Import and reuse existing pages
  • Create page objects only when page doesn't exist
  • If test requires multiple pages, ensure all page objects exist (create if needed)
Show full SKILL.md (210 more words)Show less

Refactoring Guidelines

Move to BasePage when:
  • ✅ Navigation helpers used by multiple pages (waitForPageLoad(), getCurrentUrl())
  • ✅ Common UI interactions (notifications, modals, theme toggles)
  • ✅ Verification patterns repeated across pages (isVisible(), waitForVisible())
  • ✅ Error handling that applies to all pages
  • ✅ Screenshot utilities for debugging
Move to helpers.ts when:
  • ✅ Test data generation (generateUniqueEmail(), generateTestUser())
  • ✅ Setup/teardown utilities (createTestUser(), cleanupTestData())
  • ✅ Custom assertions (expectNotificationToContain())
  • ✅ API helpers for test setup (seedDatabase(), resetState())
  • ✅ Time utilities (waitForCondition(), retryAction())

Before (BAD):

typescript
// Repeated in multiple page objects
export class SignUpPage extends BasePage {
  async waitForNotification(): Promise<void> {
    await this.page.waitForSelector('[role="status"]');
  }
}
export class SignInPage extends BasePage {
  async waitForNotification(): Promise<void> {
    await this.page.waitForSelector('[role="status"]');  // DUPLICATED!
  }
}

After (GOOD):

typescript
// BasePage - shared across all pages
export class BasePage {
  async waitForNotification(): Promise<void> {
    await this.page.waitForSelector('[role="status"]');
  }
}

// helpers.ts - data generation
export function generateUniqueEmail(): string {
  return `test.${Date.now()}@example.com`;
}

export function generateTestUser() {
  return {
    name: "Test User",
    email: generateUniqueEmail(),
    password: "TestPassword123!",
  };
}

Test Pattern with Tags

typescript
import { test, expect } from "@playwright/test";
import { LoginPage } from "./login-page";

test.describe("Login", () => {
  test("User can login successfully",
    { tag: ["@critical", "@e2e", "@login", "@LOGIN-E2E-001"] },
    async ({ page }) => {
      const loginPage = new LoginPage(page);

      await loginPage.goto();
      await loginPage.login({ email: "user@test.com", password: "pass123" });

      await expect(page).toHaveURL("/dashboard");
    }
  );
});

Tag Categories:

  • Priority: @critical, @high, @medium, @low
  • Type: @e2e
  • Feature: @signup, @signin, @dashboard
  • Test ID: @SIGNUP-E2E-001, @LOGIN-E2E-002

Test Documentation Format ({page-name}.md)

markdown
### E2E Tests: {Feature Name}

**Suite ID:** `{SUITE-ID}`
**Feature:** {Feature description}

---

## Test Case: `{TEST-ID}` - {Test case title}

**Priority:** `{critical|high|medium|low}`

**Tags:**
- type → @e2e
- feature → @{feature-name}

**Description/Objective:** {Brief description}

**Preconditions:**
- {Prerequisites for test to run}
- {Required data or state}

### Flow Steps:
1. {Step 1}
2. {Step 2}
3. {Step 3}

### Expected Result:
- {Expected outcome 1}
- {Expected outcome 2}

### Key verification points:
- {Assertion 1}
- {Assertion 2}

### Notes:
- {Additional considerations}

Documentation Rules:

  • ❌ NO general test running instructions
  • ❌ NO file structure explanations
  • ❌ NO code examples or tutorials
  • ❌ NO troubleshooting sections
  • ✅ Focus ONLY on specific test case
  • ✅ Keep under 60 lines when possible

Authentication State Reuse

typescript
// auth.setup.ts - Run once, reuse across tests
import { test as setup } from "@playwright/test";

setup("authenticate", async ({ page }) => {
  await page.goto("/login");
  await page.getByLabel("Email").fill("user@test.com");
  await page.getByLabel("Password").fill("password");
  await page.getByRole("button", { name: "Sign in" }).click();
  await page.waitForURL("/dashboard");
  await page.context().storageState({ path: ".auth/user.json" });
});

// playwright.config.ts
projects: [
  { name: "auth", testMatch: /auth\.setup\.ts/ },
  { name: "logged-in", dependencies: ["auth"], use: { storageState: ".auth/user.json" } },
  { name: "logged-out", use: { storageState: { cookies: [], origins: [] } } }
]

API Mocking

typescript
// Mock API responses for isolated tests
await page.route("**/api/users", route =>
  route.fulfill({ json: { users: [{ id: 1, name: "Test" }] } })
);

// Mock error states
await page.route("**/api/submit", route =>
  route.fulfill({ status: 500, json: { error: "Server error" } })
);

// Abort requests (e.g., block analytics)
await page.route("**/analytics/**", route => route.abort());

Test Fixtures

typescript
// fixtures.ts - Custom fixtures for setup/teardown
import { test as base } from "@playwright/test";
import { AdminPage } from "./admin/admin-page";

export const test = base.extend<{ adminPage: AdminPage }>({
  adminPage: async ({ page }, use) => {
    const admin = new AdminPage(page);
    await admin.goto();
    await use(admin);
    // Teardown runs after test
  },
});

// Usage in tests
test("admin can manage users", async ({ adminPage }) => {
  await adminPage.deleteUser("test@example.com");
});

Parallel Execution

typescript
// Tests run in parallel by default. Use serial when tests share state:
test.describe.configure({ mode: "serial" });

// Isolate test data to prevent conflicts
test("create user", async ({ page }) => {
  const uniqueEmail = `user-${Date.now()}@test.com`; // ✅ Unique per run
});

Assertions

typescript
// Soft assertions - collect multiple failures
await expect.soft(page.getByText("Title")).toBeVisible();
await expect.soft(page.getByText("Subtitle")).toBeVisible();
// Test continues, reports all failures at end

// Polling assertions - retry until condition met
await expect(async () => {
  const count = await page.getByRole("listitem").count();
  expect(count).toBeGreaterThan(5);
}).toPass({ timeout: 10000 });

// Visual regression
await expect(page).toHaveScreenshot("dashboard.png");
await expect(page.getByRole("dialog")).toHaveScreenshot();

Common Pitfalls

typescript
// ❌ Element detached after navigation
const button = page.getByRole("button", { name: "Submit" });
await button.click();
await button.click(); // May fail if page navigated

// ✅ Re-query after navigation
await page.getByRole("button", { name: "Submit" }).click();
await page.getByRole("button", { name: "Confirm" }).click();

// ❌ Race condition with animations
await element.click();

// ✅ Wait for animation to complete
await element.click();
await expect(modal).toBeVisible();

// Iframes
const frame = page.frameLocator("#iframe-id");
await frame.getByRole("button").click();

// Shadow DOM - Playwright pierces by default, but for closed shadow:
await page.locator("custom-element").locator("internal:shadow=button").click();

Mobile & Viewport Testing

typescript
// In test file
test.use({ viewport: { width: 375, height: 667 } });

// Device emulation
import { devices } from "@playwright/test";
test.use({ ...devices["iPhone 13"] });

// Or in playwright.config.ts projects
projects: [
  { name: "desktop", use: { viewport: { width: 1280, height: 720 } } },
  { name: "mobile", use: { ...devices["iPhone 13"] } },
]

Debugging & Traces

bash
# Enable traces on failure (recommended for CI)
npx playwright test --trace on-first-retry

# View trace file
npx playwright show-trace trace.zip

# Debug mode - step through test
npx playwright test --debug

# Headed mode to see browser
npx playwright test --headed
typescript
// In playwright.config.ts
use: {
  trace: "on-first-retry",      // Capture trace on retry
  screenshot: "only-on-failure", // Screenshot on failure
  video: "retain-on-failure",    // Video on failure
}

CI/CD Configuration

typescript
// playwright.config.ts for CI
export default defineConfig({
  retries: process.env.CI ? 2 : 0,
  workers: process.env.CI ? 1 : undefined,
  reporter: process.env.CI
    ? [["html"], ["github"], ["junit", { outputFile: "results.xml" }]]
    : [["html"]],
  use: {
    trace: "on-first-retry",
    screenshot: "only-on-failure",
  },
});
yaml
# GitHub Actions example
- name: Run Playwright tests
  run: npx playwright test
- uses: actions/upload-artifact@v4
  if: always()
  with:
    name: playwright-report
    path: playwright-report/

Running Tests (PREFER PARTIAL RUNS)

Always prefer running specific tests over the entire suite for faster feedback:

bash
# Run ALL tests
npx playwright test

# ✅ PREFERRED: Run specific file
npx playwright test tests/login/login.spec.ts

# ✅ PREFERRED: Run specific folder
npx playwright test tests/login/

# ✅ PREFERRED: Run by test name (grep)
npx playwright test --grep "login"
npx playwright test --grep "user can sign up"

# ✅ PREFERRED: Run by tag
npx playwright test --grep "@critical"
npx playwright test --grep "@LOGIN-E2E-001"

# ✅ Run single test by line number
npx playwright test tests/login/login.spec.ts:42

# ✅ Run tests matching multiple patterns
npx playwright test --grep "login|signup"

# ✅ Exclude tests by pattern
npx playwright test --grep-invert "slow"
Other Commands
bash
npx playwright test --debug            # Debug mode (step through)
npx playwright test --headed           # See browser
npx playwright test --trace on         # Enable tracing
npx playwright test --project=mobile   # Run specific project
npx playwright codegen                 # Record tests

Partial String Matching (CRITICAL for Robustness)

Always use partial/pattern matching instead of exact strings to reduce maintenance:

typescript
// ❌ FRAGILE: Exact string matches break easily
await expect(page.getByText("Welcome to Our Application!")).toBeVisible();
await expect(page.getByRole("button", { name: "Submit Form" })).toBeVisible();
await expect(notification).toHaveText("Your account has been created successfully.");

// ✅ ROBUST: Partial matches survive copy changes
await expect(page.getByText(/welcome/i)).toBeVisible();
await expect(page.getByRole("button", { name: /submit/i })).toBeVisible();
await expect(notification).toContainText("account");
await expect(notification).toContainText(/created/i);

// ✅ ROBUST: Use toContainText over toHaveText
await expect(page.locator(".message")).toContainText("success");

// ✅ ROBUST: Pattern matching for dynamic content
await expect(page.getByText(/order #\d+/i)).toBeVisible();
await expect(page.getByText(/\d+ items? in cart/i)).toBeVisible();

Why Partial Matching:

  • ✅ Survives minor copy/text changes
  • ✅ Works across locales (case-insensitive)
  • ✅ Less brittle to whitespace changes
  • ✅ Easier to maintain long-term
  • ❌ Exact matches break on punctuation, capitalization, or wording tweaks

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

Files

Just SKILL.md in .agent/skills/e2e-tester of PageAI-Pro/ralph-loop.

Open the folder on GitHubat commit eba65eb

Compare with similar skills

E2E Tester 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.

E2E Tester compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
E2E Tester this skillPageAI-Pro/ralph-loop315—~4.3kAutomated safety check: NotesMIT
Playwright E2E Testsonyx-dot-app/onyx32k1 repos~2.8kAutomated safety check: NotesCustom licence
E2E VerificationChorus-AIDLC/Chorus1.2k—~1.5kAutomated safety check: NotesAGPL-3.0
Playwright Testingchongdashu/vibejam-starter-pack149—~2.2kAutomated safety check: PassNone
Frontend Playwright E2Eansible/ansible-ui113—~2.5kAutomated safety check: NotesApache-2.0
Playwright POM Discoverycomet-ml/opik22k—~4.4kAutomated safety check: PassApache-2.0

Similar skills

  • Playwright E2E Tests

    onyx-dot-app/onyx

    Write and maintain Playwright end-to-end tests for the Onyx application.

    32k GitHub starsUsed in 1 repo~2.8k tokens
    Testing & QAAuto-check: notes
  • E2E Verification

    Chorus-AIDLC/Chorus

    A skill your agent uses when manually verifying a Chorus frontend change in a real browser — finding local login credentials, driving the running dev server with the Playwright MCP, logging in…

    1.2k GitHub stars~1.5k tokensUpdated today
    Testing & QAAuto-check: notes
  • Playwright Testing

    chongdashu/vibejam-starter-pack

    Plan, implement, and debug frontend tests: unit/integration/E2E/visual/a11y.

    149 GitHub stars~2.2k tokensUpdated 5 mo ago
    Testing & QAAuto-check passed
  • Frontend Playwright E2E

    ansible/ansible-ui

    Write, run, and debug Playwright E2E / integration / live tests.

    113 GitHub stars~2.5k tokensUpdated today
    Testing & QAAuto-check: notes
  • Procedure for choosing stable selectors when building Page Object Models for the Opik E2E suite by exploring the live UI with the Playwright MCP.

    22k GitHub stars~4.4k tokensUpdated today
    Testing & QAAuto-check passed
  • Agentic Browser Testing

    petrkindlmann/qa-skills

    Goal-driven E2E testing where a browser agent (Playwright MCP / computer-use) reads a natural-language goal and explores the app via the accessibility tree to assert outcomes — no pre-written script.

    170 GitHub stars~4.5k tokensUpdated 4 mo ago
    Testing & QAAuto-check passed

More from PageAI-Pro/ralph-loop

  • Component Refactoring

    PageAI-Pro/ralph-loop

    Refactor high-complexity React components in frontend. An agent skill from PageAI-Pro/ralph-loop.

    315 GitHub stars~1.8k tokensUpdated 1 mo ago
    Auto-check passed
  • Vitest Best Practices

    PageAI-Pro/ralph-loop

    Comprehensive vitest testing patterns covering test structure, AAA pattern, parameterized tests, assertions, mocking, test doubles, error handling, async testing, and performance optimization.

    315 GitHub stars~1.2k tokensUpdated 1 mo ago
    Auto-check passed
  • Prd Creator

    PageAI-Pro/ralph-loop

    Guides creation of comprehensive Product Requirement Documents (PRDs) for software projects through structured questioning and validation, then generates implementation task lists in JSON format.

    315 GitHub stars~1.6k tokensUpdated 1 mo ago
    Auto-check: notes

Categories

Questions about E2E Tester

What does E2E Tester do?

Playwright E2E testing patterns. An agent skill from PageAI-Pro/ralph-loop. E2E Tester is an agent skill from PageAI-Pro/ralph-loop. Playwright E2E testing patterns.

When should I use E2E Tester?

E2E Tester fits situations like: tasks that involve End-to-end testing; tasks that involve Browser testing.

How do I install E2E Tester in Claude Code?

Run `npx skills add PageAI-Pro/ralph-loop --skill e2e-tester -a claude-code`. Or copy the skill folder (.agent/skills/e2e-tester in PageAI-Pro/ralph-loop) into .claude/skills/e2e-tester in your project. Claude Code loads it when a task matches its description.

How do I install E2E Tester in Codex?

Run `npx skills add PageAI-Pro/ralph-loop --skill e2e-tester -a codex`. Or copy the skill folder (.agent/skills/e2e-tester in PageAI-Pro/ralph-loop) into .agents/skills/e2e-tester in your project. Codex loads it when a task matches its description.

Can I use E2E Tester 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 PageAI-Pro/ralph-loop --skill e2e-tester -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/e2e-tester, .gemini/skills/e2e-tester, .github/skills/e2e-tester and .opencode/skills/e2e-tester in your project.

What does E2E Tester need to run?

Going by SKILL.md and its folder, E2E Tester needs the command-line tools its instructions call (npx). Its frontmatter pre-approves these tools: Read, Edit, Write, Glob, Grep, Bash, WebFetch, WebSearch, Task.

Does E2E Tester access the network?

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

Is E2E Tester safe to install?

Our automated static check of SKILL.md found notes only (pre-approves every shell command (allowed-tools: bash)), nothing it rates as a warning. It is not a guarantee. Review the folder before installing.

What licence does E2E Tester use?

E2E Tester 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 E2E Tester use?

About 4.3k tokens (SKILL.md is roughly 17k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to E2E Tester?

Skills that share tags, products or a category with E2E Tester: Playwright E2E Tests (onyx-dot-app/onyx, 32k stars), E2E Verification (Chorus-AIDLC/Chorus, 1.2k stars), Playwright Testing (chongdashu/vibejam-starter-pack, 149 stars) and Frontend Playwright E2E (ansible/ansible-ui, 113 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains E2E Tester?

PageAI-Pro (a GitHub organization) maintains it in PageAI-Pro/ralph-loop, which has 315 GitHub stars. The repository holds 4 skills in this directory. The repository was last updated on August 31, 2026.

Source: PageAI-Pro/ralph-loop on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.