---

name: create-mobile-app description: Use when the user wants to start a new Power Apps mobile app (Expo / React Native / TypeScript, targeting iOS and Android) from scratch. user-invocable: true allowed-tools: Read, Write, Edit, Bash, Glob, Grep, AskUserQuestion, Skill, Task, EnterPlanMode, ExitPlanMode model: opus

Plugin check: Run node "${PLUGIN_ROOT}/scripts/check-version.js" - if it outputs a message, show it to the user before proceeding.

📋 Shared instructions: shared-instructions.md — read first. Covers safety guardrails, memory bank usage, preferred-environment policy, connector-first rule, Windows CLI compat, command-failure handling.

Create Power Apps Code App (Native)

Top-level orchestrator. Owns the user-visible flow; delegates planning to the native-app-planner agent and per-domain mutation to dedicated /add-* skills.

Workflow

Resume/template checks → prerequisites → requirements (iOS + Android fixed) → rough plan preview → Gate 1 architecture (native capabilities, connectors, then data platform) → Gate 2 Dataverse model when selected → Gates 3 and 4 screen graph/specifications → environment and template preparation → app initialization → design system → conditional Dataverse materialization and sample data → Mobile Offline Profile offer for Dataverse apps → native capabilities and connectors → navigation and screens → validation, preview, and summary.

---

Fresh-template working-directory mode

This skill assumes the user already has a fresh microsoft/power-platform-skills/plugins/mobile-apps/template#main template materialized with degit in the target working directory and has already run npm install there. The skill turns that fresh template into an app; it does not clone, degit, or copy a template itself.

Fresh template required. If the working directory is not a template, or if it already looks like an app created by this skill, STOP and tell the user to materialize a fresh microsoft/power-platform-skills/plugins/mobile-apps/template#main template with degit into a new folder, run npm install, then rerun /create-mobile-app --working-dir <fresh-template-dir>.

Use these markers:

