[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KCHS3WV7WQKNREKQEC49WM":3,"skill-same:01M6KCHS3WV7WQKNREKQEC49WM":74},{"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":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":51,"commitSha":52,"skillDirectory":53,"forksCount":54,"repositoryHtmlUrl":55,"repositoryHomepageUrl":6,"ownerHtmlUrl":56,"ownerBlogUrl":57,"ownerDescription":58,"updatedAt":59,"install":60,"resources":73},"01M6KCHS3WV7WQKNREKQEC49WM","mobiai-mobile-planning",null,"You MUST use this whenever a mobile task spans multiple steps, files, or subsystems — before touching code. Produce a written plan the user approves; do not improvise multi-step work from memory.","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-mobile-planning\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"mobiai mobile planning","planning","mobile","flutter","you","multi","task","do","files","use","work","gemini","plan","produce","code","copilot","react","memory","codex","android","2026-11-10 10:12:30",false,"---\nname: mobiai-mobile-planning\ndescription: \"You MUST use this whenever a mobile task spans multiple steps, files, or subsystems — before touching code. Produce a written plan the user approves; do not improvise multi-step work from memory.\"\nlicense: MIT\ncompatibility: [claude-code, cursor, copilot, codex, gemini]\nplatforms: [android, ios, kmp, flutter, react-native]\n---\n\n# Writing Mobile Plans\n\n## Overview\n\nWrite comprehensive implementation plans assuming the engineer has zero context for our codebase. Document everything they need: which files to touch, code, testing, how to verify. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.\n\n**Announce at start:** \"I'm using the mobile-planning skill to create the implementation plan.\"\n\n**Save plans to:** `docs\u002Fplans\u002FYYYY-MM-DD-\u003Cfeature-name>.md`\n- (User preferences for plan location override this default)\n\n## Numbered Task Lists Are INPUT, Not Substitute\n\nIf the user hands you a numbered list of 3+ tasks, that list is raw input — not a finished plan. You MUST still invoke this skill to validate:\n\n- **Dependencies**: which task must finish before another can start\n- **File-level conflicts**: can tasks be parallelized without agent collisions (e.g. two agents editing the same DI module or build file)\n- **Scope boundaries**: what each task pulls in (a \"fix bug X\" task may require related tests and touch adjacent code)\n- **Approval checkpoint**: present the dependency graph and wait for explicit user approval before dispatching any agent or writing any code\n\nA user-supplied list describes *what*. Planning determines *how, in what order, and by whom*.\n\n## Scope Check\n\nIf the spec covers multiple independent subsystems, suggest breaking into separate plans — one per subsystem. Each plan should produce working, testable software on its own.\n\n## File Structure\n\nBefore defining tasks, map out which files will be created or modified. Design units with clear boundaries. Prefer smaller, focused files. In existing codebases, follow established patterns.\n\n## Bite-Sized Task Granularity\n\n**Each step is one action (2-5 minutes):**\n- \"Write the failing test\" - step\n- \"Run it to make sure it fails\" - step\n- \"Implement the minimal code to make the test pass\" - step\n- \"Run the tests and make sure they pass\" - step\n- \"Commit\" - step\n\n## Plan Document Header\n\n**Every plan MUST start with this header:**\n\n```markdown\n# [Feature Name] Implementation Plan\n\n> **For agentic workers:** Use `mobiai-mobile-executing-plans-with-subagents` (recommended) or `mobiai-mobile-executing-plans` to implement this plan task-by-task. Steps use checkbox syntax for tracking.\n\n**Goal:** [One sentence describing what this builds]\n\n**Architecture:** [2-3 sentences about approach]\n\n**Tech Stack:** [Key technologies\u002Flibraries]\n\n**Platform:** [Android \u002F iOS \u002F KMP \u002F Flutter \u002F React Native]\n\n---\n```\n\n## Task Structure\n\n````markdown\n### Task N: [Component Name]\n\n**Files:**\n- Create: `exact\u002Fpath\u002Fto\u002Ffile.kt`\n- Modify: `exact\u002Fpath\u002Fto\u002Fexisting.kt:123-145`\n- Test: `exact\u002Fpath\u002Fto\u002Ftest.kt`\n\n- [ ] **Step 1: Write the failing test**\n\n```kotlin\n@Test\nfun `specific behavior description`() {\n    val result = function(input)\n    assertEquals(expected, result)\n}\n```\n\n- [ ] **Step 2: Run test to verify it fails**\n\nRun: `.\u002Fgradlew testDebugUnitTest --tests \"com.example.MyTest\"`\nExpected: FAIL with \"function not defined\"\n\n- [ ] **Step 3: Write minimal implementation**\n\n```kotlin\nfun function(input: Type): ReturnType {\n    return expected\n}\n```\n\n- [ ] **Step 4: Run test to verify it passes**\n\nRun: `.\u002Fgradlew testDebugUnitTest --tests \"com.example.MyTest\"`\nExpected: PASS\n\n- [ ] **Step 5: Commit**\n\n```bash\ngit add tests\u002Fpath\u002Ftest.kt src\u002Fpath\u002Ffile.kt\ngit commit -m \"feat: add specific feature\"\n```\n````\n\n## Mobile-Specific Considerations\n\nInclude these in the plan when relevant:\n\n| Consideration | Include when |\n|---------------|-------------|\n| **Build verification** | After every 2-3 tasks: `.\u002Fgradlew assembleDebug` or `xcodebuild build` |\n| **DB migrations** | Any Room\u002FCoreData schema change — include migration code |\n| **Permissions** | New permission needed — include manifest\u002Fplist entry + runtime request |\n| **ProGuard\u002FR8 rules** | New serialization or reflection — include keep rules |\n| **Multi-platform** | KMP\u002FFlutter\u002FRN — separate tasks for shared code vs platform-specific |\n| **Navigation** | New screen — include route registration and navigation call |\n| **DI registration** | New injectable class — include module\u002Fcomponent registration |\n\n## No Placeholders\n\nEvery step must contain the actual content. These are **plan failures** — never write them:\n- \"TBD\", \"TODO\", \"implement later\", \"fill in details\"\n- \"Add appropriate error handling\" \u002F \"add validation\" \u002F \"handle edge cases\"\n- \"Write tests for the above\" (without actual test code)\n- \"Similar to Task N\" (repeat the code)\n- Steps that describe what to do without showing how\n\n## Remember\n- Exact file paths always\n- Complete code in every step\n- Exact commands with expected output\n- DRY, YAGNI, TDD, frequent commits\n\n## Self-Review\n\nAfter writing the complete plan, check:\n\n**1. Spec coverage:** Skim each requirement. Can you point to a task that implements it? List any gaps.\n\n**2. Placeholder scan:** Search for red flags from the \"No Placeholders\" section. Fix them.\n\n**3. Type consistency:** Do types, method signatures, and property names match across tasks?\n\nIf you find issues, fix them inline.\n\n## Execution Handoff\n\nAfter saving the plan, offer execution choice:\n\n**\"Plan complete and saved to `\u003Cpath>`. Two execution options:**\n\n**1. Subagent-Driven (recommended)** - I dispatch a fresh subagent per task, review between tasks\n\n**2. Inline Execution** - Execute tasks in this session with checkpoints\n\n**Which approach?\"**\n\n**If Subagent-Driven chosen:** Use `mobiai-mobile-executing-plans-with-subagents`\n\n**If Inline Execution chosen:** Use `mobiai-mobile-executing-plans`\n","# Writing Mobile Plans\n\n## Overview\n\nWrite comprehensive implementation plans assuming the engineer has zero context for our codebase. Document everything they need: which files to touch, code, testing, how to verify. Give them the whole plan as bite-sized tasks. DRY. YAGNI. TDD. Frequent commits.\n\n**Announce at start:** \"I'm using the mobile-planning skill to create the implementation plan.\"\n\n**Save plans to:** `docs\u002Fplans\u002FYYYY-MM-DD-\u003Cfeature-name>.md`\n- (User preferences for plan location override this default)\n\n## Numbered Task Lists Are INPUT, Not Substitute\n\nIf the user hands you a numbered list of 3+ tasks, that list is raw input — not a finished plan. You MUST still invoke this skill to validate:\n\n- **Dependencies**: which task must finish before another can start\n- **File-level conflicts**: can tasks be parallelized without agent collisions (e.g. two agents editing the same DI module or build file)\n- **Scope boundaries**: what each task pulls in (a \"fix bug X\" task may require related tests and touch adjacent code)\n- **Approval checkpoint**: present the dependency graph and wait for explicit user approval before dispatching any agent or writing any code\n\nA user-supplied list describes *what*. Planning determines *how, in what order, and by whom*.\n\n## Scope Check\n\nIf the spec covers multiple independent subsystems, suggest breaking into separate plans — one per subsystem. Each plan should produce working, testable software on its own.\n\n## File Structure\n\nBefore defining tasks, map out which files will be created or modified. Design units with clear boundaries. Prefer smaller, focused files. In existing codebases, follow established patterns.\n\n## Bite-Sized Task Granularity\n\n**Each step is one action (2-5 minutes):**\n- \"Write the failing test\" - step\n- \"Run it to make sure it fails\" - step\n- \"Implement the minimal code to make the test pass\" - step\n- \"Run the tests and make sure they pass\" - step\n- \"Commit\" - step\n\n## Plan Document Header\n\n**Every plan MUST start with this header:**\n\n```markdown\n# [Feature Name] Implementation Plan\n\n> **For agentic workers:** Use `mobiai-mobile-executing-plans-with-subagents` (recommended) or `mobiai-mobile-executing-plans` to implement this plan task-by-task. Steps use checkbox syntax for tracking.\n\n**Goal:** [One sentence describing what this builds]\n\n**Architecture:** [2-3 sentences about approach]\n\n**Tech Stack:** [Key technologies\u002Flibraries]\n\n**Platform:** [Android \u002F iOS \u002F KMP \u002F Flutter \u002F React Native]\n\n---\n```\n\n## Task Structure\n\n````markdown\n### Task N: [Component Name]\n\n**Files:**\n- Create: `exact\u002Fpath\u002Fto\u002Ffile.kt`\n- Modify: `exact\u002Fpath\u002Fto\u002Fexisting.kt:123-145`\n- Test: `exact\u002Fpath\u002Fto\u002Ftest.kt`\n\n- [ ] **Step 1: Write the failing test**\n\n```kotlin\n@Test\nfun `specific behavior description`() {\n    val result = function(input)\n    assertEquals(expected, result)\n}\n```\n\n- [ ] **Step 2: Run test to verify it fails**\n\nRun: `.\u002Fgradlew testDebugUnitTest --tests \"com.example.MyTest\"`\nExpected: FAIL with \"function not defined\"\n\n- [ ] **Step 3: Write minimal implementation**\n\n```kotlin\nfun function(input: Type): ReturnType {\n    return expected\n}\n```\n\n- [ ] **Step 4: Run test to verify it passes**\n\nRun: `.\u002Fgradlew testDebugUnitTest --tests \"com.example.MyTest\"`\nExpected: PASS\n\n- [ ] **Step 5: Commit**\n\n```bash\ngit add tests\u002Fpath\u002Ftest.kt src\u002Fpath\u002Ffile.kt\ngit commit -m \"feat: add specific feature\"\n```\n````\n\n## Mobile-Specific Considerations\n\nInclude these in the plan when relevant:\n\n| Consideration | Include when |\n|---------------|-------------|\n| **Build verification** | After every 2-3 tasks: `.\u002Fgradlew assembleDebug` or `xcodebuild build` |\n| **DB migrations** | Any Room\u002FCoreData schema change — include migration code |\n| **Permissions** | New permission needed — include manifest\u002Fplist entry + runtime request |\n| **ProGuard\u002FR8 rules** | New serialization or reflection — include keep rules |\n| **Multi-platform** | KMP\u002FFlutter\u002FRN — separate tasks for shared code vs platform-specific |\n| **Navigation** | New screen — include route registration and navigation call |\n| **DI registration** | New injectable class — include module\u002Fcomponent registration |\n\n## No Placeholders\n\nEvery step must contain the actual content. These are **plan failures** — never write them:\n- \"TBD\", \"TODO\", \"implement later\", \"fill in details\"\n- \"Add appropriate error handling\" \u002F \"add validation\" \u002F \"handle edge cases\"\n- \"Write tests for the above\" (without actual test code)\n- \"Similar to Task N\" (repeat the code)\n- Steps that describe what to do without showing how\n\n## Remember\n- Exact file paths always\n- Complete code in every step\n- Exact commands with expected output\n- DRY, YAGNI, TDD, frequent commits\n\n## Self-Review\n\nAfter writing the complete plan, check:\n\n**1. Spec coverage:** Skim each requirement. Can you point to a task that implements it? List any gaps.\n\n**2. Placeholder scan:** Search for red flags from the \"No Placeholders\" section. Fix them.\n\n**3. Type consistency:** Do types, method signatures, and property names match across tasks?\n\nIf you find issues, fix them inline.\n\n## Execution Handoff\n\nAfter saving the plan, offer execution choice:\n\n**\"Plan complete and saved to `\u003Cpath>`. Two execution options:**\n\n**1. Subagent-Driven (recommended)** - I dispatch a fresh subagent per task, review between tasks\n\n**2. Inline Execution** - Execute tasks in this session with checkpoints\n\n**Which approach?\"**\n\n**If Subagent-Driven chosen:** Use `mobiai-mobile-executing-plans-with-subagents`\n\n**If Inline Execution chosen:** Use `mobiai-mobile-executing-plans`\n",{"name":5,"license":15,"platforms":44,"description":7,"compatibility":48},[38,45,46,22,47],"ios","kmp","react-native",[49,50,34,37,30],"claude-code","cursor","main","2edc6ac1cde2cc280ae0388aa8072902d2e230d5","skills\u002Fcore\u002Fskills\u002Fmobiai-mobile-planning",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":61,"prompt":71,"zipAvailable":72},[62,65,68],{"tool":63,"command":64},"npx","npx skills add ArisGuimera\u002FMobiAI-Core --skill mobiai-mobile-planning",{"tool":66,"command":67},"bunx","bunx skills add ArisGuimera\u002FMobiAI-Core --skill mobiai-mobile-planning",{"tool":69,"command":70},"pnpm","pnpm dlx skills add ArisGuimera\u002FMobiAI-Core --skill mobiai-mobile-planning","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FArisGuimera\u002FMobiAI-Core\u002Fblob\u002Fmain\u002Fskills\u002Fcore\u002Fskills\u002Fmobiai-mobile-planning\u002FSKILL.md",true,[],[75,100,113,131,149,163],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":89,"publishedAt":39},"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",[81,86],{"categoryNo":82,"categoryName":83,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":87,"categoryName":88,"taxonomyType":84,"taxonomyTypeDesc":85},"01JBSEEDCAT000000000000009","前端开发",[35,90,91,92,93,37,34,94,95,33,96,97,50,28,98,47,49,99],"react native","native","mobiai react native","testing","debugging","state management","state","management","navigation","project",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":107,"publishedAt":39},"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",[106],{"categoryNo":82,"categoryName":83,"taxonomyType":84,"taxonomyTypeDesc":85},[108,93,37,34,33,109,110,50,28,49,111,99,112],"mobiai kmp","kotlin","kotlin multiplatform","shared","platform",{"skillNo":114,"name":115,"nameZh":6,"description":116,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":117,"categories":118,"keywords":120,"publishedAt":39},"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",[119],{"categoryNo":82,"categoryName":83,"taxonomyType":84,"taxonomyTypeDesc":85},[93,45,121,122,123,37,124,34,33,125,126,127,50,128,28,49,99,129,130],"ios testing","mobiai ios testing","writing","unit tests","framework","running tests","ui","snapshot","tests","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":39},"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",[],[45,138,139,140,37,34,141,33,142,143,144,50,28,145,146,49,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":39},"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",[],[45,156,157,158,37,34,33,159,50,28,160,49,99,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":39},"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,45,171,172,37,173,34,33,174,175,50,28,176,177,99,178,179,180,181,182],"architecture","ios architecture","mobiai ios architecture","project structure","refactoring","find","patterns","structure","understand","changes","codebase","Existing","features"]