# Using Mobiai

> Use when starting any conversation — establishes how to find and invoke MobiAI skills, requiring `Skill` tool invocation before ANY response including clarifying questions, git/file reads, or code exploration

- Skill: `arisguimera/using-mobiai` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add arisguimera/using-mobiai`
- Raw SKILL.md: https://api.skillmd.com/api/skills/arisguimera/using-mobiai/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: MIT
- Author: arisguimera (https://skillmd.com/u/arisguimera)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/arisguimera/using-mobiai

---


<SUBAGENT-STOP>
If you were dispatched as a subagent to execute a specific, scoped task, skip this skill. Your parent agent is responsible for skill routing.
</SUBAGENT-STOP>

<EXTREMELY-IMPORTANT>
If you think there is even a 1% chance a MobiAI skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill via the `Skill` tool.

IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.

This is not negotiable. This is not optional. You cannot rationalize your way out of this.
</EXTREMELY-IMPORTANT>

## Instruction Priority

MobiAI skills override default system-prompt behavior, but **user instructions always take precedence**:

1. **User's explicit instructions** (CLAUDE.md, GEMINI.md, AGENTS.md, direct requests) — highest priority
2. **MobiAI skills** — override default behavior where they conflict
3. **Default system prompt** — lowest priority

If a CLAUDE.md or user message conflicts with a skill's workflow, follow the user. The user is in control.

## How to Access Skills

**In Claude Code:** Call the `Skill` tool with the skill name (e.g. `Skill(mobiai-fix-issue)`). The SKILL.md body is returned as the tool result — follow it directly. **Never use the `Read` tool on `SKILL.md` files** — that bypasses invocation and is not activation.

**In Copilot CLI:** Call the `skill` tool. Skills are auto-discovered from installed plugins.

**In Gemini CLI:** Call `activate_skill` with the skill name.

**In Codex:** Skills are discovered natively from the symlinked skills directory. See `.codex/INSTALL.md`.

**In other environments:** Check your platform's documentation for how skills are invoked.

## Quick Decision Guide

Match the user's intent against the rows below. If any row matches even at 1% confidence — invoke that skill FIRST, before any other tool call.

| User intent | Skill to invoke |
|-------------|-----------------|
| User reports a bug / shares a ticket (Jira, Linear, GitHub issues) | `mobiai-fix-issue` |
| User shares a commit SHA + says the fix didn't work, or asks whether a commit resolves a bug | `mobiai-mobile-debugging` (or `mobiai-fix-issue` if the ticket is still open) |
| User shares a crash, stack trace, or error | `mobiai-analyze-crash` |
| User mentions Firebase Crashlytics specifically | `mobiai-crashlytics` |
| User wants to reproduce a bug on device/emulator/simulator | `mobiai-reproduce-bug` |
| User asks to write or add tests | `mobiai-write-tests` |
| User asks for a code review | `mobiai-review-code` |
| User wants to commit, push, or open a PR (says "mergear", "push", "subir", "dale PR", "shipeá", "commit", "merge") | `mobiai-create-pr` |
| Interact with Android device/emulator (adb, screenshots, logcat) | `mobiai-android-device` |
| Build an Android project (Gradle, flavors, variants) | `mobiai-android-build` |
| Interact with iOS Simulator (simctl) | `mobiai-ios-device` |
| Build an iOS project (xcodebuild, schemes) | `mobiai-ios-build` |
| Working on a Kotlin Multiplatform project | `mobiai-kmp` |
| Working on a Flutter project | `mobiai-flutter` |
| Working on a React Native project | `mobiai-react-native` |
| Need to understand Android project structure | `mobiai-android-architecture` |
| Need to understand iOS project structure | `mobiai-ios-architecture` |
| Writing Android tests specifically | `mobiai-android-testing` |
| Writing iOS tests specifically | `mobiai-ios-testing` |
| Design a new feature with **unclear intent or requirements** (user still exploring what to build) | `mobiai-mobile-brainstorming` |
| Bug or unexpected behavior, need root cause | `mobiai-mobile-debugging` |
| Implementing a feature/fix with tests first | `mobiai-mobile-tdd` |
| User gives a **defined task list (3+ items)** or a multi-step spec — intent clear, "how" missing | `mobiai-mobile-planning` |
| About to claim work is done | `mobiai-mobile-verification` |
| Have a written plan to execute step by step | `mobiai-mobile-executing-plans` |
| 2+ independent tasks to parallelize (says "en paralelo", "orquestador", "agentes al mismo tiempo", "waves", "al mismo tiempo") | `mobiai-mobile-parallel-agents` |
| Executing a plan via subagents (says "ejecutá el plan", "implementalo", "arrancá con esto", "hacelo con agentes") | `mobiai-mobile-executing-plans-with-subagents` |
| Starting feature work in isolation | `mobiai-mobile-worktrees` |
| Implementation done, need to integrate | `mobiai-mobile-finishing-branch` |
| Creating a new MobiAI skill | `mobiai-writing-skills` |
| User asks about code impact, call graph, callers/callees, "where is X used", semantic exploration of the codebase | `mobiai-graph` |
| User asks about project decisions, bugfixes, workarounds, or "what did we decide last time" | `mobiai-brain` |
| SessionStart banner avisa que hay un MobiAI update disponible, o el usuario pide actualizar MobiAI | `mobiai-update` |

If the request doesn't match any row, ask the user to clarify before touching code. Do not improvise a workflow.

## The Rule

**Invoke relevant skills BEFORE any response or action** — including clarifying questions, reading files, running `git show` or `git log`, spawning subagents, or exploring the filesystem. Even a 1% chance a skill might apply means invoke it to check. If the invoked skill turns out not to fit, you can move on — but the check must happen first.

## Announce What You're Using

Immediately after invoking a skill, announce one sentence to the user:

> "Using `mobiai-fix-issue` to investigate the QA-548 ticket you shared."

This makes the invocation visible and commits you to following the skill's workflow instead of drifting back to improvisation.

## Asking the User

When a skill needs decisions or clarifications from the user, ask **one question at a time** — never batch multiple decisions into a single message.

**The rule:**
1. Identify all open questions internally.
2. Ask only the **first** one. Present it as multiple choice (A/B/C) with a recommended option and a one-line reason for the recommendation.
3. **Wait for the answer.** The user may pick an option, push back, or open a side discussion — engage with that before moving on.
4. Once resolved, ask the next question. Repeat until done.

**Why this matters:** Dumping 5+ decisions in one message forces the user to context-switch through all of them at once and short-circuits the chance to debate any single choice. One-at-a-time keeps the dialogue tight, and earlier answers often reshape later questions (eliminating some entirely).

**Format each question like this:**

> **D1 — &lt;topic&gt;.** &lt;one-sentence framing&gt;
> - **A)** &lt;option&gt; — &lt;one-line tradeoff&gt;
> - **B)** &lt;option&gt; — &lt;one-line tradeoff&gt; ← **recommend**, &lt;reason&gt;
> - **C)** &lt;option&gt; — &lt;one-line tradeoff&gt;
>
> Pick one, or push back if none of these fit.

**Exceptions:**
- The user explicitly asks for everything at once ("dame todas las decisiones de un saque", "tirame el plan completo", "give me all the questions"). Follow that instruction.
- Purely informational previews (a triage table, a list of findings) where no decision is required yet — those can be longer. But the **questions** that follow them must still come one at a time.

**Anti-patterns:**
- Six decisions + a "confirm everything and let's go" in a single message.
- Open-ended questions with no options ("what do you want to do about photos?") — always offer concrete A/B/C choices with a recommendation.
- Asking the next question before the user has confirmed (or pushed back on) the previous one.
- Hiding the recommendation ("here are three options, which do you prefer?"). Always state which one you'd pick and why.

This rule applies to **every** skill — `mobiai-mobile-brainstorming`, `mobiai-mobile-planning`, `mobiai-mobile-parallel-agents`, `mobiai-fix-issue`, anything that gathers user input. If a downstream skill seems to want a batch of questions, override it: ask one at a time anyway.

## Red Flags

These thoughts mean STOP — you're rationalizing:

| Thought | Reality |
|---------|---------|
| "This is just a diagnostic question, not a fix request" | Diagnostic questions about broken code are tasks. `mobiai-mobile-debugging` exists for exactly this. Invoke it. |
| "Let me `git show` this commit quickly first" | `git show` output lacks ticket context. Invoke the skill first — it tells you HOW to read the commit. |
| "Let me grep the codebase to understand first" | Skills tell you HOW to explore. Check the guide first. |
| "The user is asking a question, not a task" | Questions that need code investigation are tasks. Check the guide. |
| "I already fixed a bug this session, I know the pattern" | Each task gets its own skill check. Momentum ≠ authorization. |
| "I remember what this skill does from last session" | Skills evolve. Invoke it to read the current version. |
| "This looks like a simple one-liner, the skill is overkill" | HARD-GATEs apply regardless of size. Simple fixes still need invocation. |
| "The user shared a commit SHA, so it's a research request" | Commit SHA + "doesn't work" = debugging task. Invoke `mobiai-mobile-debugging`. |
| "Let me check current branch/state quickly first" | `git status`/`git log` without a skill loaded is improvisation. Invoke first. |
| "The user said 'mirá este error' — that's passive, not a task" | Requests to look at broken code are tasks. Invoke. |
| "I need more context before I can pick a skill" | Pick the closest match at 1% confidence. Wrong-skill is recoverable; no-skill is not. |
| "I'll just do this one thing first" | Check the guide BEFORE doing anything. |

## Anti-Pattern: "From Memory"

A subtle variant: you remember what a skill does from a previous session and you reproduce its steps in-session without ever calling `Skill(...)`.

That is not activation. The skill's HARD-GATEs, phase boundaries, approval checkpoints, and platform-specific branching only come into force once the `Skill` tool has loaded the current SKILL.md body. If you catch yourself thinking "I don't need to invoke it, I remember what it does" — that is the exact moment to invoke it.

## Skill Priority

When multiple skills could apply:

1. **Process skills first** (`mobiai-mobile-brainstorming`, `mobiai-mobile-debugging`) — determine HOW to approach the task.
2. **Workflow skills second** (`mobiai-fix-issue`, `mobiai-create-pr`) — orchestrate multi-phase work and delegate to process/implementation skills as sub-steps.
3. **Implementation skills third** (`mobiai-android-build`, `mobiai-ios-device`, platform-specifics) — guide execution.

Examples:
- "Fix QA-548" → `mobiai-fix-issue` (workflow). It will internally invoke debugging, TDD, verification, and create-pr.
- "Design feature X" → `mobiai-mobile-brainstorming` first, then planning/implementation.

## Platform Detection

Read the project structure to pick platform-specific skills:

- `build.gradle(.kts)` → Android → `mobiai-android-*`
- `*.xcodeproj` / `*.xcworkspace` → iOS → `mobiai-ios-*`
- `shared/` + `composeApp/` → KMP → `mobiai-kmp`
- `pubspec.yaml` → Flutter → `mobiai-flutter`
- `package.json` + `metro.config.js` / `app.json` → React Native → `mobiai-react-native`

Always read the project's `CLAUDE.md` (or equivalent) for project-specific conventions.

## Principles

- **Minimal fixes**: Change only what's necessary. No drive-by refactors.
- **Evidence-based**: Verify compile + tests pass before declaring done.
- **Platform-native**: Follow each platform's conventions and idioms.
- **Community-driven**: Found a gap? Use `mobiai-writing-skills` to contribute.

---

*The structure and tone of this bootstrap are inspired by Jesse Vincent's [Superpowers](https://github.com/obra/superpowers) (MIT). See `NOTICE.md` for attribution.*

