agentleFS
redhat-developerredhat-developer/rhdh/.claude/skills/e2e-verify-fix/SKILL.md

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
  1. Distinctive:

    Verify that the test fix works reliably and passes all code quality checks.

    line 9
  2. Very specific:

    Use this skill after implementing a fix (via e2e-diagnose-and-fix) to confirm the fix works before submitting a PR.

    line 13
  3. Distinctive:

    Always use the Playwright healer agent for test verification.

    line 17
  4. Very specific:

    If not already initialized in this session, initialize the healer agent in e2e-tests/:

    line 23
  5. Very specific:

    If it fails, go back to e2e-diagnose-and-fix and iterate — use the healer agent there too for the fix.

    line 55
  6. Distinctive:

    Run the test 5 times consecutively to verify no flakiness was introduced:

    line 59
  7. Distinctive:

    Run the full project to confirm the fix holds under CI-like concurrency:

    line 81
  8. Distinctive:

    IMPORTANT: Never skip verification steps.

    line 92
  9. Distinctive:

    Run all code quality checks in the e2e-tests workspace:

    line 96
  10. Very specific:

    Use the current scripts from e2e-tests/package.json.

    line 114
  11. Distinctive:

    If the fix touches shared utilities or page objects, run the entire Playwright project to check for regressions:

    line 130
  12. Distinctive:

    Before submitting, review all changes:

    line 145
  13. Distinctive:

    Only intended files were changed

    line 153
  14. Distinctive:

    No secrets or credentials were added

    line 154
  15. Distinctive:

    No unrelated changes were included

    line 155
  16. Distinctive:

    After verification, produce a summary:

    line 161

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.sh for 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=claude

See 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") during e2e-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=0

Set 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:unit

Use 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 fmt

5. 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=0

This 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 --stat

Verify:

  • 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/NO

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.