| State | Detection | Action | |---|---|---| | Fresh template | package.json, app.config.js, auth.config.json, tamagui.config.ts exist; node_modules/expo exists; memory-bank.md, native-app-plan.md, .datamodel-manifest.json, and generated Dataverse services are absent | Proceed. | | Template not installed | Fresh-template files exist but node_modules/expo is absent | STOP: ask user to run npm install in the template folder, then rerun. Do not provision ADO npm tokens here. | | Already-created app | memory-bank.md, native-app-plan.md, .datamodel-manifest.json, or src/generated/services/*.ts exists | STOP: this is not a fresh create target. Ask user to materialize a fresh template folder with degit. | | Not template | Required template files are missing | STOP: ask user to materialize microsoft/power-platform-skills/plugins/mobile-apps/template#main into the working directory with degit and run npm install. |

This gate is intentionally simple: /create-mobile-app creates a new app from a fresh template. It does not adopt, repair, resume, or overwrite an already-created app.

---

TypeScript Gate Policy — no quality compromise

tsc is a phase gate, not a reflex after every tiny edit. The app may not advance past a gate until TypeScript is clean.

Required gates:

• Scaffold gate: Step 6.6 after existing-template preparation, npx power-apps init, and dependency verification.
• Dataverse/generated-services gate: immediately after Step 8 returns and generated services/models are refreshed.
• Navigation/skeleton gate: after Step 10b layouts and Step 10.8 shared code/skeletons are written, before Step 11 builders launch.
• Screen-wave gate: after each Step 11 screen-builder wave returns, before launching the next wave.
• Final gate: before Step 12 starts the dev server.

When a gate fails:

1. Capture the full tsc --noEmit output once.
2. Classify errors by root cause (for example: generated model names, service option shapes, invalid UI props, typed percentage values, create/update payload typing, missing imports).
3. Repair in a batch.
4. Re-run the same gate once after the batch.
5. Continue only when the gate is clean, or stop/block according to the retry policy.

Do not run full-app tsc after every microscopic local edit inside the same repair pass. That is slower and encourages line-by-line patching. Batch root-cause fixes, then re-run the gate. This is a speed improvement only; it does not lower the quality bar.

Hard stops:

• Do not launch data-source work from a broken scaffold gate.
• Do not launch screen-builders from broken generated services, layouts, shared code, or skeletons.
• Do not launch wave N+1 until wave N passes its tsc gate.
• Do not start the dev server until the final gate is clean.
• Do not hide approved capability failures behind mocks or TODOs just to satisfy tsc.

---

Step 0 — Resume check + fresh-template gate

Telemetry checkpoint: validate_fresh_template

If $ARGUMENTS includes a --working-dir (or the user names an existing directory), check whether <working_dir>/memory-bank.md exists.

• Bank present → read it. Identify the highest-numbered completed step. Inform the user:

  "Found existing project '<name>' at <dir>. Steps 1–<N> already completed (last update <date>). Resume from Step <N+1>?" Wait for confirmation. If the user says yes, jump to that step. Skip the wizard (Step 2) and re-use the values stored in the bank.

• Bank absent → fresh project. Continue to Step 1.
• Bank present but corrupted (missing required headings) → surface the parse error, ask the user whether to overwrite (lose history) or fix manually before proceeding.

The bank is the only resume mechanism. Do not infer resume state from package.json or node_modules/ — those can lie.

After the resume check, run the fresh-template gate from the section above. This is a create-only command:

• If memory-bank.md exists and the user confirms resume, resume as documented above.
• If any already-created-app marker exists and there is no approved resume path, STOP and tell the user to materialize a fresh template into a new folder with degit.
• If required template files are missing, STOP and tell the user to materialize microsoft/power-platform-skills/plugins/mobile-apps/template#main into the working directory with degit and run npm install.
• If node_modules/expo is missing, STOP and tell the user to run npm install in that template folder before rerunning this skill.

Do not silently copy a bundled template over the user's folder. A fresh plugins/mobile-apps/template template may contain placeholder power.config.json with an empty environmentId; Step 5 removes that placeholder immediately before Step 6 runs npx power-apps init.

Step 1 — Prerequisites

Telemetry checkpoint: validate_development_toolchain

Run all checks first — no point gathering requirements if the toolchain isn't ready.

Important: npm auth and Power Platform app auth are separate. The account used for npm install can be different from the account used by npx power-apps:

| What | Uses | Typical account | |---|---|---| | npm install private feed access | npm/Azure Artifacts auth configured outside this skill | Account with feed Reader access | | npx power-apps init, Dataverse, deploy | npx power-apps browser auth + az login --tenant <env-tenant> for Dataverse helper scripts | Power Platform environment account, often a test-tenant/admin account |

Renewing npm feed auth does not sign the user into npx power-apps. If the Power Apps CLI prompts for browser auth later, that is expected and unrelated to the npm/ADO feed token.

Then run the checks:

node --version                                      # v22+
npm  --version                                      # v10+
az account show --query "user.name" -o tsv          # Azure CLI logged in (needed for Dataverse helper scripts)
git --version                                       # optional

Do NOT probe Xcode, Java, Android Studio, or CocoaPods here. This plugin's flow is plan → scaffold → code → local Expo dev server. Build + deploy (npm run build / npx power-apps push) is a separate user-driven step via the /deploy skill. Local native compile is the user's choice and lives outside this skill (run the platform-specific native command directly when needed). See shared/version-check.md — only the Always required tier matters here.

| Missing | Action | |---|---| | Node < 22 | STOP — instruct nvm install 22 && nvm use 22 | | az | STOP — instruct az login |

Template-only rule: this skill no longer provisions npm feed tokens, PAT fallbacks, vendor fallbacks, or registry rewrites. The user must run npm install in the fresh template folder before invoking /create-mobile-app.

Capture target Power Platform environment for the remaining flow.

Source of truth for env selection: the generated power.config.json first, explicit environment ID second. In the normal template-folder flow, npx power-apps init runs first and writes the selected environment ID into power.config.json; read that ID and pass it to scripts/resolve-environment.js to resolve the Dataverse URL and tenant. If power.config.json is missing or has an empty placeholder environmentId, ask for an environment ID. A Dataverse URL is useful as a resolver fallback for existing apps, but it is not enough for npx power-apps init because init needs --environment-id.

| Step | Source | When user is asked | |---|---|---| | 0. power.config.json has environmentId | scripts/resolve-environment.js <environment-id> | Never — automatic after npx power-apps init | | 1. User supplies env ID | scripts/resolve-environment.js <environment-id> | Ask only if power.config.json is missing/empty or user wants a different env | | 2. User wants a different account | Follow shared-instructions standalone CLI auth handling | Only if resolution/token acquisition fails or user asks | | 3. User wants different env | Ask for another env ID and re-run resolver | Only if user selects "use a different environment" at Step 2 | | 4. npx power-apps init -t MobileApp --display-name "$DISPLAY_NAME" --environment-id $ACTIVE_ENV_ID --non-interactive | Persists choice into power.config.json | Only when this skill owns the initial init path |

TARGET_ENV="<environment-id-or-empty>"
if [ -z "$TARGET_ENV" ] && [ -f power.config.json ]; then
  TARGET_ENV=$(node -e "try { const id=require('./power.config.json').environmentId || ''; console.log(id); } catch { console.log(''); }")
fi
test -n "$TARGET_ENV" || { echo "✗ Environment missing. Provide an environment ID."; exit 2; }
ENV_JSON=$(node "${PLUGIN_ROOT}/scripts/resolve-environment.js" "$TARGET_ENV")
printf '%s\n' "$ENV_JSON" > .resolved-environment.json
ACTIVE_ENV_ID=$(node -e "const j=JSON.parse(process.argv[1]); console.log(j.environmentId || '')" "$ENV_JSON")
ACTIVE_ENV_NAME=$(node -e "const j=JSON.parse(process.argv[1]); console.log(j.displayName || j.environmentUrl || '')" "$ENV_JSON")
ACTIVE_ENV_URL=$(node -e "const j=JSON.parse(process.argv[1]); console.log(j.environmentUrl || '')" "$ENV_JSON")
ACTIVE_TENANT_ID=$(node -e "const j=JSON.parse(process.argv[1]); console.log(j.tenantId || '')" "$ENV_JSON")
test -n "$ACTIVE_ENV_ID" || { echo "✗ Environment ID missing. Provide the environment ID directly."; exit 2; }
echo "✓ Target env: $ACTIVE_ENV_NAME ($ACTIVE_ENV_ID)"
echo "✓ Target env URL: $ACTIVE_ENV_URL"
echo "✓ Target tenant: ${ACTIVE_TENANT_ID:-unknown}"

**Orchestrator handling for `ex