e2e-evidence

Select Playwright test tiers and capture passed-count evidence for plan close-out.

2|Updated Apr 2, 2026
One-click install
npx skills add https://github.com/jonaseck2/slaktforskning --skill e2e-evidence
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: e2e-evidence
Source: https://github.com/jonaseck2/slaktforskning/tree/main/.claude/skills/e2e-evidence
Command: npx skills add https://github.com/jonaseck2/slaktforskning --skill e2e-evidence

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill prevents weak or misleading end-to-end closure by telling you exactly which Playwright tier to run and what test output counts as real evidence before archiving.

Core Features & Use Cases

  • Playwright tier selection: Decide between Tier 1 (boot, crud, website-export, duplicates) and Tier 2 (adds panels, reactivity, imports) based on what user-facing goal your plan touches.
  • Evidence-based close-out guidance: Ensure your close-out notes include the actual tail lines from test runs (e.g., “N passed”) rather than summaries or claims.
  • Failure ownership discipline: When [boot] / [crud] / [panels] / [reactivity] / [imports] fail or are flaky, route the fix to the owning plan or require a separate plan explicitly covering the fix before archive.
  • Project-to-user-goal mapping: Know which Playwright project name protects which user-observable surface so you can route new specs correctly.

Quick Start

Decide which tier fits your change and paste the required “npm run test:e2e” and, if needed, “npm run test:e2e:full” tail output lines into your plan close-out evidence.

Frequently Asked Questions about e2e-evidence

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

FAQPage Schema
How do I decide which Playwright e2e tests to run before closing out a plan?▼

Playwright tier selection for plan close-out depends on which user goals your changes touch. Tier 1 always runs across boot, crud, website-export, and duplicates, while Tier 2 adds panels, reactivity, and imports when those specific UI surfaces are modified.

What counts as valid e2e test evidence for CI release gating?▼

Valid e2e test evidence for CI release gating requires the actual passed-count tail lines from your test command runs, such as the specific "N passed" output, rather than subjective summaries or claims of success in your close-out notes.

How do I triage CI failures by Playwright project tags like boot or crud?▼

Triage CI failures by Playwright project tags like boot, crud, panels, reactivity, or imports by routing the fix to the owning plan before archive, or by requiring a separate plan explicitly covering the fix.

Do I need to run test:e2e:full if my changes only touch basic crud operations?▼

If your changes only touch basic crud operations, running test:e2e alone suffices because Tier 1 deterministically covers boot, crud, website-export, and duplicates. You only need test:e2e:full for Tier 2 when UI, panels, data-changed, or importer user goals are touched.

When should I not archive a plan after running Playwright e2e tests?▼

You should not archive a plan after running Playwright e2e tests if the close-out lacks the actual tail line passed-counts from the test commands, or if project-tagged failures remain flaky without a separate fix plan.

How do I map a new e2e spec to the correct Playwright project for genealogy app testing?▼

Map a new e2e spec to the correct Playwright project by matching the user-observable surface it protects—such as boot, crud, panels, reactivity, or imports—to the project-to-user-goal mapping before adding the spec to that tier.