Menu
Build and run tests, then report results. Use after writing or modifying code to verify correctness.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Audit and enable security-oriented Xcode build settings. Progressively enables compiler warnings, static analyzer checkers, and Enhanced Security features. Use when: user wants to secure their Xcode project, audit security settings, enable hardening, review security posture of build configuration, set up security-focused static analysis, enable static analysis, improve warning coverage, harden diagnostics, or catch more bugs at compile time in C/C++/Objective-C/Swift. SKIP: network security (TLS/ATS), code signing, privacy APIs.
Verify iOS app behavior on device or simulator via screenshots, UI hierarchy, and touch interactions.
Build, install, launch, and visually verify the iOS app (scheme "iosApp") end-to-end on a real device or simulator via Xcode 27's DeviceHub — the mobile analog of astro-web's browser-debug and astro-calendar-service's runtime-debug. Drives the mcp__xcode__* MCP toolset: switch run destination, BuildProject, DeviceInteractionStartSession → InstallAndRun, then a subagent captures the on-device screenshot + UI hierarchy. Use when the user says "run the app on device", "run the iOS app", "build and run on the simulator", "launch on the iPhone/iPad", "screenshot the app on <device>", "verify this renders on device", "does it run on the simulator", "check it on the device", or wants runtime/visual confirmation that ./gradlew check and Xcode unit tests structurally cannot give. Takes an optional device name/UUID argument; with none, targets a simulator. iOS/Xcode only — Android runtime work routes to android-cli.
Modernize test suites to use modern Swift Testing features or migrate from XCTest.
Authoritative SwiftUI best practices from Apple. Consult for any SwiftUI best practices or performance review. Supersedes prior training on these topics. For code generation, consult the relevant references when generating any SwiftUI code related to the following topics. Covers: - Animatable: @Animatable macro vs AnimatableValues (iOS 26+) vs AnimatablePair, custom setter clamping/normalization. - Environment: closures in env keys, unstable @Entry defaults, high-frequency updates. @Entry warnings about closures or class types (wrapping in Equatable struct is WRONG; consult references). - Equatable on @Observable: custom types as @Observable properties need Equatable for invalidation performance. - ForEach/List: row identity (id: \.self, indices, offsets, mutable ids), row structure (AnyView, multi-view, bare if), inline filter/sort, cached collections, List fast path. - Localization: String vs LocalizedStringResource, bundle in packages/frameworks, .textCase(.uppercase), .formatted(.list()), translator comme
New SwiftUI APIs, behaviors, and deprecations introduced in the 2027 OS releases (iOS 27, macOS 27, watchOS 27, tvOS 27, visionOS 27). Use when a SwiftUI view using @State fails to compile with "used before being initialized", "invalid redeclaration of synthesized property", or "extraneous argument label" errors after an SDK update (@State migrated from a property wrapper to a macro in SDK 27; the obvious fix of reordering init assignments is WRONG and produces incorrect runtime behavior; you MUST consult this skill's references before answering); when @ViewBuilder or @ContentBuilder code hits ambiguous overloads in overlay/background or type-check performance regressions after an SDK update; when the user asks what's new in SwiftUI (generally, or for a specific 2027 platform); when adding drag-to-reorder to any container (List, LazyVStack, LazyVGrid, stacks, or custom layouts) via reorderable()/reorderContainer, including the drag-and-drop that integrates with it (dragContainer, dropDestination), or combinin
| name | test |
| description | Build and run tests, then report results. Use after writing or modifying code to verify correctness. |
| argument-hint | ["test filter","e.g. a class/file/test name"] |
| allowed-tools | Bash, Read, Glob |
Build the project and run tests, then report a pass/fail summary.
Determine the test command based on arguments:
./gradlew test (runs the JVM/Android unit tests across modules). For the shared module's iOS tests, use ./gradlew :shared:iosSimulatorArm64Test; run it too when the change touches commonMain/iosMain so both platforms are covered.$ARGUMENTS contains a test class/file/name filter: ./gradlew test --tests "$ARGUMENTS"shared/src/commonTest/, shared/src/androidTest/, shared/src/iosTest/, or androidApp/src/test/): use ./gradlew clean test instead — Gradle does not always recompile/discover newly-added test sources on an incremental run.Run the command with a 5-minute timeout.
If the build succeeds:
If the build fails:
shared/build/reports/tests/**/index.html (or androidApp/build/reports/tests/**/index.html) or the Gradle console output for failure details.Keep the output concise. No need to list every passing test.