Install any skill in seconds. Free to start, no credit card required.
Get Started Free →kc1t/e2e-app-testing
Real click/typing WebdriverIO e2e toolkit for the Alethe desktop app — use whenever the user asks to test, explore, click through, or verify a feature in the running Alethe UI (not unit/Rust tests). Covers generic navigation tools, a saved-procedure registry, and the specific flows already mapped (onboarding, project creation, git init, agent/merge settings).
Passed 15 of 20 test cases with the skill, and 3 of 20 without it.
and 18 more in the full report
15 fixed3 passed either way6 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 15 test cases the skill fixed. Same model, same prompt, with and without the skill.
I want to manually explore and test a new UI flow without creating a permanent test spec in our CI pipeline. Which file is designated for disposable ad-hoc test scripts?
| Checked | Without skill | With skill |
|---|---|---|
| Identifies e2e/specs/_sandbox.spec.ts as the disposable spec for ad-hoc exploration. | Missed | Passed |
The instructions your model reads when the skill loads.
This skill exists so that any Claude Code session (not just the one that wrote it) can
test the app by really clicking/typing in the UI, without needing to rediscover from scratch how
the test environment works. See the full history in docs/CHANGELOG.md (the "Tests" section) and
in the comments of each file cited below — this is just the map of "what exists and how to use it."
Every test in this suite interacts with the real UI via WebDriver click/typing — never via
window.__ALETHE_E2E__ to trigger an action (create project, open terminal, etc.). That hook
exists only to read state the UI already created (window.__ALETHE_E2E_QUERY__,
window.__ALETHE_E2E_STORE_DEBUG__) — never for actions. Reason: a hook can "work" even with
the real on-screen button broken, masking real UI bugs (it has already happened in this suite more
than once — see CHANGELOG).
e2e/support/launch.ts already takes care of this via
ALETHE_APP_DATA_DIR (a fully isolated profile from the user's real profile, created from scratch
on every run). Never bypass this.src/** changed since the last build, rebuild both stages before running
e2e, otherwise the test silently runs against stale code:
npm_config_script_shell=cmd npm run build
CARGO_TARGET_DIR=target-e2e npm_config_script_shell=cmd npx tauri build --debug --no-bundle
Get-Process alethe) — only kill whatever is
at target-e2e\debug\alethe.exe; the process at target\debug\alethe.exe is the user's real
app (npm run app), NEVER touch it.npx wdio run e2e/wdio.conf.ts --spec e2e/specs/<file>.spec.ts. Run it in the
FOREGROUND (without redirecting to background) if the user wants to watch the window
live — moving it to background puts the window in a session without an interactive desktop,
invisible to them (a real bug already diagnosed in this session).e2e/support/uiKit.ts — generic, for any screenclickByText(text, opts?) — clicks ANY button/link/[role=button] whose visible texttest cases passed, vs 3 / 20 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.