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.