Menü
>-
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
Shrink a media asset to the smallest bytes that still serve its purpose, keyed on asset kind (raster, vector, animation, video, audio, model, document, font) and on where it will be presented. Detects and acquires the right binary from a central tool manifest, runs a lossless-or-lossy pass decided by fidelity intent, measures before and after, validates the output, and keeps the result only if it is smaller AND still valid, redirecting to a better format or a different kind when the source is wrong for the job (a no-alpha PNG-24 wants JPEG or WebP; an over-long GIF wants video). Optimizes one file or walks a whole repository. Use for "optimize/compress this image, gif, svg, video, audio, 3D model, or web font", "shrink a PNG", "which format should this asset be", or "make these assets smaller". Skip when the asset is already minimal, when the bytes must stay bit-exact for a reason other than size, or when a build-time plugin (a bundler image loader, expo-optimize) already optimizes it in the pipeline.
Drive an iOS Simulator headlessly on macOS: discover and boot a device, install and launch an app, drive its UI by accessibility (AXe) rather than brittle coordinates, capture screenshots, and navigate the simulator's own chrome, menus, and execution modes. The iOS analog of android-emulator-harness and playwright-harness. Project-agnostic core; Expo/React-Native specifics live in expo-ios-simulator, and "make the app driveable" lives in mobile-accessibility. Use for any task that is "boot/run an iOS simulator", "drive an iOS screen", "screenshot the simulator", or "automate an iOS flow".
Run and drive an Expo / React Native app on the iOS Simulator. Pick an execution mode (Expo Go, dev client, Storybook-mobile, web-on-mobile), build and install a dev client, and clear the recurring Expo/RN prompts that block automation: the push-token alert that stacks until the overlay darkens the screen, the "Open in app?" deep-link dialog, the dev menu, and the element-inspector trap. Sits ON TOP of ios-simulator; failures route to ios-simulator-triage. Project-agnostic; discovers bundle id and scheme from the app config. Use for "run my Expo app on the simulator", "load a dev client", or "drive Storybook on iOS".
Diagnose and recover from failures when building, running, or driving an app on the iOS Simulator. A living catalog organized by layer: build failures (xcodebuild, CocoaPods, signing, codegen), runtime failures split into app-runtime vs Expo-runtime (the red error overlay), and automation failures that emit no error (element not found in the accessibility tree, stuck flow). Each layer names where its logs live. Used alongside ios-simulator and expo-ios-simulator when something breaks. Project-agnostic.
Read and use the Expo / React Native in-app developer tools: the developer menu (reload, go home, performance monitor, element inspector, Open DevTools, and fast refresh) and React Native DevTools (Console, Sources, Network, Memory, Performance, Components, and Profiler), plus Rozenite plugins. The tools are identical on iOS and Android; only the gesture that opens the menu differs, so this skill is the shared home referenced by both the iOS-simulator and Android-emulator skills. This is the reference for reading these tools (what each shows and how to interpret it), not a driver. Use for "open the Expo dev menu", "read the performance monitor", "use the element inspector", or "inspect a component / a slow re-render with React Native DevTools".
Capture proof of a driven iOS-simulator flow: vision-verifiable screenshots, video (mp4), and a manifest tying steps to artifacts, plus an honest list of what a simulator cannot do (deliver a push, use a real camera, place a call, fully observe the network). Produces artifacts to a contract that a separate GitHub-presentation skill consumes; this skill owns extraction, not publishing. Sits beside ios-simulator; project-agnostic. Use for "capture evidence of an iOS flow" or "record the simulator".
| name | mobile-accessibility |
| description | >- |
Why its own skill: the same tags serve two consumers (driving vs auditing); owning them here keeps both DRY. Driving skills read the handle; auditing skills read the semantics.
An accessible app exposes an accessibility tree: a hierarchy of elements that assistive technology (VoiceOver) navigates, and that an automation driver (AXe) reads to find and tap things. Every element can carry a few fields. Two of them matter most, and they exist for different reasons:
| Field (iOS) | React Native prop | Who reads it | What it is for |
|---|---|---|---|
accessibilityIdentifier | testID | the driver | a stable handle to find an element in a script |
accessibilityLabel | accessibilityLabel | the human (VoiceOver) and the auditor | the element's name, spoken aloud |
Apple draws this line itself: an identifier lets a script "uniquely identify an element"
and thereby "avoid inappropriately setting or accessing an element's accessibility label"
(accessibilityIdentifier docs). React Native's testID is the same idea from the other
side: "Used to locate this view in end-to-end tests." The label, by contrast, is "a
string that succinctly identifies the accessibility element" for a user; Apple's example
is "Save," not "Save button."
So:
testID -> accessibilityIdentifier; it does not
change when copy, locale, or layout changes. Tapping by visible label is the fallback
when no handle exists. Coordinates are the last resort (brittle; see ios-simulator
references/driving.md).references/ios-native.md.references/react-native-expo.md.references/auditing.md.testID) for driving; fall back to the label; avoid coordinates.Web a11y -> future web-accessibility. Cross-platform auditing -> future accessibility. Android specifics -> android-emulator-harness lineage.