How do I install the E2e Tests skill?

Run npx skillmds@latest add navikt/e2e-tests-2 in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is E2e Tests safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with E2e Tests?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is E2e Tests free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published E2e Tests?

navikt (@navikt) published this skill. Their other Agent Skills are listed on their SkillMD profile.

E2e Tests by navikt — Agent Skill

Name: E2e Tests
Author: navikt

E2e Tests

Create full-system tests that boot the application and prove an observable user or system flow. Use when the assembled app, its entry point and final outcome must work together; use `integration-tests` for a narrow real adapter without full application boot.

navikt d38861b 2.4 KB Updated Sep 17, 2026

File contents

E2E Tests

OpenCode v1: Skill names below are exact IDs from the active catalog, not slash commands. Load them with the native skill tool. Slash commands are direct user entry points only.

Prove one complete flow through the assembled application. Discover the repository's stack and test contract before selecting libraries, annotations, fixtures, or commands.

1. Discover the test contract

Inspect repository evidence in this order:

Existing E2E or system tests and their nearest configuration.
Build manifests, task or script definitions, and test-runner configuration.
Application entry points and local boot fixtures.
Existing infrastructure fixtures, container setup, tags, and CI commands.

Record the discovered application boot path, test framework and style, fixture lifecycle, E2E classification mechanism, and exact focused/full commands. Do not infer Gradle, Kotest, Ktor, Jest, Playwright, Testcontainers, or any other stack choice from this skill.

If no E2E convention exists, present the smallest option compatible with the detected build and runtime and get approval before adding framework or build configuration.

2. Choose the flow and boundaries

Test one user or system flow through the running application.
Enter through a production-shaped boundary such as HTTP, UI, CLI, or message ingestion.
Assert externally observable outcomes, not internal calls.
Use real infrastructure only where a substitute would hide the contract; reuse the repository's fixture strategy when one exists.
Keep data deterministic and free of real personal data or secrets.

3. Implement in the repository's style

Follow the discovered framework, naming, tags, directories, lifecycle, and helpers. Make setup visible enough that the flow remains readable. Cover the relevant success and failure state without turning one E2E test into a complete test suite.

4. Verify

Run the discovered focused E2E command first, then the repository's broader E2E gate when proportionate. Report the exact commands, exit codes, and relevant output. Completion requires fresh evidence that the test entered the assembled application and observed the intended outcome.

---name: e2e-tests-2description: Create full-system tests that boot the application and prove an observable user or system flow. Use when the assembled app, its entry point and final outcome must work together; use `integration-tests` for a narrow real adapter without full application boot.---# E2E Tests> **OpenCode v1:** Skill names below are exact IDs from the active catalog, not slash commands. Load them with the native `skill` tool. Slash commands are direct user entry points only.Prove one complete flow through the assembled application. Discover therepository's stack and test contract before selecting libraries, annotations,fixtures, or commands.## 1. Discover the test contractInspect repository evidence in this order:1. Existing E2E or system tests and their nearest configuration.2. Build manifests, task or script definitions, and test-runner configuration.3. Application entry points and local boot fixtures.4. Existing infrastructure fixtures, container setup, tags, and CI commands.Record the discovered application boot path, test framework and style, fixturelifecycle, E2E classification mechanism, and exact focused/full commands. Donot infer Gradle, Kotest, Ktor, Jest, Playwright, Testcontainers, or any otherstack choice from this skill.If no E2E convention exists, present the smallest option compatible with thedetected build and runtime and get approval before adding framework or buildconfiguration.## 2. Choose the flow and boundaries- Test one user or system flow through the running application.- Enter through a production-shaped boundary such as HTTP, UI, CLI, or message ingestion.- Assert externally observable outcomes, not internal calls.- Use real infrastructure only where a substitute would hide the contract; reuse the repository's fixture strategy when one exists.- Keep data deterministic and free of real personal data or secrets.## 3. Implement in the repository's styleFollow the discovered framework, naming, tags, directories, lifecycle, andhelpers. Make setup visible enough that the flow remains readable. Cover therelevant success and failure state without turning one E2E test into a completetest suite.## 4. VerifyRun the discovered focused E2E command first, then the repository's broaderE2E gate when proportionate. Report the exact commands, exit codes, and relevantoutput. Completion requires fresh evidence that the test entered the assembledapplication and observed the intended outcome.

Frequently asked questions