Use this skill whenever a user wants to validate, review, or audit e2e tests that have been migrated from an old framework (typically in a `e2e-next/` directory) to the new `e2e-next/` framework. Triggers include: "review my migrated test", "validate this e2e test", "check my test migration", "did I migrate this correctly", "review e2e PR", "check test coverage after migration", or any request involving comparing old vs new e2e test files across the vcluster, vcluster-pro, or loft-enterprise repos. Always use this skill when an e2e test file or PR from one of these repos is provided for review — even if the user just says "take a look at this test".
A skill for exhaustively reviewing e2e tests migrated from the old framework (next/ directory)
to the new framework (e2e-next/ directory) across the vcluster, vcluster-pro, and
loft-enterprise repositories.
The user will provide one or more of:
If only the new test is provided (no original), you must locate the original yourself using the local repo tools (see Repo Access).
Use the local repo MCP tools to inspect implementation details and locate source files. All three repos may be relevant depending on the test subject:
| Repo | Use when |
|---|---|
vcluster | Core vcluster functionality, open-source features |
vcluster-pro | Pro/enterprise vcluster features |
loft-enterprise | Loft platform, multi-tenancy, UI-level features |
When reviewing a test, always look up the actual implementation being tested in the relevant repo before drawing conclusions about correctness or coverage. Do not rely solely on what the test itself asserts.
Follow these steps in order for every migration review:
If the original (next/) test was not provided:
Using the repo MCP tools:
Verify the structural correctness of the migration:
e2e-next/ directory structurebeforeAll, afterAll, beforeEach, afterEach) are correctly
translated — no leftover old-framework teardown patternspage, context, request) are used correctlyFor each test case in the migrated file:
expect(x).toBeDefined() with no deeper check)await, missing retries on flaky operationsThis is the most important step. Compare the implementation (Step 2) against the test suite.
For every distinct behavior, code path, and configurable option in the implementation:
For each gap, suggest a concrete additional test case including:
Common gap categories to check explicitly:
Produce all three of the following output sections:
Go through the migrated test file and annotate specific lines or blocks with numbered
comments. Format as a fenced code block with inline // [N] ... annotations, followed by
a numbered legend below it explaining each annotation.
Example:
// [1] Missing: should also assert that the old resource was deleted
await expect(newResource).toBeVisible();
// [2] Race condition: no retry/wait before asserting pod readiness
expect(pod.status).toBe('Running');
Legend:
Running immediately; use waitForCondition## Migration Checklist — <test file name>
### Framework Migration
- [x] Correct directory structure
- [x] New framework imports
- [ ] ⚠️ Teardown uses old-framework pattern on line 42
### Correctness
- [x] Assertions are meaningful
- [ ] ⚠️ Test "should reject invalid config" passes even with valid config (line 87)
### Coverage Gaps
- 🔴 No test for RBAC: non-admin user attempting privileged operation
- 🟡 No test for concurrent resource creation
- 🟢 No test for audit log output (low risk)
### Code Quality
- [ ] ⚠️ Duplicate setup block (lines 12–25 and 61–74) — extract to beforeEach
- [x] Naming is clear and consistent
A copy-paste-ready GitHub PR review comment in Markdown. Structure:
## E2E Migration Review
**Overall:** ✅ Approved with suggestions / ⚠️ Changes requested / ❌ Major issues found
### Summary
<2–3 sentence high-level assessment>
### Issues
#### 🔴 Must Fix
- ...
#### 🟡 Should Fix
- ...
#### 🟢 Nice to Have
- ...
### Suggested Additional Tests
- **Test:** `<descriptive test name>`
**Scenario:** <what to set up>
**Assert:** <what to check>
<repeat for each suggested test>
### Nits
- ...
For the reviewer using this skill: If you know the specific old and new frameworks involved in this migration, add them here so Claude can apply framework-specific checks.
Example entries:
- Old:
@vcluster/e2ecustom test runner → New: Playwright +@vcluster/e2e-nextfixtures- Old: Ginkgo/Gomega (Go) → New: Playwright (TypeScript)
- Old: Custom shell-script harness → New: Playwright with kubectl helpers
Until this section is filled in, Claude will infer the frameworks from the provided files.