e2e-verify-fix
Skill171 starsChanged 20 days agoApache-2.0View on GitHub
Verify an E2E test fix by running the test multiple times and checking code quality
- Reads credentials
We split this skill into the rules it gives an agent
16 rules. About 0 are common, 12 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈12
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 9
Verify that the test fix works reliably and passes all code quality checks.
- Very specific: line 13
Use this skill after implementing a fix (via e2e-diagnose-and-fix) to confirm the fix works before submitting a PR.
- Distinctive: line 17
Always use the Playwright healer agent for test verification.
- Very specific: line 23
If not already initialized in this session, initialize the healer agent in e2e-tests/:
- Very specific: line 55
If it fails, go back to e2e-diagnose-and-fix and iterate — use the healer agent there too for the fix.
- Distinctive: line 59
Run the test 5 times consecutively to verify no flakiness was introduced:
- Distinctive: line 81
Run the full project to confirm the fix holds under CI-like concurrency:
- Distinctive: line 92
IMPORTANT: Never skip verification steps.
- Distinctive: line 96
Run all code quality checks in the e2e-tests workspace:
- Very specific: line 114
Use the current scripts from e2e-tests/package.json.
- Distinctive: line 130
If the fix touches shared utilities or page objects, run the entire Playwright project to check for regressions:
- Distinctive: line 145
Before submitting, review all changes:
- Distinctive: line 153
Only intended files were changed
- Distinctive: line 154
No secrets or credentials were added
- Distinctive: line 155
No unrelated changes were included
- Distinctive: line 161
After verification, produce a summary:
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Verify Fix
Verify that the test fix works reliably and passes all code quality checks.
When to Use
Use this skill after implementing a fix (via e2e-diagnose-and-fix) to confirm the fix works before submitting a PR.
MANDATORY: Use the Playwright Healer Agent for Verification
Always use the Playwright healer agent for test verification. The healer provides step-by-step debugging if a run fails, making it faster to iterate on fixes.
Note: The Playwright healer agent is currently supported in OpenCode and Claude Code only. In Cursor or other tools without Playwright agent support, skip the healer initialization and use
local-test.shfor all verification steps.
Healer Initialization
If not already initialized in this session, initialize the healer agent in e2e-tests/:
cd e2e-tests
# For OpenCode
npx playwright init-agents --loop=opencode
# For Claude Code
npx playwright init-agents --loop=claudeSee https://playwright.dev/docs/test-agents for the full list of supported tools and options. The generated files are local tooling — do NOT commit them.
Export BASE_URL and an unlocked BW_SESSION. Set K8S_CLUSTER_URL and
K8S_CLUSTER_TOKEN for cluster-aware tests and the corresponding deployed namespaces
(NAME_SPACE, NAME_SPACE_RBAC, or NAME_SPACE_RUNTIME). Run local verification through
local-test.sh; do not generate a .env file containing secrets.
Verification Steps
1. Single Run Verification via Healer
Invoke the healer agent to run the fixed test once:
Task: "You are the Playwright Test Healer agent. Verify a fix by running the test once.
Working directory: <path>/e2e-tests
Run: ./local-test.sh -- --project=any-test --retries=0 --workers=1 "$SPEC_FILE" -g "$TEST_NAME"
If it passes, report success. If it fails, examine the error and report what went wrong."If it fails, go back to e2e-diagnose-and-fix and iterate — use the healer agent there too for the fix.
2. Multi-Run Stability Check
Run the test 5 times consecutively to verify no flakiness was introduced:
cd e2e-tests
PASS=0; FAIL=0
for i in $(seq 1 5); do
echo "=== Stability run $i/5 ==="
if ./local-test.sh -- --project=any-test --retries=0 --workers=1 "$SPEC_FILE" 2>&1; then
PASS=$((PASS + 1))
else
FAIL=$((FAIL + 1))
fi
done
echo "Stability results: $PASS/5 passed"Acceptance criteria: 5/5 passes. If any run fails, invoke the healer agent on the failing run to diagnose and fix the remaining issue — do not manually guess at fixes.
3. Full Project Stability Check
When to run: This step is required if the failure was only reproducible when running the full CI project (
CI=true ./local-test.sh -- --project="$CI_PROJECT") duringe2e-reproduce-failure. If the failure reproduced in isolated single-test runs, this step is optional but still recommended.
Run the full project to confirm the fix holds under CI-like concurrency:
cd e2e-tests
CI=true ./local-test.sh -- --project="$CI_PROJECT" --retries=0Set CI_PROJECT to the project from the CI failure (e.g., showcase, showcase-rbac). This verifies the fix under the same worker count and test interaction conditions that triggered the original failure.
Acceptance criteria: The full project run must pass. If the fixed test still fails when run alongside other tests, the fix is incomplete — return to e2e-diagnose-and-fix.
IMPORTANT: Never skip verification steps. If you cannot run tests (e.g., no cluster available, environment issues), stop and ask the user for explicit approval before proceeding without verification. Do not assume it's OK to skip.
4. Code Quality Checks
Run all code quality checks in the e2e-tests workspace:
cd e2e-tests
# Oxlint
yarn lint
# Oxfmt formatting
yarn fmt:check
# Shell scripts
yarn shellcheck
# Unit and runner regression tests when shared utilities or runners changed
yarn test:unitUse the current scripts from e2e-tests/package.json. There is no tsc:check
script in this workspace; do not report a compilation check that was not run.
For changes under .ci/, also run the applicable checks from .ci/package.json.
Fix any issues found:
# Auto-fix lint issues
yarn lint:fix
# Auto-fix formatting
yarn fmt5. Optional: Full Project Regression Check
If the fix touches shared utilities or page objects, run the entire Playwright project to check for regressions:
cd e2e-tests
./local-test.sh -- --project="$PROJECT" --retries=0This is optional for isolated spec file changes but recommended for changes to:
e2e-tests/playwright/utils/(utility classes)e2e-tests/playwright/support/(page objects, selectors)e2e-tests/playwright/data/(shared test data)playwright.config.ts(configuration)
6. Review the Diff
Before submitting, review all changes:
git diff
git diff --statVerify:
- Only intended files were changed
- No secrets or credentials were added
- No unrelated changes were included
- Component annotations are present in any new/modified spec files
- Semantic selectors are used (no deprecated CSS class selectors)
Result Summary
After verification, produce a summary:
Fix Verification Results:
- Test: <spec-file> (<project>)
- Single run: PASS
- Stability (5 runs): 5/5 PASS
- Oxlint: PASS/FAIL
- Oxfmt: PASS/FAIL
- ShellCheck: PASS/FAIL
- Unit tests (when applicable): PASS/FAIL/NOT RUN
- Files changed: <list>
- Ready for PR: YES/NOIn this repository20 other files it gives its agents.
- .cursor/rules/add_extension_metadata.mdcCursor rule
- .cursor/rules/ci-e2e-testing.mdcCursor rule
- .cursor/rules/e2e-coverage-imports.mdcCursor rule
- .cursor/rules/e2e-fix-workflow.mdcCursor rule
- .cursor/rules/github-workflows-security.mdcCursor rule
- .cursor/rules/managing-ai-rules.mdcCursor rule
- .cursor/rules/playwright-locators.mdcCursor rule
- e2e-deploy-rhdhSkill
- e2e-diagnose-and-fixSkill
- e2e-parse-ci-failureSkill
- e2e-reproduce-failureSkill
- e2e-submit-and-reviewSkill
- patch-backstageSkill
- e2e-deploy-rhdhSkill
- e2e-diagnose-and-fixSkill
- e2e-parse-ci-failureSkill
- e2e-reproduce-failureSkill
- e2e-submit-and-reviewSkill
- e2e-verify-fixSkill
- patch-backstageSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

