using-mobiai

name	using-mobiai
description	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
license	MIT
compatibility	["claude-code","cursor","copilot","codex","gemini"]

If you were dispatched as a subagent to execute a specific, scoped task, skip this skill. Your parent agent is responsible for skill routing. 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.

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

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 — <topic>. <one-sentence framing>

• A) <option> — <one-line tradeoff>
• B) <option> — <one-line tradeoff> ← recommend, <reason>
• C) <option> — <one-line tradeoff>

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 (MIT). See NOTICE.md for attribution.