القائمة
Run pure-logic unit tests — Kotlin (Kotest on JVM host) and Swift (Swift Testing in iosAppTests/Unit/). Use to validate non-UI logic changes. For iOS view tests, use run-ui-tests instead.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Convert acceptance criteria, Jira tickets, Gherkin scenarios, PRDs, or any product requirements into a structured spec template. Use when translating PM artifacts into actionable specs for add-*, update, migrate, or remove skills.
Scaffold a complete new feature module with all 6 submodules, source files, tests, fakes, and AGENTS.md. Use when adding an entirely new feature to the app.
Execute cross-cutting migrations — library swaps, pattern changes, API version upgrades, or architecture refactors. Handles phased rollout, coexistence, and rollback planning.
Reverse-engineer a spec from existing code — reconstructs presumed acceptance criteria, data flow, API contracts, UI states, and business rules by reading source, tests, and git history. Use when inheriting undocumented features, onboarding onto unfamiliar code, or preparing for a refactor.
Modify existing feature code across all affected layers — domain models, data, presentation, tests, and fakes. Use when changing behavior, adding fields, or enhancing existing features.
Verification pipeline with three scopes — diff (default, changed modules only), full (whole project lint + unit + arch + builds), and all (every test level + every variant + full assemble). Use after any code change.
| name | run-unit-tests |
| description | Run pure-logic unit tests — Kotlin (Kotest on JVM host) and Swift (Swift Testing in iosAppTests/Unit/). Use to validate non-UI logic changes. For iOS view tests, use run-ui-tests instead. |
After modifying any Kotlin source files in impl/domain, impl/data, or impl/presentation modules, or Swift pure-logic files (helpers, formatters, NavigationStateManager state transforms) in iosApp/iosApp/.
Not for iOS view tests — those live in iosApp/iosAppTests/UIComponent/ and are run via the run-ui-tests skill against the UIComponentTests test plan.
./gradlew testAndroidHostTest
xcodebuild test -scheme iOSApp -testPlan UnitTests -destination 'platform=iOS Simulator,name=iPhone 17 Pro'
Runs the Swift Testing tests in iosApp/iosAppTests/Unit/. Currently holds a single PlaceholderUnitTest (1 + 1 == 2) — the plumbing is wired so real iOS-side pure-logic tests drop into that directory without any build-system work. Most business logic lives in KMP Kotlin and is covered by Kotest above.
# Domain tests
./gradlew :features:{name}:impl:domain:testAndroidHostTest
# Data tests
./gradlew :features:{name}:impl:data:testAndroidHostTest
# Presenter tests
./gradlew :features:{name}:impl:presentation:testAndroidHostTest
Valid feature names: home, login, more, order, profile, rewards, scan
./gradlew :core:{module}:testAndroidHostTest
Valid core modules: auth:api, auth:impl, centerpost, circuit, network, theme, test-fixtures
BehaviorSpec (Given/When/Then structure)TestCenterPostDispatchers for deterministic coroutine executionfeatures/{name}/test/ for fake implementationsNavigation and integration tests in testing/navint-tests/ are not unit tests. They run on a connected Android emulator via ./gradlew :testing:navint-tests:connectedAndroidDeviceTest and use JUnit4 @RunWith(AndroidJUnit4::class) rather than Kotest BehaviorSpec. Do not include them in the unit test run.