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.