← ClaudeAtlas

e2e-manual-debugginglisted

Use this skill when an e2e scenario can't find a UI element — `iosTap`/`iosWaitForElement`/`macClickButton`/`macWaitForElement` keeps timing out, you don't know the right `ElementQuery` to use, you need to know what `AXLabel` / `AXIdentifier` / `.help()` / `accessibilityLabel` a button actually exposes, or `iosLogUI` output isn't enough. This skill boots an interactive e2e-mode instance of the apps and walks through inspecting the running UI (XCUITest view hierarchy, AppleScript accessibility tree, Xcode's Accessibility Inspector, on-the-fly screenshots) to discover the exact attributes a scenario step needs. Use whenever someone says "I can't find this element", "what's the right query for X", "the test can't see Y", "what label does the macOS button expose", "find the accessibility identifier", or "the button isn't being clicked". Do NOT use this skill for writing new scenarios from scratch (use e2e-for-feature) or running/fixing scenarios when the issue isn't an unknown element (use e2e-testing).
gpambrozio/Gallager · ★ 3 · Code & Development · score 69
Install: claude install-skill gpambrozio/Gallager
# E2E Element Discovery (Manual Inspection) When `e2e-testing` or `e2e-for-feature` writes a step that can't find its element, the loop "guess label → run scenario → fail → guess again" is slow and brittle. This skill is the shortcut: boot an e2e-mode instance of the app, navigate to the state the scenario expects, and read the actual accessibility tree to discover the exact label, identifier, role, or `.help()` text the step should target. ## When this skill applies You're in this skill if any of these are true: - `iosTap(.label("..."))` / `iosWaitForElement(...)` keeps timing out and you don't know what label/identifier the SwiftUI view actually exposes. - `macClickButton(titled: "...")` / `macWaitForElement(titled: "...")` can't find a button — could be a `.help()` text, an `accessibilityLabel`, or no exposure at all. - A scenario worked yesterday and stopped working after a UI change; you need to find the new label. - You're writing a new scenario and want to discover identifiers up front, before guessing. - `iosLogUI` dumps the tree but you can't tell which entry corresponds to the on-screen control you care about. If you're not stuck on element discovery — for example, you're writing a scenario, reproducing a test failure caused by a logic bug, or comparing baselines — go back to `e2e-testing` / `e2e-for-feature` / `baseline-review` instead. ## Workflow at a glance 1. **Boot interactive e2e mode**, optionally landing in the state of an existing scenario. 2. **Dri