[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KCGAVP13PQN13FCV4F50NP":3,"skill-same:01M6KCGAVP13PQN13FCV4F50NP":77},{"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":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":6,"ownerHtmlUrl":59,"ownerBlogUrl":60,"ownerDescription":61,"updatedAt":62,"install":63,"resources":76},"01M6KCGAVP13PQN13FCV4F50NP","mobiai-mobile-debugging",null,"You MUST use this before proposing any fix for a mobile bug, test failure, crash, or unexpected behavior — AND when re-investigating a bug whose previous fix didn't work (user shares a commit SHA and questions whether it resolves the bug). Walks root-cause analysis as phased evidence gathering. For small fixes with clear evidence, runs autonomously and returns the root cause to the caller. For complex or uncertain cases, gates at known-vs-assumed and root-cause steps.","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-debugging\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"mobiai mobile debugging","debugging","mobile debugging","mobile","bug","at","re","you","native","as","react-native","react","evidence","fix","work","returns","analysis","code","copilot","commit","2026-11-10 10:12:30",false,"---\nname: mobiai-mobile-debugging\ndescription: \"You MUST use this before proposing any fix for a mobile bug, test failure, crash, or unexpected behavior — AND when re-investigating a bug whose previous fix didn't work (user shares a commit SHA and questions whether it resolves the bug). Walks root-cause analysis as phased evidence gathering. For small fixes with clear evidence, runs autonomously and returns the root cause to the caller. For complex or uncertain cases, gates at known-vs-assumed and root-cause steps.\"\nlicense: MIT\ncompatibility: [claude-code, cursor, copilot, codex, gemini]\nplatforms: [android, ios, kmp, flutter, react-native]\n---\n\n# Systematic Mobile Debugging\n\nRandom fixes waste time and create new bugs. Quick patches mask underlying issues.\n\n**Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure.\n\n\u003CHARD-GATE>\nYou MUST NOT propose any fix, write any code, edit any production file, refactor any surrounding code, or invoke `mobiai-mobile-tdd` until you have (a) gathered evidence, (b) separated what is known from what is assumed, (c) formed and verified a hypothesis, and (d) stated the root cause.\n\nWhether you also need **explicit user confirmation** at steps (b) and (d) depends on the scope classification inherited from the caller (or declared at Pre-flight below). Fast path: no confirmation gate, proceed autonomously. Gated path: explicit confirmation required at both steps.\n\u003C\u002FHARD-GATE>\n\n## Anti-Pattern: \"It's Obviously X\"\n\nThe most common failure mode is pattern-matching the symptom to a familiar-looking cause and proposing a fix before the evidence supports it — especially when a sub-agent or exploration returns a confident diagnosis that was never cross-checked against the code. Threading, null, lifecycle, cache, \"the backend changed\" — all tempting guesses. Every bug goes through the phased flow.\n\nThe scope classification only changes **whether you wait for user confirmation**, not **whether you do the analysis**. Fast path still gathers evidence, splits known vs. assumed, forms and verifies a hypothesis, and states the root cause — it just returns that result to the caller instead of pausing for approval.\n\n## The Iron Law\n\n```\nNO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST\n```\n\n## Pre-flight: Scope Classification\n\nThis skill inherits the scope from its caller (typically `mobiai-fix-issue`). If invoked standalone, classify at the start:\n\n**Fast path** — work autonomously through all phases; return the verified root cause to the caller at Phase 6:\n- Clear symptom with obvious evidence (stack trace points at a specific line, log message is explicit)\n- Single root cause category (not contradictory evidence)\n- No architectural question, no cross-module mystery\n\n**Gated path** — stop and wait for user confirmation at Phase 2 and Phase 5:\n- Contradictory evidence or multiple plausible causes\n- Cross-module \u002F cross-platform investigation required\n- Root cause involves architectural choices (e.g., \"should this be on the main thread?\")\n- Previous fix attempts failed\n\nIn doubt → gated path.\n\n## Checklist\n\nYou MUST create a task for each of these items and complete them in order. Do not skip phases. Do not merge phases.\n\n1. **Gather evidence** — logs, stack traces, reproduction steps, affected platforms, recent changes\n2. **State known vs. assumed** — label each fact as observed or inferred (gated path: present to the user and wait for confirmation; fast path: record the split internally and proceed)\n3. **Form a hypothesis** — a single, specific, testable theory about the root cause\n4. **Verify the hypothesis** — against code and evidence, not against intuition\n5. **Present the root cause** (gated path: wait for user confirmation before Phase 6; fast path: state the root cause and proceed to Phase 6)\n6. **Hand off to implementation** — return control to `mobiai-fix-issue` if the broader pipeline is active, or invoke `mobiai-mobile-tdd`\n\n## When to Use\n\nUse for ANY mobile technical issue:\n- Test failures\n- Bugs in production\n- Unexpected behavior\n- Performance problems\n- Build failures\n- Crashes\n\n**Use this ESPECIALLY when:**\n- Under time pressure (emergencies make guessing tempting)\n- \"Just one quick fix\" seems obvious\n- You've already tried multiple fixes\n- A previous fix didn't work\n- A sub-agent or exploration returned a confident diagnosis\n\n**Don't skip when:**\n- Issue seems simple (simple bugs have root causes too)\n- You're in a hurry (rushing guarantees rework)\n\n## Pre-flight: check the Brain for overdue debt\n\nStandalone invocations only — **skip this section when called from `mobiai-fix-issue`**, which already runs its own pre-flight review and would otherwise double-prompt.\n\nIf `\u003Crepo>\u002F.mobiai\u002Fbrain\u002Fconfig.json` exists, do a quick review pass before forming hypotheses. The issue you're investigating might be related to a known workaround already logged as temporary debt; checking up front prevents re-deriving an answer that's already in the brain.\n\n**Preferred — MCP tool** (when `mobiai-brain` MCP server is registered):\n\nInvoke `mobile_review` with default args. From the returned `overdue` list, focus on entries whose `platform` matches the project's platform and whose `area` overlaps with the symptoms (component, module, feature where the bug shows up). 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 Phase 1:\n\n> \"Heads up — there are N overdue temporary workaround(s) in \u003Cplatform>\u002F\u003Carea> that may relate to what you're seeing: \u003Ctitle>. I'll proceed with the investigation; let me know if you want to look at those first.\"\n\nThen continue with Phase 1. Don't pause unless asked. Skip silently when:\n\n- The brain isn't initialized.\n- No overdue entries match the area \u002F platform of the issue.\n\n## Pre-flight: check the Graph for code structure\n\nStandalone invocations only — **skip this section when called from `mobiai-fix-issue`**, which already runs its own Graph pre-flight at Phase 1.\n\nThe Graph indexes Kotlin\u002FSwift symbols and can rank files by relevance to a symptom — useful for Phase 1 (Gather Evidence) and Phase 3 (Form a Hypothesis). Brain says \"what's known about this area\"; Graph says \"where the affected code lives today\".\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 relevant files from the symptom (top results = where to look first):\nmobiai graph context \"\u003Cone-line symptom or bug title>\"\n\n# If a symbol appears in the stack trace, find its callers:\nmobiai graph callers \u003CSymbolFromStackTrace>\n```\n\nIf the index is ≥1 day old, mention it to the user before continuing:\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 — let the user decide.\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 vuelvo a buscar — sin él tengo que grep a ciegas y leer más archivos de los necesarios.\"\n\nDon't run `init` autonomously.\n\n**Skip silently when**:\n\n- The project has no Kotlin\u002FSwift files (Flutter-only or RN-only without native code).\n- The bug is purely in resources, config, or build files (Graph won't help).\n\n## Phase 1: Gather Evidence\n\nBefore forming any opinion, collect the raw material.\n\n1. **Read error messages carefully**\n   - Don't skip past errors or warnings\n   - Read stack traces completely\n   - Note line numbers, file paths, error codes\n\n2. **Confirm reproducibility**\n   - Can you trigger it reliably?\n   - What are the exact steps?\n   - If not reproducible → gather more data, don't guess\n\n   | Platform | How to reproduce |\n   |----------|-----------------|\n   | **Android** | `adb logcat` for logs, reproduce on emulator, check specific API level |\n   | **iOS** | Xcode console or `simctl` logs, reproduce on simulator, check iOS version |\n   | **Flutter** | `flutter run` with `--verbose`, check both platforms |\n   | **React Native** | Metro console, `adb logcat` \u002F Xcode console, check native bridge errors |\n   | **KMP** | Reproduce on each target platform; check whether the issue is in shared code or platform-specific `actual` implementations |\n\n3. **Check recent changes & find the breaking commit**\n   - What changed that could cause this?\n   - `git log --oneline -20 -- \u003Caffected-file>` — commits that touched the affected file\n   - `git blame -L \u003Cline>,\u003Cline> \u003Cfile>` — which commit last changed the specific failing line\n   - `git log --all --grep=\"\u003Ckeyword>\"` — past related fixes that might show the introduction of a conflicting pattern\n   - **If this is a regression**: identify the commit that introduced the bug. Record its SHA and subject. Use `git bisect` when the history is dense or the search space is large. The breaking commit goes into the PR description (it helps the reviewer assess scope and decide backport priority).\n   - **If the bug has always existed** (not a regression): state that explicitly. \"Always-existed, not a regression\" is valid and important information for the reviewer — don't leave it ambiguous.\n   - New dependencies, config changes, Gradle\u002FSPM\u002Fpubspec bumps can themselves be the breaking commit.\n\n4. **Collect concrete evidence**\n\n   Add diagnostic instrumentation at component boundaries:\n\n   | Platform | Instrumentation |\n   |----------|----------------|\n   | **Android** | `Log.d(TAG, \"value=$value\")` at ViewModel, Repository, DAO boundaries |\n   | **iOS** | `print(\"value=\\(value)\")` or `os_log` at ViewModel, Service, Store boundaries |\n   | **Flutter** | `debugPrint(\"value=$value\")` at BLoC\u002FProvider, Repository, API boundaries |\n   | **React Native** | `console.log(\"value=\", value)` at component, hook, API boundaries |\n   | **KMP** | Log at the shared\u002Fexpect boundary AND at each `actual` implementation |\n\n5. **Identify affected platforms precisely**\n   - Does it happen on Android only? iOS only? Both? Specific OS versions? Specific devices?\n   - Precise platform scope often points directly at the root cause category.\n\n## Phase 2: State Known vs. Assumed\n\nSeparate what you actually observed from what you are inferring. List in two columns:\n\n- **Known** (direct evidence): log lines seen, stack traces captured, reproduction confirmed, git diff contents\n- **Assumed** (not yet verified): \"probably caused by X\", \"likely a threading issue\", \"the backend probably returned null\"\n\nEvery item in \"Assumed\" is a candidate to either verify (moving it to Known) or to drop.\n\n- **Fast path**: record the split internally, proceed directly to Phase 3.\n- **Gated path**: present the split to the user and wait for confirmation before Phase 3. If the user corrects an assumption, update the list.\n\n## Phase 3: Form a Hypothesis\n\nOne hypothesis at a time, stated specifically. Not \"it's a race condition\" — rather \"the ViewModel's `observeUser()` coroutine is cancelled by the Activity being recreated on rotation, so the subsequent emission is dropped\".\n\nCheck common mobile bug categories to frame the hypothesis:\n\n**Lifecycle bugs:**\n- Android: Activity\u002FFragment recreated after rotation? ViewModel cleared after process death? `onSaveInstanceState` missing?\n- iOS: View controller deallocated? `viewWillAppear` vs `viewDidLoad` timing? SceneDelegate lifecycle?\n- Flutter: Widget rebuilt unexpectedly? State lost on navigation? `dispose()` not called?\n- React Native: Component unmounted during async operation? Navigation state stale?\n\n**Threading bugs:**\n- Android: Accessing UI from background thread? Coroutine on wrong dispatcher?\n- iOS: UI update not on main thread? Data race in concurrent queue? `@MainActor` missing?\n- Flutter: Isolate communication issue? `setState` after dispose?\n- React Native: Native module callback on wrong thread?\n\n**Memory bugs:**\n- Android: Context leak in singleton? Inner class holding Activity reference?\n- iOS: Retain cycle in closure? Missing `[weak self]`?\n- Flutter: Stream subscription not cancelled? Controller not disposed?\n- React Native: Event listener not removed in cleanup?\n\n**Data bugs:**\n- SQL\u002FRoom\u002FCoreData: Wrong query? Migration missing? Schema mismatch?\n- SharedPreferences\u002FUserDefaults: Wrong key? Type mismatch?\n- API: Response format changed? Null field not handled?\n\n**KMP-specific:**\n- Divergence between `actual` implementations across platforms\n- Freezing\u002Fthreading models in legacy Kotlin\u002FNative\n- Serialization differences between JVM and Native\n\nState the single hypothesis in the form: \"I think X is the root cause because Y\". Be specific.\n\n## Phase 4: Verify the Hypothesis\n\nVerify against code and evidence, not against intuition.\n\n1. **Find working examples**\n   - Locate similar code in the same codebase that works\n   - What is different between the working and broken paths?\n   - List every difference, however small.\n\n2. **Test minimally**\n   - Make the SMALLEST possible change that would confirm or refute the hypothesis (a log line, a breakpoint, a one-line guard used only as a probe — not as a fix)\n   - One variable at a time\n\n3. **Read the code path carefully**\n   - Trace from the entry point down to where the bad value appears\n   - Fix at the source, not at the symptom\n   - If the hypothesis contradicts the code, the hypothesis is wrong — do not bend the evidence to match\n\n4. **If verification fails**\n   - Discard the hypothesis\n   - Return to Phase 3 and form a new one\n   - Do NOT stack fixes on top of an unverified theory\n\n## Phase 5: Present Root Cause\n\nOnce the hypothesis is verified, state:\n\n1. **The root cause** — one or two sentences, stated plainly\n2. **The evidence that proves it** — specific log lines, specific code locations, specific reproduction results\n3. **Why the symptom follows from the cause** — the causal chain from root cause to observed behavior\n4. **What is still uncertain**, if anything\n\n- **Fast path**: state the root cause concisely and proceed to Phase 6 without pausing. If you discover during Phase 4 that the evidence is contradictory or the hypothesis doesn't hold cleanly, upgrade to gated path before presenting.\n- **Gated path**: ask explicitly:\n\n  > \"This is the root cause I've identified and verified. Do you confirm this is correct before I propose a fix?\"\n\n  Wait for the user's explicit confirmation. If the user pushes back or points to evidence you missed, return to Phase 3 or Phase 4 as appropriate.\n\n## Phase 6: Hand Off to Implementation\n\nThe fix itself is not proposed inside this skill. `mobiai-mobile-debugging` ends when the root cause is stated (fast path) or confirmed (gated path).\n\n- If invoked from `mobiai-fix-issue`, return control — `mobiai-fix-issue`'s Phase 4 (Propose the Fix) takes over with its own gating rules. **Skip the Brain hook below** — `mobiai-fix-issue` runs its own save proposal at the end of Phase 6 (verification). Don't double-prompt.\n- Otherwise, **invoke skill `mobiai-mobile-tdd`** to write the failing test first, then the implementation.\n\n### Optional: capture root cause in MobiAI Brain\n\nStandalone invocations only (skip when called from `mobiai-fix-issue`). After the root cause is confirmed, check whether `\u003Crepo>\u002F.mobiai\u002Fbrain\u002Fconfig.json` exists. If it does NOT, skip silently.\n\nIf it does, judge whether the cause is worth remembering. Save when:\n\n- It's a platform gotcha that's likely to bite again (lifecycle timing, threading, build-config interaction).\n- The investigation surfaced a non-obvious causal chain that took real effort to find.\n- A workaround was identified that the project will keep using until a future cleanup.\n\nSkip when the cause is trivial (typo, obvious null, one-line bug with no broader pattern).\n\nWhen worth saving, **propose** the save to the user (one-line confirmation). Never invoke silently. Use `status: active` when the root cause is documented but no fix is applied yet (the entry serves as \"we understood this, future agents should know\"), or `status: temporary` with `review_after` when a workaround was applied that needs revisiting.\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_bugfix` with:\n\n- `title`: short, e.g. `\"Compose recomposition loop in LazyColumn with derivedStateOf\"`\n- `platform`: `android | ios | shared | kmp | flutter | react-native`\n- `area`: free-form, e.g. `\"compose\" | \"coroutines\" | \"gradle\"`\n- `status`: `active | temporary`\n- `review_after`: `\"YYYY-MM-DD\"` (only when status is temporary)\n- `files`: array of repo-relative file paths\n- `body`: Markdown with `### Symptom` \u002F `### Root Cause` \u002F `### Investigation Notes` \u002F `### Resolution`\n\n**Fallback — CLI** (if MCP isn't configured):\n\n```bash\nmobiai brain save bugfix \\\n  --title \"\u003Cshort, e.g. 'Compose recomposition loop in LazyColumn with derivedStateOf'>\" \\\n  --platform \u003Candroid|ios|shared|kmp|flutter|react-native> \\\n  --area \u003Cfree-form, e.g. compose | coroutines | gradle> \\\n  --status \u003Cactive|temporary> \\\n  --review-after \u003CYYYY-MM-DD if temporary> \\\n  --files \"\u003Cfile1>,\u003Cfile2>\" \\\n  --body \"### Symptom\nWhat the user observed.\n\n### Root Cause\nThe actual cause, in plain language.\n\n### Investigation Notes\nThe evidence that confirmed it — log lines, commits, behavior on different builds.\n\n### Resolution\nWhat was done about it (or 'documented only, no fix applied yet').\"\n```\n\nThe body fields are suggestions, not a rigid template. Use the structure that fits what you found.\n\n## Red Flags — STOP and Follow Process\n\nIf you catch yourself thinking:\n- \"Quick fix for now, investigate later\"\n- \"Just try changing X and see if it works\"\n- \"Add multiple changes, run tests\"\n- \"It's probably a threading issue\" (without evidence)\n- \"I'll add a null check here\" (without knowing why it's null)\n- \"Works on my emulator\" (without checking other devices)\n- \"The sub-agent said it's X, I'll go with that\" (without verifying against code)\n- **\"One more fix attempt\" (when already tried 2+)**\n\n**ALL of these mean: STOP. Return to Phase 1.**\n\n## Common Rationalizations\n\n| Excuse | Reality |\n|--------|---------|\n| \"Issue is simple, don't need process\" | Simple issues have root causes too. The phased flow is fast for simple bugs. |\n| \"Emergency, no time for process\" | Systematic debugging is FASTER than guess-and-check thrashing. |\n| \"Just try this first, then investigate\" | First fix sets the pattern. Do it right from the start. |\n| \"I'll write tests after confirming the fix works\" | Untested fixes don't stick. Test first proves it. |\n| \"This null check should handle it\" | Why is it null? That's the actual bug. |\n| \"Works on my device\" | There are thousands of device\u002FOS combinations. |\n| \"The Explore agent already diagnosed it\" | Sub-agents can be confidently wrong. Verify against the code. |\n| \"One more fix attempt\" (after 2+ failures) | 3+ failures = architectural problem. Question the pattern, don't fix again. |\n\n## Quick Reference\n\n| Phase | Key Activity | Fast path | Gated path |\n|-------|--------------|-----------|------------|\n| **1. Gather evidence** | Read errors, reproduce, check changes, instrument | Proceed autonomously | Proceed autonomously |\n| **2. Known vs. assumed** | Split facts from inferences | Record internally, proceed | Present to user, wait for confirmation |\n| **3. Hypothesis** | Single specific testable theory | Proceed autonomously | Proceed autonomously |\n| **4. Verify** | Compare to working code, test minimally | Proceed autonomously | Proceed autonomously |\n| **5. Root cause** | Present cause + evidence + causal chain | State and proceed to Phase 6 | Ask user to confirm before Phase 6 |\n| **6. Hand off** | Return to `mobiai-fix-issue` or invoke `mobiai-mobile-tdd` | Implementation begins elsewhere | Implementation begins elsewhere |\n\n## Related Skills\n\n- **`mobiai-fix-issue`** — the broader pipeline; calls this skill for its Phase 3. The scope classification (fast\u002Fgated) declared in `mobiai-fix-issue` is inherited by this skill.\n- **`mobiai-mobile-tdd`** — for creating the failing test once the root cause is confirmed\n- **`mobiai-mobile-verification`** — to verify the fix worked before claiming success\n- **`mobiai-reproduce-bug`** — for driving a device\u002Femulator\u002Fsimulator to reproduce the bug in Phase 1 (use only when `mobiai-fix-issue` Phase 2 authorized reproduction; do not invoke autonomously)\n","# Systematic Mobile Debugging\n\nRandom fixes waste time and create new bugs. Quick patches mask underlying issues.\n\n**Core principle:** ALWAYS find root cause before attempting fixes. Symptom fixes are failure.\n\n\u003CHARD-GATE>\nYou MUST NOT propose any fix, write any code, edit any production file, refactor any surrounding code, or invoke `mobiai-mobile-tdd` until you have (a) gathered evidence, (b) separated what is known from what is assumed, (c) formed and verified a hypothesis, and (d) stated the root cause.\n\nWhether you also need **explicit user confirmation** at steps (b) and (d) depends on the scope classification inherited from the caller (or declared at Pre-flight below). Fast path: no confirmation gate, proceed autonomously. Gated path: explicit confirmation required at both steps.\n\u003C\u002FHARD-GATE>\n\n## Anti-Pattern: \"It's Obviously X\"\n\nThe most common failure mode is pattern-matching the symptom to a familiar-looking cause and proposing a fix before the evidence supports it — especially when a sub-agent or exploration returns a confident diagnosis that was never cross-checked against the code. Threading, null, lifecycle, cache, \"the backend changed\" — all tempting guesses. Every bug goes through the phased flow.\n\nThe scope classification only changes **whether you wait for user confirmation**, not **whether you do the analysis**. Fast path still gathers evidence, splits known vs. assumed, forms and verifies a hypothesis, and states the root cause — it just returns that result to the caller instead of pausing for approval.\n\n## The Iron Law\n\n```\nNO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST\n```\n\n## Pre-flight: Scope Classification\n\nThis skill inherits the scope from its caller (typically `mobiai-fix-issue`). If invoked standalone, classify at the start:\n\n**Fast path** — work autonomously through all phases; return the verified root cause to the caller at Phase 6:\n- Clear symptom with obvious evidence (stack trace points at a specific line, log message is explicit)\n- Single root cause category (not contradictory evidence)\n- No architectural question, no cross-module mystery\n\n**Gated path** — stop and wait for user confirmation at Phase 2 and Phase 5:\n- Contradictory evidence or multiple plausible causes\n- Cross-module \u002F cross-platform investigation required\n- Root cause involves architectural choices (e.g., \"should this be on the main thread?\")\n- Previous fix attempts failed\n\nIn doubt → gated path.\n\n## Checklist\n\nYou MUST create a task for each of these items and complete them in order. Do not skip phases. Do not merge phases.\n\n1. **Gather evidence** — logs, stack traces, reproduction steps, affected platforms, recent changes\n2. **State known vs. assumed** — label each fact as observed or inferred (gated path: present to the user and wait for confirmation; fast path: record the split internally and proceed)\n3. **Form a hypothesis** — a single, specific, testable theory about the root cause\n4. **Verify the hypothesis** — against code and evidence, not against intuition\n5. **Present the root cause** (gated path: wait for user confirmation before Phase 6; fast path: state the root cause and proceed to Phase 6)\n6. **Hand off to implementation** — return control to `mobiai-fix-issue` if the broader pipeline is active, or invoke `mobiai-mobile-tdd`\n\n## When to Use\n\nUse for ANY mobile technical issue:\n- Test failures\n- Bugs in production\n- Unexpected behavior\n- Performance problems\n- Build failures\n- Crashes\n\n**Use this ESPECIALLY when:**\n- Under time pressure (emergencies make guessing tempting)\n- \"Just one quick fix\" seems obvious\n- You've already tried multiple fixes\n- A previous fix didn't work\n- A sub-agent or exploration returned a confident diagnosis\n\n**Don't skip when:**\n- Issue seems simple (simple bugs have root causes too)\n- You're in a hurry (rushing guarantees rework)\n\n## Pre-flight: check the Brain for overdue debt\n\nStandalone invocations only — **skip this section when called from `mobiai-fix-issue`**, which already runs its own pre-flight review and would otherwise double-prompt.\n\nIf `\u003Crepo>\u002F.mobiai\u002Fbrain\u002Fconfig.json` exists, do a quick review pass before forming hypotheses. The issue you're investigating might be related to a known workaround already logged as temporary debt; checking up front prevents re-deriving an answer that's already in the brain.\n\n**Preferred — MCP tool** (when `mobiai-brain` MCP server is registered):\n\nInvoke `mobile_review` with default args. From the returned `overdue` list, focus on entries whose `platform` matches the project's platform and whose `area` overlaps with the symptoms (component, module, feature where the bug shows up). 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 Phase 1:\n\n> \"Heads up — there are N overdue temporary workaround(s) in \u003Cplatform>\u002F\u003Carea> that may relate to what you're seeing: \u003Ctitle>. I'll proceed with the investigation; let me know if you want to look at those first.\"\n\nThen continue with Phase 1. Don't pause unless asked. Skip silently when:\n\n- The brain isn't initialized.\n- No overdue entries match the area \u002F platform of the issue.\n\n## Pre-flight: check the Graph for code structure\n\nStandalone invocations only — **skip this section when called from `mobiai-fix-issue`**, which already runs its own Graph pre-flight at Phase 1.\n\nThe Graph indexes Kotlin\u002FSwift symbols and can rank files by relevance to a symptom — useful for Phase 1 (Gather Evidence) and Phase 3 (Form a Hypothesis). Brain says \"what's known about this area\"; Graph says \"where the affected code lives today\".\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 relevant files from the symptom (top results = where to look first):\nmobiai graph context \"\u003Cone-line symptom or bug title>\"\n\n# If a symbol appears in the stack trace, find its callers:\nmobiai graph callers \u003CSymbolFromStackTrace>\n```\n\nIf the index is ≥1 day old, mention it to the user before continuing:\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 — let the user decide.\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 vuelvo a buscar — sin él tengo que grep a ciegas y leer más archivos de los necesarios.\"\n\nDon't run `init` autonomously.\n\n**Skip silently when**:\n\n- The project has no Kotlin\u002FSwift files (Flutter-only or RN-only without native code).\n- The bug is purely in resources, config, or build files (Graph won't help).\n\n## Phase 1: Gather Evidence\n\nBefore forming any opinion, collect the raw material.\n\n1. **Read error messages carefully**\n   - Don't skip past errors or warnings\n   - Read stack traces completely\n   - Note line numbers, file paths, error codes\n\n2. **Confirm reproducibility**\n   - Can you trigger it reliably?\n   - What are the exact steps?\n   - If not reproducible → gather more data, don't guess\n\n   | Platform | How to reproduce |\n   |----------|-----------------|\n   | **Android** | `adb logcat` for logs, reproduce on emulator, check specific API level |\n   | **iOS** | Xcode console or `simctl` logs, reproduce on simulator, check iOS version |\n   | **Flutter** | `flutter run` with `--verbose`, check both platforms |\n   | **React Native** | Metro console, `adb logcat` \u002F Xcode console, check native bridge errors |\n   | **KMP** | Reproduce on each target platform; check whether the issue is in shared code or platform-specific `actual` implementations |\n\n3. **Check recent changes & find the breaking commit**\n   - What changed that could cause this?\n   - `git log --oneline -20 -- \u003Caffected-file>` — commits that touched the affected file\n   - `git blame -L \u003Cline>,\u003Cline> \u003Cfile>` — which commit last changed the specific failing line\n   - `git log --all --grep=\"\u003Ckeyword>\"` — past related fixes that might show the introduction of a conflicting pattern\n   - **If this is a regression**: identify the commit that introduced the bug. Record its SHA and subject. Use `git bisect` when the history is dense or the search space is large. The breaking commit goes into the PR description (it helps the reviewer assess scope and decide backport priority).\n   - **If the bug has always existed** (not a regression): state that explicitly. \"Always-existed, not a regression\" is valid and important information for the reviewer — don't leave it ambiguous.\n   - New dependencies, config changes, Gradle\u002FSPM\u002Fpubspec bumps can themselves be the breaking commit.\n\n4. **Collect concrete evidence**\n\n   Add diagnostic instrumentation at component boundaries:\n\n   | Platform | Instrumentation |\n   |----------|----------------|\n   | **Android** | `Log.d(TAG, \"value=$value\")` at ViewModel, Repository, DAO boundaries |\n   | **iOS** | `print(\"value=\\(value)\")` or `os_log` at ViewModel, Service, Store boundaries |\n   | **Flutter** | `debugPrint(\"value=$value\")` at BLoC\u002FProvider, Repository, API boundaries |\n   | **React Native** | `console.log(\"value=\", value)` at component, hook, API boundaries |\n   | **KMP** | Log at the shared\u002Fexpect boundary AND at each `actual` implementation |\n\n5. **Identify affected platforms precisely**\n   - Does it happen on Android only? iOS only? Both? Specific OS versions? Specific devices?\n   - Precise platform scope often points directly at the root cause category.\n\n## Phase 2: State Known vs. Assumed\n\nSeparate what you actually observed from what you are inferring. List in two columns:\n\n- **Known** (direct evidence): log lines seen, stack traces captured, reproduction confirmed, git diff contents\n- **Assumed** (not yet verified): \"probably caused by X\", \"likely a threading issue\", \"the backend probably returned null\"\n\nEvery item in \"Assumed\" is a candidate to either verify (moving it to Known) or to drop.\n\n- **Fast path**: record the split internally, proceed directly to Phase 3.\n- **Gated path**: present the split to the user and wait for confirmation before Phase 3. If the user corrects an assumption, update the list.\n\n## Phase 3: Form a Hypothesis\n\nOne hypothesis at a time, stated specifically. Not \"it's a race condition\" — rather \"the ViewModel's `observeUser()` coroutine is cancelled by the Activity being recreated on rotation, so the subsequent emission is dropped\".\n\nCheck common mobile bug categories to frame the hypothesis:\n\n**Lifecycle bugs:**\n- Android: Activity\u002FFragment recreated after rotation? ViewModel cleared after process death? `onSaveInstanceState` missing?\n- iOS: View controller deallocated? `viewWillAppear` vs `viewDidLoad` timing? SceneDelegate lifecycle?\n- Flutter: Widget rebuilt unexpectedly? State lost on navigation? `dispose()` not called?\n- React Native: Component unmounted during async operation? Navigation state stale?\n\n**Threading bugs:**\n- Android: Accessing UI from background thread? Coroutine on wrong dispatcher?\n- iOS: UI update not on main thread? Data race in concurrent queue? `@MainActor` missing?\n- Flutter: Isolate communication issue? `setState` after dispose?\n- React Native: Native module callback on wrong thread?\n\n**Memory bugs:**\n- Android: Context leak in singleton? Inner class holding Activity reference?\n- iOS: Retain cycle in closure? Missing `[weak self]`?\n- Flutter: Stream subscription not cancelled? Controller not disposed?\n- React Native: Event listener not removed in cleanup?\n\n**Data bugs:**\n- SQL\u002FRoom\u002FCoreData: Wrong query? Migration missing? Schema mismatch?\n- SharedPreferences\u002FUserDefaults: Wrong key? Type mismatch?\n- API: Response format changed? Null field not handled?\n\n**KMP-specific:**\n- Divergence between `actual` implementations across platforms\n- Freezing\u002Fthreading models in legacy Kotlin\u002FNative\n- Serialization differences between JVM and Native\n\nState the single hypothesis in the form: \"I think X is the root cause because Y\". Be specific.\n\n## Phase 4: Verify the Hypothesis\n\nVerify against code and evidence, not against intuition.\n\n1. **Find working examples**\n   - Locate similar code in the same codebase that works\n   - What is different between the working and broken paths?\n   - List every difference, however small.\n\n2. **Test minimally**\n   - Make the SMALLEST possible change that would confirm or refute the hypothesis (a log line, a breakpoint, a one-line guard used only as a probe — not as a fix)\n   - One variable at a time\n\n3. **Read the code path carefully**\n   - Trace from the entry point down to where the bad value appears\n   - Fix at the source, not at the symptom\n   - If the hypothesis contradicts the code, the hypothesis is wrong — do not bend the evidence to match\n\n4. **If verification fails**\n   - Discard the hypothesis\n   - Return to Phase 3 and form a new one\n   - Do NOT stack fixes on top of an unverified theory\n\n## Phase 5: Present Root Cause\n\nOnce the hypothesis is verified, state:\n\n1. **The root cause** — one or two sentences, stated plainly\n2. **The evidence that proves it** — specific log lines, specific code locations, specific reproduction results\n3. **Why the symptom follows from the cause** — the causal chain from root cause to observed behavior\n4. **What is still uncertain**, if anything\n\n- **Fast path**: state the root cause concisely and proceed to Phase 6 without pausing. If you discover during Phase 4 that the evidence is contradictory or the hypothesis doesn't hold cleanly, upgrade to gated path before presenting.\n- **Gated path**: ask explicitly:\n\n  > \"This is the root cause I've identified and verified. Do you confirm this is correct before I propose a fix?\"\n\n  Wait for the user's explicit confirmation. If the user pushes back or points to evidence you missed, return to Phase 3 or Phase 4 as appropriate.\n\n## Phase 6: Hand Off to Implementation\n\nThe fix itself is not proposed inside this skill. `mobiai-mobile-debugging` ends when the root cause is stated (fast path) or confirmed (gated path).\n\n- If invoked from `mobiai-fix-issue`, return control — `mobiai-fix-issue`'s Phase 4 (Propose the Fix) takes over with its own gating rules. **Skip the Brain hook below** — `mobiai-fix-issue` runs its own save proposal at the end of Phase 6 (verification). Don't double-prompt.\n- Otherwise, **invoke skill `mobiai-mobile-tdd`** to write the failing test first, then the implementation.\n\n### Optional: capture root cause in MobiAI Brain\n\nStandalone invocations only (skip when called from `mobiai-fix-issue`). After the root cause is confirmed, check whether `\u003Crepo>\u002F.mobiai\u002Fbrain\u002Fconfig.json` exists. If it does NOT, skip silently.\n\nIf it does, judge whether the cause is worth remembering. Save when:\n\n- It's a platform gotcha that's likely to bite again (lifecycle timing, threading, build-config interaction).\n- The investigation surfaced a non-obvious causal chain that took real effort to find.\n- A workaround was identified that the project will keep using until a future cleanup.\n\nSkip when the cause is trivial (typo, obvious null, one-line bug with no broader pattern).\n\nWhen worth saving, **propose** the save to the user (one-line confirmation). Never invoke silently. Use `status: active` when the root cause is documented but no fix is applied yet (the entry serves as \"we understood this, future agents should know\"), or `status: temporary` with `review_after` when a workaround was applied that needs revisiting.\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_bugfix` with:\n\n- `title`: short, e.g. `\"Compose recomposition loop in LazyColumn with derivedStateOf\"`\n- `platform`: `android | ios | shared | kmp | flutter | react-native`\n- `area`: free-form, e.g. `\"compose\" | \"coroutines\" | \"gradle\"`\n- `status`: `active | temporary`\n- `review_after`: `\"YYYY-MM-DD\"` (only when status is temporary)\n- `files`: array of repo-relative file paths\n- `body`: Markdown with `### Symptom` \u002F `### Root Cause` \u002F `### Investigation Notes` \u002F `### Resolution`\n\n**Fallback — CLI** (if MCP isn't configured):\n\n```bash\nmobiai brain save bugfix \\\n  --title \"\u003Cshort, e.g. 'Compose recomposition loop in LazyColumn with derivedStateOf'>\" \\\n  --platform \u003Candroid|ios|shared|kmp|flutter|react-native> \\\n  --area \u003Cfree-form, e.g. compose | coroutines | gradle> \\\n  --status \u003Cactive|temporary> \\\n  --review-after \u003CYYYY-MM-DD if temporary> \\\n  --files \"\u003Cfile1>,\u003Cfile2>\" \\\n  --body \"### Symptom\nWhat the user observed.\n\n### Root Cause\nThe actual cause, in plain language.\n\n### Investigation Notes\nThe evidence that confirmed it — log lines, commits, behavior on different builds.\n\n### Resolution\nWhat was done about it (or 'documented only, no fix applied yet').\"\n```\n\nThe body fields are suggestions, not a rigid template. Use the structure that fits what you found.\n\n## Red Flags — STOP and Follow Process\n\nIf you catch yourself thinking:\n- \"Quick fix for now, investigate later\"\n- \"Just try changing X and see if it works\"\n- \"Add multiple changes, run tests\"\n- \"It's probably a threading issue\" (without evidence)\n- \"I'll add a null check here\" (without knowing why it's null)\n- \"Works on my emulator\" (without checking other devices)\n- \"The sub-agent said it's X, I'll go with that\" (without verifying against code)\n- **\"One more fix attempt\" (when already tried 2+)**\n\n**ALL of these mean: STOP. Return to Phase 1.**\n\n## Common Rationalizations\n\n| Excuse | Reality |\n|--------|---------|\n| \"Issue is simple, don't need process\" | Simple issues have root causes too. The phased flow is fast for simple bugs. |\n| \"Emergency, no time for process\" | Systematic debugging is FASTER than guess-and-check thrashing. |\n| \"Just try this first, then investigate\" | First fix sets the pattern. Do it right from the start. |\n| \"I'll write tests after confirming the fix works\" | Untested fixes don't stick. Test first proves it. |\n| \"This null check should handle it\" | Why is it null? That's the actual bug. |\n| \"Works on my device\" | There are thousands of device\u002FOS combinations. |\n| \"The Explore agent already diagnosed it\" | Sub-agents can be confidently wrong. Verify against the code. |\n| \"One more fix attempt\" (after 2+ failures) | 3+ failures = architectural problem. Question the pattern, don't fix again. |\n\n## Quick Reference\n\n| Phase | Key Activity | Fast path | Gated path |\n|-------|--------------|-----------|------------|\n| **1. Gather evidence** | Read errors, reproduce, check changes, instrument | Proceed autonomously | Proceed autonomously |\n| **2. Known vs. assumed** | Split facts from inferences | Record internally, proceed | Present to user, wait for confirmation |\n| **3. Hypothesis** | Single specific testable theory | Proceed autonomously | Proceed autonomously |\n| **4. Verify** | Compare to working code, test minimally | Proceed autonomously | Proceed autonomously |\n| **5. Root cause** | Present cause + evidence + causal chain | State and proceed to Phase 6 | Ask user to confirm before Phase 6 |\n| **6. Hand off** | Return to `mobiai-fix-issue` or invoke `mobiai-mobile-tdd` | Implementation begins elsewhere | Implementation begins elsewhere |\n\n## Related Skills\n\n- **`mobiai-fix-issue`** — the broader pipeline; calls this skill for its Phase 3. The scope classification (fast\u002Fgated) declared in `mobiai-fix-issue` is inherited by this skill.\n- **`mobiai-mobile-tdd`** — for creating the failing test once the root cause is confirmed\n- **`mobiai-mobile-verification`** — to verify the fix worked before claiming success\n- **`mobiai-reproduce-bug`** — for driving a device\u002Femulator\u002Fsimulator to reproduce the bug in Phase 1 (use only when `mobiai-fix-issue` Phase 2 authorized reproduction; do not invoke autonomously)\n",{"name":5,"license":15,"platforms":44,"description":7,"compatibility":49},[45,46,47,48,29],"android","ios","kmp","flutter",[50,51,37,52,53],"claude-code","cursor","codex","gemini","main","2edc6ac1cde2cc280ae0388aa8072902d2e230d5","skills\u002Fcore\u002Fskills\u002Fmobiai-mobile-debugging",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":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add ArisGuimera\u002FMobiAI-Core --skill mobiai-mobile-debugging",{"tool":69,"command":70},"bunx","bunx skills add ArisGuimera\u002FMobiAI-Core --skill mobiai-mobile-debugging",{"tool":72,"command":73},"pnpm","pnpm dlx skills add ArisGuimera\u002FMobiAI-Core --skill mobiai-mobile-debugging","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FArisGuimera\u002FMobiAI-Core\u002Fblob\u002Fmain\u002Fskills\u002Fcore\u002Fskills\u002Fmobiai-mobile-debugging\u002FSKILL.md",true,[],[78,102,115,133,151,165],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":92,"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",[84,89],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",{"categoryNo":90,"categoryName":91,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000009","前端开发",[30,93,27,94,95,52,37,20,96,36,97,98,51,99,100,29,50,101],"react native","mobiai react native","testing","state management","state","management","use","navigation","project",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":109,"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",[108],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},[110,95,52,37,36,111,112,51,99,50,113,101,114],"mobiai kmp","kotlin","kotlin multiplatform","shared","platform",{"skillNo":116,"name":117,"nameZh":6,"description":118,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":119,"categories":120,"keywords":122,"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",[121],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},[95,46,123,124,125,52,126,37,36,127,128,129,51,130,99,50,101,131,132],"ios testing","mobiai ios testing","writing","unit tests","framework","running tests","ui","snapshot","tests","unit",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"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",[],[46,140,141,142,52,37,143,36,144,145,146,51,99,147,148,50,149,150],"device","mobiai ios device","screenshots","run","logs","capture","read","manage","ios simulator","commands","with",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"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",[],[46,158,159,160,52,37,36,161,51,99,162,50,101,150,163,164],"build","ios build","mobiai ios build","troubleshooting","dependencies","spm","cocoapods",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":171,"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",[],[172,46,173,174,52,175,37,36,176,177,51,99,178,179,101,180,181,182,183,184],"architecture","ios architecture","mobiai ios architecture","project structure","refactoring","find","patterns","structure","understand","changes","codebase","Existing","features"]