levels-system

Guides system, E2E, and acceptance testing with coverage criteria and step-by-step procedures.

Updated Jun 24, 2026
One-click install
npx skills add https://github.com/Hakkadaikon/hymme --skill levels-system-hakkadaikon
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: levels-system
Source: https://github.com/Hakkadaikon/hymme/tree/main/skills/levels-system
Command: npx skills add https://github.com/Hakkadaikon/hymme --skill levels-system-hakkadaikon

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams often struggle to decide what to verify at the whole-system level: which requirements need a system test, which user flows deserve an E2E scenario, and how to prove acceptance criteria are actually covered. This Skill provides structured guidance for the broad-confirmation layer of testing so nothing critical is left unverified and nothing trivial bloats the suite. ## Core Features & Use Cases - System Testing Guidance: Enumerate functional and non-functional requirements (performance, security, availability, data integrity) and assign one representative end-to-end scenario per requirement. - E2E Testing with Playwright: Select business-critical user flows, write minimal through-scenarios using role/label selectors and auto-waiting, and cap scenario counts to keep CI fast. - Acceptance Testing (UAT): Build a traceability table mapping each agreed acceptance criterion to exactly one test written in business vocabulary. - Use Case: Before a release, use this Skill to list all functional and non-functional requirements, confirm each has a representative scenario, and verify no acceptance criterion lacks a corresponding test. ## Quick Start Ask the AI to apply the levels-system skill to design system, E2E, and acceptance tests for your release requirements.

Frequently Asked Questions about levels-system

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

FAQPage Schema
How do I decide what to cover in system testing?▼

System testing should cover functional and non-functional requirements (performance, security, availability, data integrity) with one representative end-to-end scenario each. Branch-level coverage belongs to lower layers like unit and integration tests.

How many E2E tests should a project have?▼

E2E tests sit at the top of the test pyramid, so keep only business-critical flows, one through-scenario per flow. Set a scenario count limit based on CI time budget and push input variations down to unit or component tests.

How do I write acceptance tests with traceability?▼

Assign each agreed acceptance criterion a unique ID, then build a table mapping criterion ID, criterion text, test name, and status. Keep a strict one-to-one mapping so a failing test identifies exactly which agreement was broken.

Why are my Playwright E2E tests flaky?▼

Flakiness usually comes from fixed waits like waitForTimeout and CSS selector dependencies. Use role and label-based element queries with auto-waiting assertions such as expect(locator).toBeVisible() instead.

When should I not use system or E2E tests?▼

Avoid these levels for debugging individual logic or exhaustively covering input variations and boundary values; they are slow and hard to isolate. Send equivalence partitioning and edge cases to unit or integration tests instead.