메뉴
Combined unit + UI test gap-filling for all changed code. Analyzes the branch diff and creates missing tests for domain logic, data access, presenters, and UI screens.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | add-tests |
| description | Combined unit + UI test gap-filling for all changed code. Analyzes the branch diff and creates missing tests for domain logic, data access, presenters, and UI screens. |
Comprehensive test gap-filling that combines unit tests and UI tests.
git diff origin/main...HEAD --name-only -- '*.kt'
Categorize changed files:
impl/domain/ → needs unit tests (use case logic)impl/data/ → needs unit tests (repository logic)impl/presentation/src/commonMain/ → needs presenter unit testsimpl/presentation/src/androidMain/ → needs UI tests (Robot pattern) + may need navint-testsapi/navigation/ → may need navint-tests for navigation contract changestest/ → fake changes may require updating existing testsapi/ → contract changes may require updating tests + fakesFollow the add-unit-tests skill instructions:
.agents/skills/add-unit-tests/SKILL.md for templates and conventionstest/src/commonMain/ for all abstract use casesFollow the add-ui-tests skill instructions:
.agents/skills/add-ui-tests/SKILL.md for templates and conventionsapi/navigation/ for testable elementsAndroid navint-tests: If impl/presentation/src/androidMain/ or api/navigation/ changed, check whether a corresponding test exists in testing/navint-tests/src/androidDeviceTest/kotlin/:
NavigationTest.kt or IntegrationTest.kt@RunWith(AndroidJUnit4::class) — NOT Kotest BehaviorSpecfeatures/{name}/test/)If a navigation flow or integration scenario lacks coverage, add the test in testing/navint-tests/. See .agents/standards/testing-navint.md for the navint-tests conventions.
iOS navint-tests: If iosApp/iosApp/Circuit/ changed, check whether corresponding tests exist in iosApp/iosAppTests/NavInt/:
NavigationStateManagerTest, TabSwitchingTest, DeepLinkNavigationTest, AuthFlowNavigationTest@Suite @MainActor struct) — NOT XCTestNavigationStateManager state transitions (no ViewInspector, state management only)If a navigation state change or new navigation flow lacks iOS coverage, add or update tests in iosApp/iosAppTests/NavInt/. See .agents/standards/testing-navint.md for the iOS navint-tests conventions.
If a new user journey, deep link, or tab navigation flow was added, check whether a corresponding test exists in testing/e2e-tests/src/main/kotlin/.../suites/:
JourneyTest.kt@RunWith(AndroidJUnit4::class) and AppRobot for all interactionsBy.desc(testTag)) — no direct code accessfeatures/*/api/navigation/If a startup performance concern exists, check testing/benchmarks/src/main/kotlin/com/mockdonalds/app/benchmarks/ (separate module, minified target):
Benchmark.ktMacrobenchmarkRule with StartupTimingMetric()See .agents/standards/testing-e2e.md for e2e-tests conventions, testing/e2e-tests/AGENTS.md for journey-test details, and testing/benchmarks/AGENTS.md for macrobenchmark details.
Work is NEVER complete until verification passes. Run the verify skill to validate all changes. It will:
./gradlew :testing:navint-tests:connectedAndroidDeviceTest) if presentation or navigation modules changed (requires emulator)If ANY check fails, fix the issue and re-run. Do not declare the task complete until verification passes.
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.