e2e

Automate end-to-end UI validation for the kspec web interface with Playwright.

1|2|Updated Jan 16, 2026
One-click install
npx skills add https://github.com/kynetic-ai/kynetic-spec --skill e2e-kynetic-ai
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: e2e
Source: https://github.com/kynetic-ai/kynetic-spec/tree/main/.claude/skills/e2e
Command: npx skills add https://github.com/kynetic-ai/kynetic-spec --skill e2e-kynetic-ai

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

E2E testing for the kspec web UI ensures reliability of core flows by exercising daemon startup, UI interactions, and API verifications in a structured, isolated environment.

Core Features & Use Cases

  • Patterned end-to-end testing workflows using Playwright against the kspec UI
  • Isolated fixtures and daemon lifecycle to prevent cross-test interference
  • Guidance on selectors, URL assertions, and API verification for robust test suites

Quick Start

Initialize an isolated E2E testing environment for kspec and run the first Playwright-based test to validate the web UI.

Frequently Asked Questions about e2e

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write E2E tests for a web UI using Playwright?

E2E tests with Playwright automate web UI validation by interacting with selectors, asserting URL states, and verifying API response behaviors. Structured patterns isolate fixtures and manage daemon lifecycle to ensure reliable test execution.

What is the best way to isolate Playwright test fixtures from each other?

Isolating Playwright test fixtures requires managing the daemon lifecycle and setting up isolated environments for each test. This prevents cross-test interference and enforces strict boundaries for reliable UI test automation.

How do I verify API responses during a Playwright UI test?

Verifying API responses during Playwright UI tests involves asserting backend states alongside UI interactions. This pattern enforces best practices for selector reliability and backend verification within the E2E suite.

Why does my E2E test fail due to cross-test interference?

E2E test failure from cross-test interference occurs when fixtures and daemon states are not properly isolated. Using isolated test environments and managing the daemon lifecycle for each run prevents state bleeding across the test suite.

How do I manage daemon lifecycle during automated UI testing?

Managing daemon lifecycle during automated UI testing requires starting and stopping the daemon within isolated test environments. This structured approach ensures the web interface is ready before Playwright executes navigation flows.