apple-browsers: Skill for Claude Code

verify-ios

Proves iOS behavior in the real app. You write a proof: a short Python file for this one change, saved with its evidence and never committed. prove checks it, runs it on each device, captures evidence, and always cleans up.

V=.claude/skills/verify-ios/bin/verify-ios      # from the worktree root; every example below uses $V

How it gets used. Only when someone asks for it: agents never pick it on their own (disable-model-invocation), and nothing in the repo's agent instructions points to it. With AStack's auto, name it when you start, for example "/auto fix … and use verify-ios to verify" (auto honours an explicitly named driver). Outside auto, invoke /verify-ios directly.

Before writing a proof, read the feature files in features/ for what you are changing: they list the real ids, the iPhone/iPad differences and the app quirks that make a naive proof fail.

Layers

proof (Python, throwaway, in the evidence folder)
  └─ library  lib/verify_ios: steps.py (DuckDuckGo steps), harness.py (the `ios` handle, assertions, prove)
       ├─ driver.py → runner/ (Swift XCUITest runner, generic: find, tap, type, wait, alert…) → the app's UI
       └─ web.py → the app's AutomationServer → page content (read-back and setup only)
bin/verify-ios: command line over the same library, for setup and for exploring by hand

Only driver.py knows how the UI is driven. A different driver means a new class with the same methods, which must pass tests/must_fail.py before it is used.

Check it works here

$V selftest                    # both devices; --devices iphone for a quicker check

Sets up the simulators, builds the app and runner if the build isn't current (a first build takes 3–20 minutes), runs the tool's tests, the "must fail" trust checks and one worked proof on each device, and confirms nothing was left running. Ends with "ok": true and the report paths, or names the step that failed and why. Run it on a new Mac, a new checkout, or after an Xcode update.