[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KCJZPQW8FANQ7PNF4W52BE":3,"skill-same:01M6KCJZPQW8FANQ7PNF4W52BE":80},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":57,"commitSha":58,"skillDirectory":59,"forksCount":60,"repositoryHtmlUrl":61,"repositoryHomepageUrl":6,"ownerHtmlUrl":62,"ownerBlogUrl":63,"ownerDescription":64,"updatedAt":65,"install":66,"resources":79},"01M6KCJZPQW8FANQ7PNF4W52BE","mobiai-write-tests",null,"Use when the user asks to write tests for mobile code, or after applying a fix that needs regression tests.","ArisGuimera\u002FMobiAI-Core","ArisGuimera","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F16361358?v=4","01M6KC5MVGRKDA14DWT98445V9","AristiDevs","01M6KC5MZKRFFHFFD340B21YN3",492,"MIT","https:\u002F\u002Fgithub.com\u002FArisGuimera\u002FMobiAI-Core\u002Fblob\u002Fmain\u002Fskills\u002Fcore\u002Fskills\u002Fmobiai-write-tests\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"mobiai write tests","write tests","tests","write","fix","for","native","claude-code","react-native","mobile","use","cursor","android","flutter","regression","ios","code","copilot","react","codex","2026-11-10 10:12:30",false,"---\nname: mobiai-write-tests\ndescription: Use when the user asks to write tests for mobile code, or after applying a fix that needs regression tests.\nlicense: MIT\ncompatibility: [claude-code, cursor, copilot, codex]\nplatforms: [android, ios, kmp, flutter, react-native]\n---\n\n# Write Tests\n\nWrite tests that cover a bug fix or new feature, following the project's existing patterns and platform conventions.\n\n## When to Use\n\n- After applying a fix, to prevent regression\n- User asks to add tests for specific code\n- As part of the `mobiai-fix-issue` pipeline\n\n**Note**: If you're implementing a new feature or fix from scratch, consider using `mobiai-mobile-tdd` instead — it enforces writing tests FIRST (Red-Green-Refactor). This skill is for adding tests to existing code.\n\n## Pre-flight: check the Brain for relevant patterns\n\nStandalone invocations only — **skip this section when called from `mobiai-fix-issue` or `mobiai-mobile-tdd`**, which run their own pre-flight or wrap this skill mid-flow.\n\nIf `\u003Crepo>\u002F.mobiai\u002Fbrain\u002Fconfig.json` exists, do a quick review pass before designing the test cases. A known workaround in the same area might shape what's worth asserting (the test should verify the workaround still works, not assume the fix is upstream).\n\n**Preferred — MCP tool** (when `mobiai-brain` MCP server is registered):\n\nInvoke `mobile_review` with default args. Focus on entries whose `platform` matches the project's platform and whose `area` overlaps with the system under test (datastore, networking, lifecycle, etc.). Run `mobile_scan` first if you don't already know the project's platform.\n\n**Fallback — CLI**:\n\n```bash\nmobiai brain review --no-fail\n```\n\nIf 1+ overdue entries match, **mention them to the user** before Step 1:\n\n> \"Heads up — there are N overdue workaround(s) in \u003Cplatform>\u002F\u003Carea> that may shape what these tests need to cover: \u003Ctitle>. I'll proceed; let me know if you want to look at those first.\"\n\nThen continue with Step 1. Skip silently when:\n\n- The brain isn't initialized.\n- No overdue entries match the area \u002F platform of the code under test.\n\n## Pre-flight: check the Graph for code structure\n\nStandalone invocations only — **skip this section when called from `mobiai-fix-issue` or `mobiai-mobile-tdd`**, which run their own Graph pre-flight or wrap this skill mid-flow.\n\nThe Graph helps locate the system under test, its callers, and nearby existing tests — useful before Step 1 (Understand What to Test) and Step 2 (Find Existing Test Patterns).\n\n**If `\u003Crepo>\u002F.mobiai\u002Fgraph\u002Findex.json` exists**:\n\n```bash\n# Freshness — if \"hace Xd\" with X ≥ 1, suggest refresh (don't auto-run):\nmobiai graph status\n\n# Locate the symbol being tested:\nmobiai graph search \u003CClassOrFunctionUnderTest>\n\n# See how it's used in the codebase (informs which test cases matter):\nmobiai graph callers \u003CClassOrFunctionUnderTest>\n\n# Find existing test classes nearby (informs patterns and naming):\nmobiai graph search Test --kind class --limit 20\n```\n\nThe callers list reveals which call sites depend on the behavior — those are the cases worth covering. The existing-test search shows the project's actual test conventions (framework, naming, location).\n\nIf the index is ≥1 day old:\n\n> \"El índice del Graph es de hace Xd. Si querés resultados frescos, corré `mobiai graph init`.\"\n\nDon't run `init` autonomously.\n\n**If `.mobiai\u002Fgraph\u002Findex.json` does not exist** and the project has `.kt` or `.swift` files:\n\n> \"No veo el índice del Graph. Generalo con `mobiai graph init` y arranco — sin él tengo que descubrir las convenciones de tests grepeando.\"\n\nDon't run `init` autonomously.\n\n**Skip silently when**:\n\n- The project has no Kotlin\u002FSwift files (Flutter or RN-only).\n- You're testing pure Dart \u002F JS \u002F TS code (Graph doesn't index those in V1).\n\n## Workflow\n\n### Step 1: Understand What to Test\n\n1. **Read the changed files** to understand what was fixed or added\n2. **Identify the testable unit** — the method, class, or behavior that changed\n3. **Define test cases**:\n   - The specific behavior that was broken and is now fixed\n   - Edge cases related to the change\n   - Boundary conditions (null inputs, empty collections, max values)\n\n### Step 2: Find Existing Test Patterns\n\nBefore writing tests, find and read existing tests in the project:\n\nSearch for existing test files near the changed code:\n- Use the Glob tool with patterns like `**\u002Ftest\u002F**\u002F*Test*` or `**\u002F*_test.*`\n- Or use Grep to search for test classes: `class.*Test` in test directories\n\nRead existing tests to understand:\n- Which test framework is used\n- Naming conventions\n- Mocking approach\n- How dependencies are set up\n- Where test files are located relative to source files\n\n### Step 3: Write Tests\n\nFollow the project's existing patterns. If no patterns exist, follow platform defaults below.\n\n### Step 4: Run Tests\n\nRun the test suite to verify:\n- Your new tests pass\n- Existing tests still pass (no regressions from the fix)\n\nIf tests fail, fix them. If existing tests fail and your fix caused the regression, fix that too.\n\n### Step 5: Capture in MobiAI Brain (if worth remembering)\n\nOnce tests pass, check whether `\u003Crepo>\u002F.mobiai\u002Fbrain\u002Fconfig.json` exists. If it does NOT, skip this step silently — not every project uses Brain.\n\nIf it does, decide whether this test is a **reusable pattern** worth saving as a `testing_pattern` entry. A test is worth saving when it captures a non-obvious mobile-specific gotcha — async\u002Flifecycle timing, platform quirks, flaky-test workarounds, fixture patterns. Skip when the test is a routine assertion on business logic.\n\nWhen it's worth saving, **propose** the save to the user first (one-line confirmation). Never invoke silently.\n\n**Preferred — MCP tool** (if your client has the `mobiai-brain` MCP server registered, you'll see this tool in your toolbox):\n\nInvoke `mobile_save_testing` with:\n\n- `title`: short pattern name, e.g. `\"DataStore clear waits for empty emission\"`\n- `platform`: `android | ios | shared | kmp | flutter | react-native`\n- `area`: free-form, e.g. `\"datastore\" | \"coroutines\" | \"xctest\" | \"maestro\"`\n- `files`: array of repo-relative paths (test + system-under-test)\n- `body`: Markdown with `### Problem` \u002F `### Solution` \u002F `### Example` (omit `### Example` when the language doesn't fit)\n\n**Fallback — CLI** (if MCP isn't configured):\n\n```bash\nmobiai brain save testing \\\n  --title \"\u003Cshort pattern name, e.g. 'DataStore clear waits for empty emission'>\" \\\n  --platform \u003Candroid|ios|shared|kmp|flutter|react-native> \\\n  --area \u003Cfree-form, e.g. datastore | coroutines | xctest | maestro> \\\n  --files \"\u003Ctest_file>,\u003Csut_file>\" \\\n  --body \"### Problem\nWhat goes wrong without this pattern (race, leak, false pass, etc.).\n\n### Solution\nThe pattern itself, in one paragraph.\n\n### Example\n\\`\\`\\`kotlin\n\u002F\u002F minimal code snippet\n\\`\\`\\`\"\n```\n\nSkip the body's `### Example` block on languages that don't fit. The fewer placeholders, the better — concrete pattern in the user's own words beats a generic template.\n\n## Platform Conventions\n\n### Android (Kotlin)\n\n**Default framework**: JUnit 4 + MockK\n\n**Test location**: Mirror source path under test directory\n- Source: `app\u002Fsrc\u002Fmain\u002Fjava\u002Fcom\u002Fexample\u002Ffeature\u002FMyClass.kt`\n- Test: `app\u002Fsrc\u002Ftest\u002Fjava\u002Fcom\u002Fexample\u002Ffeature\u002FMyClassTest.kt`\n\n**Naming**: Backtick-enclosed descriptive names\n```kotlin\n@Test\nfun `calculateTotal returns zero when cart is empty`() { ... }\n\n@Test\nfun `formatPrice throws when amount is negative`() { ... }\n```\n\n**Mocking**: Use `io.mockk` (`mockk`, `every`, `verify`, `coEvery` for coroutines)\n\n**Coroutines**: Use `kotlinx-coroutines-test` with `runTest`\n\n**Run tests**:\n```bash\n.\u002Fgradlew test\u003CFlavor>DebugUnitTest --no-daemon\n```\n\n**Rules**:\n- No Android framework in unit tests — use Robolectric only if absolutely needed\n- Mock external dependencies (repositories, APIs, DAOs)\n- Test ViewModels with `MainDispatcherRule` or `Dispatchers.setMain()`\n\n### iOS (Swift)\n\n**Default framework**: XCTest\n\n**Test location**: Inside the test target\n- Source: `MyApp\u002FFeature\u002FMyClass.swift`\n- Test: `MyAppTests\u002FFeature\u002FMyClassTests.swift`\n\n**Naming**: `test` prefix + descriptive name\n```swift\nfunc testCalculateTotal_returnsZero_whenCartIsEmpty() { ... }\nfunc testFormatPrice_throws_whenAmountIsNegative() { ... }\n```\n\n**Run tests**:\n```bash\nxcodebuild test -scheme \u003Cscheme> -destination 'platform=iOS Simulator,name=iPhone 15' -quiet\n```\n\n### Flutter (Dart)\n\n**Default framework**: `flutter_test`\n\n**Test location**: `test\u002F` directory mirroring `lib\u002F`\n- Source: `lib\u002Ffeature\u002Fmy_class.dart`\n- Test: `test\u002Ffeature\u002Fmy_class_test.dart`\n\n**Naming**: `test()` with descriptive strings\n```dart\ntest('calculateTotal returns zero when cart is empty', () { ... });\ngroup('formatPrice', () {\n  test('throws when amount is negative', () { ... });\n});\n```\n\n**Run tests**:\n```bash\nflutter test\n```\n\n### React Native (TypeScript\u002FJavaScript)\n\n**Default framework**: Jest\n\n**Test location**: `__tests__\u002F` directory or co-located `.test.ts` files\n\n**Naming**: `describe` + `it` blocks\n```typescript\ndescribe('calculateTotal', () => {\n  it('returns zero when cart is empty', () => { ... });\n});\n```\n\n**Run tests**:\n```bash\nnpx jest\n```\n\n### KMP (Kotlin Multiplatform)\n\n**Test location**: `shared\u002Fsrc\u002FcommonTest\u002Fkotlin\u002F` for shared code\n\n**Run tests**:\n```bash\n.\u002Fgradlew :shared:testDebugUnitTest  # Android target\n.\u002Fgradlew :shared:iosSimulatorArm64Test  # iOS target\n```\n\n## When Tests Are Not Possible\n\nSet `testsWritten=false` if:\n- The fix is in tightly coupled UI code with no way to unit test without massive refactoring\n- The fix is a configuration change (manifest, plist, build file)\n- The fix is purely a resource change (strings, layouts, assets)\n\nAlways explain why tests couldn't be written.\n","# Write Tests\n\nWrite tests that cover a bug fix or new feature, following the project's existing patterns and platform conventions.\n\n## When to Use\n\n- After applying a fix, to prevent regression\n- User asks to add tests for specific code\n- As part of the `mobiai-fix-issue` pipeline\n\n**Note**: If you're implementing a new feature or fix from scratch, consider using `mobiai-mobile-tdd` instead — it enforces writing tests FIRST (Red-Green-Refactor). This skill is for adding tests to existing code.\n\n## Pre-flight: check the Brain for relevant patterns\n\nStandalone invocations only — **skip this section when called from `mobiai-fix-issue` or `mobiai-mobile-tdd`**, which run their own pre-flight or wrap this skill mid-flow.\n\nIf `\u003Crepo>\u002F.mobiai\u002Fbrain\u002Fconfig.json` exists, do a quick review pass before designing the test cases. A known workaround in the same area might shape what's worth asserting (the test should verify the workaround still works, not assume the fix is upstream).\n\n**Preferred — MCP tool** (when `mobiai-brain` MCP server is registered):\n\nInvoke `mobile_review` with default args. Focus on entries whose `platform` matches the project's platform and whose `area` overlaps with the system under test (datastore, networking, lifecycle, etc.). Run `mobile_scan` first if you don't already know the project's platform.\n\n**Fallback — CLI**:\n\n```bash\nmobiai brain review --no-fail\n```\n\nIf 1+ overdue entries match, **mention them to the user** before Step 1:\n\n> \"Heads up — there are N overdue workaround(s) in \u003Cplatform>\u002F\u003Carea> that may shape what these tests need to cover: \u003Ctitle>. I'll proceed; let me know if you want to look at those first.\"\n\nThen continue with Step 1. Skip silently when:\n\n- The brain isn't initialized.\n- No overdue entries match the area \u002F platform of the code under test.\n\n## Pre-flight: check the Graph for code structure\n\nStandalone invocations only — **skip this section when called from `mobiai-fix-issue` or `mobiai-mobile-tdd`**, which run their own Graph pre-flight or wrap this skill mid-flow.\n\nThe Graph helps locate the system under test, its callers, and nearby existing tests — useful before Step 1 (Understand What to Test) and Step 2 (Find Existing Test Patterns).\n\n**If `\u003Crepo>\u002F.mobiai\u002Fgraph\u002Findex.json` exists**:\n\n```bash\n# Freshness — if \"hace Xd\" with X ≥ 1, suggest refresh (don't auto-run):\nmobiai graph status\n\n# Locate the symbol being tested:\nmobiai graph search \u003CClassOrFunctionUnderTest>\n\n# See how it's used in the codebase (informs which test cases matter):\nmobiai graph callers \u003CClassOrFunctionUnderTest>\n\n# Find existing test classes nearby (informs patterns and naming):\nmobiai graph search Test --kind class --limit 20\n```\n\nThe callers list reveals which call sites depend on the behavior — those are the cases worth covering. The existing-test search shows the project's actual test conventions (framework, naming, location).\n\nIf the index is ≥1 day old:\n\n> \"El índice del Graph es de hace Xd. Si querés resultados frescos, corré `mobiai graph init`.\"\n\nDon't run `init` autonomously.\n\n**If `.mobiai\u002Fgraph\u002Findex.json` does not exist** and the project has `.kt` or `.swift` files:\n\n> \"No veo el índice del Graph. Generalo con `mobiai graph init` y arranco — sin él tengo que descubrir las convenciones de tests grepeando.\"\n\nDon't run `init` autonomously.\n\n**Skip silently when**:\n\n- The project has no Kotlin\u002FSwift files (Flutter or RN-only).\n- You're testing pure Dart \u002F JS \u002F TS code (Graph doesn't index those in V1).\n\n## Workflow\n\n### Step 1: Understand What to Test\n\n1. **Read the changed files** to understand what was fixed or added\n2. **Identify the testable unit** — the method, class, or behavior that changed\n3. **Define test cases**:\n   - The specific behavior that was broken and is now fixed\n   - Edge cases related to the change\n   - Boundary conditions (null inputs, empty collections, max values)\n\n### Step 2: Find Existing Test Patterns\n\nBefore writing tests, find and read existing tests in the project:\n\nSearch for existing test files near the changed code:\n- Use the Glob tool with patterns like `**\u002Ftest\u002F**\u002F*Test*` or `**\u002F*_test.*`\n- Or use Grep to search for test classes: `class.*Test` in test directories\n\nRead existing tests to understand:\n- Which test framework is used\n- Naming conventions\n- Mocking approach\n- How dependencies are set up\n- Where test files are located relative to source files\n\n### Step 3: Write Tests\n\nFollow the project's existing patterns. If no patterns exist, follow platform defaults below.\n\n### Step 4: Run Tests\n\nRun the test suite to verify:\n- Your new tests pass\n- Existing tests still pass (no regressions from the fix)\n\nIf tests fail, fix them. If existing tests fail and your fix caused the regression, fix that too.\n\n### Step 5: Capture in MobiAI Brain (if worth remembering)\n\nOnce tests pass, check whether `\u003Crepo>\u002F.mobiai\u002Fbrain\u002Fconfig.json` exists. If it does NOT, skip this step silently — not every project uses Brain.\n\nIf it does, decide whether this test is a **reusable pattern** worth saving as a `testing_pattern` entry. A test is worth saving when it captures a non-obvious mobile-specific gotcha — async\u002Flifecycle timing, platform quirks, flaky-test workarounds, fixture patterns. Skip when the test is a routine assertion on business logic.\n\nWhen it's worth saving, **propose** the save to the user first (one-line confirmation). Never invoke silently.\n\n**Preferred — MCP tool** (if your client has the `mobiai-brain` MCP server registered, you'll see this tool in your toolbox):\n\nInvoke `mobile_save_testing` with:\n\n- `title`: short pattern name, e.g. `\"DataStore clear waits for empty emission\"`\n- `platform`: `android | ios | shared | kmp | flutter | react-native`\n- `area`: free-form, e.g. `\"datastore\" | \"coroutines\" | \"xctest\" | \"maestro\"`\n- `files`: array of repo-relative paths (test + system-under-test)\n- `body`: Markdown with `### Problem` \u002F `### Solution` \u002F `### Example` (omit `### Example` when the language doesn't fit)\n\n**Fallback — CLI** (if MCP isn't configured):\n\n```bash\nmobiai brain save testing \\\n  --title \"\u003Cshort pattern name, e.g. 'DataStore clear waits for empty emission'>\" \\\n  --platform \u003Candroid|ios|shared|kmp|flutter|react-native> \\\n  --area \u003Cfree-form, e.g. datastore | coroutines | xctest | maestro> \\\n  --files \"\u003Ctest_file>,\u003Csut_file>\" \\\n  --body \"### Problem\nWhat goes wrong without this pattern (race, leak, false pass, etc.).\n\n### Solution\nThe pattern itself, in one paragraph.\n\n### Example\n\\`\\`\\`kotlin\n\u002F\u002F minimal code snippet\n\\`\\`\\`\"\n```\n\nSkip the body's `### Example` block on languages that don't fit. The fewer placeholders, the better — concrete pattern in the user's own words beats a generic template.\n\n## Platform Conventions\n\n### Android (Kotlin)\n\n**Default framework**: JUnit 4 + MockK\n\n**Test location**: Mirror source path under test directory\n- Source: `app\u002Fsrc\u002Fmain\u002Fjava\u002Fcom\u002Fexample\u002Ffeature\u002FMyClass.kt`\n- Test: `app\u002Fsrc\u002Ftest\u002Fjava\u002Fcom\u002Fexample\u002Ffeature\u002FMyClassTest.kt`\n\n**Naming**: Backtick-enclosed descriptive names\n```kotlin\n@Test\nfun `calculateTotal returns zero when cart is empty`() { ... }\n\n@Test\nfun `formatPrice throws when amount is negative`() { ... }\n```\n\n**Mocking**: Use `io.mockk` (`mockk`, `every`, `verify`, `coEvery` for coroutines)\n\n**Coroutines**: Use `kotlinx-coroutines-test` with `runTest`\n\n**Run tests**:\n```bash\n.\u002Fgradlew test\u003CFlavor>DebugUnitTest --no-daemon\n```\n\n**Rules**:\n- No Android framework in unit tests — use Robolectric only if absolutely needed\n- Mock external dependencies (repositories, APIs, DAOs)\n- Test ViewModels with `MainDispatcherRule` or `Dispatchers.setMain()`\n\n### iOS (Swift)\n\n**Default framework**: XCTest\n\n**Test location**: Inside the test target\n- Source: `MyApp\u002FFeature\u002FMyClass.swift`\n- Test: `MyAppTests\u002FFeature\u002FMyClassTests.swift`\n\n**Naming**: `test` prefix + descriptive name\n```swift\nfunc testCalculateTotal_returnsZero_whenCartIsEmpty() { ... }\nfunc testFormatPrice_throws_whenAmountIsNegative() { ... }\n```\n\n**Run tests**:\n```bash\nxcodebuild test -scheme \u003Cscheme> -destination 'platform=iOS Simulator,name=iPhone 15' -quiet\n```\n\n### Flutter (Dart)\n\n**Default framework**: `flutter_test`\n\n**Test location**: `test\u002F` directory mirroring `lib\u002F`\n- Source: `lib\u002Ffeature\u002Fmy_class.dart`\n- Test: `test\u002Ffeature\u002Fmy_class_test.dart`\n\n**Naming**: `test()` with descriptive strings\n```dart\ntest('calculateTotal returns zero when cart is empty', () { ... });\ngroup('formatPrice', () {\n  test('throws when amount is negative', () { ... });\n});\n```\n\n**Run tests**:\n```bash\nflutter test\n```\n\n### React Native (TypeScript\u002FJavaScript)\n\n**Default framework**: Jest\n\n**Test location**: `__tests__\u002F` directory or co-located `.test.ts` files\n\n**Naming**: `describe` + `it` blocks\n```typescript\ndescribe('calculateTotal', () => {\n  it('returns zero when cart is empty', () => { ... });\n});\n```\n\n**Run tests**:\n```bash\nnpx jest\n```\n\n### KMP (Kotlin Multiplatform)\n\n**Test location**: `shared\u002Fsrc\u002FcommonTest\u002Fkotlin\u002F` for shared code\n\n**Run tests**:\n```bash\n.\u002Fgradlew :shared:testDebugUnitTest  # Android target\n.\u002Fgradlew :shared:iosSimulatorArm64Test  # iOS target\n```\n\n## When Tests Are Not Possible\n\nSet `testsWritten=false` if:\n- The fix is in tightly coupled UI code with no way to unit test without massive refactoring\n- The fix is a configuration change (manifest, plist, build file)\n- The fix is purely a resource change (strings, layouts, assets)\n\nAlways explain why tests couldn't be written.\n",{"name":5,"license":15,"platforms":54,"description":7,"compatibility":56},[41,44,55,42,37],"kmp",[36,40,46,48],"main","2edc6ac1cde2cc280ae0388aa8072902d2e230d5","skills\u002Fcore\u002Fskills\u002Fmobiai-write-tests",14,"https:\u002F\u002Fgithub.com\u002FArisGuimera\u002FMobiAI-Core","https:\u002F\u002Fgithub.com\u002FArisGuimera","https:\u002F\u002Faristi.dev","⭐️ GitHub Star\r\n📲 Mobile developer\r\n🎥 Te enseño a programar apps en Youtube (AristiDevs)\r\n✍🏻 Y por escrito en CursoKotlin.com\r\n❤️ Kotlin Fanboy\r\n👇👇👇👇","2026-11-13 22:28:09",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add ArisGuimera\u002FMobiAI-Core --skill mobiai-write-tests",{"tool":72,"command":73},"bunx","bunx skills add ArisGuimera\u002FMobiAI-Core --skill mobiai-write-tests",{"tool":75,"command":76},"pnpm","pnpm dlx skills add ArisGuimera\u002FMobiAI-Core --skill mobiai-write-tests","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FArisGuimera\u002FMobiAI-Core\u002Fblob\u002Fmain\u002Fskills\u002Fcore\u002Fskills\u002Fmobiai-write-tests\u002FSKILL.md",true,[],[81,101,114,131,149,163],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":91,"publishedAt":49},"01M6KCMR2WVBEC7T0YY4J2SCAR","mobiai-react-native","Use when working on a React Native project — building, testing, debugging, understanding navigation and state management.","https:\u002F\u002Fgithub.com\u002FArisGuimera\u002FMobiAI-Core\u002Fblob\u002Fmain\u002Fskills\u002Freact-native\u002Fskills\u002Fmobiai-react-native\u002FSKILL.md",[87,90],{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[47,92,35,93,94,48,46,95,96,45,97,98,40,39,99,37,36,100],"react native","mobiai react native","testing","debugging","state management","state","management","navigation","project",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":108,"publishedAt":49},"01M6KCMKFC3DKFW5B2208SM59W","mobiai-kmp","Use when working on a Kotlin Multiplatform project — shared code, expect\u002Factual declarations, platform-specific implementations, building and testing.","https:\u002F\u002Fgithub.com\u002FArisGuimera\u002FMobiAI-Core\u002Fblob\u002Fmain\u002Fskills\u002Fkmp\u002Fskills\u002Fmobiai-kmp\u002FSKILL.md",[107],{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},[109,94,48,46,45,110,111,40,39,36,112,100,113],"mobiai kmp","kotlin","kotlin multiplatform","shared","platform",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":121,"publishedAt":49},"01M6KCMEC4YP1FFAX4ZX80Q10R","mobiai-ios-testing","Use when writing or running tests in an iOS project — unit tests, UI tests, snapshot tests, choosing the right framework.","https:\u002F\u002Fgithub.com\u002FArisGuimera\u002FMobiAI-Core\u002Fblob\u002Fmain\u002Fskills\u002Fios\u002Fskills\u002Fmobiai-ios-testing\u002FSKILL.md",[120],{"categoryNo":88,"categoryName":89,"taxonomyType":21,"taxonomyTypeDesc":22},[94,44,122,123,124,48,125,46,45,126,127,128,40,129,39,36,100,31,130],"ios testing","mobiai ios testing","writing","unit tests","framework","running tests","ui","snapshot","unit",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":137,"publishedAt":49},"01M6KCM78C8P9R6X78EZCQ0YF9","mobiai-ios-device","Use when interacting with an iOS Simulator — run simctl commands, capture screenshots, read device logs, manage simulators.","https:\u002F\u002Fgithub.com\u002FArisGuimera\u002FMobiAI-Core\u002Fblob\u002Fmain\u002Fskills\u002Fios\u002Fskills\u002Fmobiai-ios-device\u002FSKILL.md",[],[44,138,139,140,48,46,141,45,142,143,144,40,39,145,146,36,147,148],"device","mobiai ios device","screenshots","run","logs","capture","read","manage","ios simulator","commands","with",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":155,"publishedAt":49},"01M6KCM2HE6Z1B7WREJ9DTKKWA","mobiai-ios-build","Use when building an iOS project, configuring schemes, troubleshooting build failures, or managing dependencies with CocoaPods or SPM.","https:\u002F\u002Fgithub.com\u002FArisGuimera\u002FMobiAI-Core\u002Fblob\u002Fmain\u002Fskills\u002Fios\u002Fskills\u002Fmobiai-ios-build\u002FSKILL.md",[],[44,156,157,158,48,46,45,159,40,39,160,36,100,148,161,162],"build","ios build","mobiai ios build","troubleshooting","dependencies","spm","cocoapods",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":169,"publishedAt":49},"01M6KCKWZNT8P6K5SYXE1YAT9E","mobiai-ios-architecture","Use when creating features, refactoring, or navigating an iOS codebase — understand project structure, find where to make changes, follow existing patterns.","https:\u002F\u002Fgithub.com\u002FArisGuimera\u002FMobiAI-Core\u002Fblob\u002Fmain\u002Fskills\u002Fios\u002Fskills\u002Fmobiai-ios-architecture\u002FSKILL.md",[],[170,44,171,172,48,173,46,45,174,175,40,39,176,177,100,178,179,180,181,182],"architecture","ios architecture","mobiai ios architecture","project structure","refactoring","find","patterns","structure","understand","changes","codebase","Existing","features"]