/setup-app-insights

name: setup-app-insights
description: Configure optional customer-owned Application Insights telemetry for a Power Apps mobile app — enable it against an existing Azure resource, change the resource, or disable it. Standalone, and invoked by /edit-app.
user-invocable: true
allowed-tools: Read, Write, Edit, Glob, Grep, Bash, AskUserQuestion, Skill
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](../../shared/shared-instructions.md)** — read first.

Set up Application Insights

Configures the generated app's optional, customer-owned Application Insights telemetry through `app.json` → `expo.extra.appInsightsConfig`. This is host/runtime configuration, not a connector or plan section — it never touches the data model, native-capability matrix, connector list, or screens.

Application Insights is **off by default**. Invoking this skill (or approving its mutation) is the explicit opt-in; consent is never inferred from an app description.

When to use

• `/setup-app-insights` — enable, change, or disable Application Insights on an existing app.
• Invoked by `/edit-app` when the request is only an Application Insights change (its Step 0.5 fast path delegates here).
• Examples: "Enable Application Insights for this app", "Change the Application Insights resource this app uses", "Disable Application Insights for this app".

When NOT to use

• Adding or changing custom events in app screens → configure Application Insights here first, then continue through `/edit-app` for those source changes.
• Data model / connector / native / design / screen changes → the respective `/add-*`, `/setup-*`, `/edit-app`, or `/design-system` skills.
• Provisioning a new Azure Application Insights resource → out of scope; this skill discovers or accepts an **existing** resource.

Inputs

• `working_dir` — absolute path to the project root (auto-detected from cwd, or passed by an orchestrator).
• `--action <enable|change-resource|disable>` — optional; when omitted, inferred from current state and one question.

Step 1 — Detect invocation mode

**Telemetry checkpoint: `resolve_app_insights_mode`**

1. Check MOBILE_APP_ORCHESTRATING=1 AND explicit edit-app caller context
   → Mode A (invoked by /edit-app). Use the passed --working-dir. Return a status block.

2. Else resolve working_dir from cwd (must contain app.json with an expo object)
   → Mode B (standalone). Return a human summary.

Use the invocation-scoped context from [app-edit-routing.md](../../shared/references/app-edit-routing.md), not a stale shell value. Configuration approval remains owned by Step 3 in either mode.

Step 2 — Inspect and determine the action

**Telemetry checkpoint: `determine_app_insights_action`**

Read, when present:

• `<working_dir>/app.json`
• `<working_dir>/app/_layout.tsx`
• `<working_dir>/package.json`
• `<working_dir>/memory-bank.md`

If `app.json` is missing, malformed, or has no `expo` object, STOP without mutation (`BLOCKED` in Mode A). If uncommitted work overlaps `app.json` or `app/_layout.tsx`, follow the changed-file overlap approval rule in `shared-instructions.md`.

Determine the action:

• `enable` — `appInsightsConfig.enabled` is absent or `false` and the user wants it on.
• `change-resource` — already `enabled: true` and the user wants a different destination.
• `disable` — the user wants Application Insights turned off.
• If intent is ambiguous, ask one `AskUserQuestion` with those three choices, seeded by the current `enabled` state.

Step 3 — Mutation preview + approval

**Telemetry checkpoint: `review_app_insights_change`**

Show one focused preview and continue only after approval:

─── Application Insights ────────────────────────────
Action        <enable | change resource | disable>
Current       enabled: <true|false>
Configuration app.json → expo.extra.appInsightsConfig
Provider      app/_layout.tsx → PowerAppsProvider appConfig
Sensitive     connection string is never printed or stored in memory-bank.md

Ask: `Apply this Application Insights change?`

Step 4 — Emit the selection telemetry

After the action is confirmed, record the choice through Mobile Apps usage telemetry (`enabled` for enable/change-resource, `disabled` for disable):

node "${PLUGIN_ROOT}/hooks/run-telemetry.js" \
  app-insights-selection \
  "<enabled-or-disabled>" \
  "<prompt-or-pretool>" \
  '<working_dir>'

Pass the invocation source so the event's `invocationSource` matches how the skill was reached: `pretool` in Mode A (delegated from another skill such as `/edit-app` via the Skill tool) and `prompt` in Mode B (the user ran `/setup-app-insights` directly).

This event follows the existing Mobile Apps telemetry controls and contains no Application Insights resource details or connection string. It fails open and never blocks the skill.

Step 5a — enable / change-resource

**Telemetry checkpoint: `configure_app_insights_resource`**

Discover Application Insights resources visible to the current Azure CLI identity:

az resource list \
  --resource-type Microsoft.Insights/components \
  --query "[].{name:name,id:id,resourceGroup:resourceGroup,location:location}" \
  -o json

Branch on the result:

• **One or more resources returned:** use `AskUserQuestion` to let the user select one. Before configuring it, confirm the selected component is **workspace-based** — `az resource list` returns every `Microsoft.Insights/components`, including classic components, which are not compliant with this skill's contract. Read `properties.WorkspaceResourceId` from the selected resource:

  WORKSPACE_RESOURCE_ID=$(
    az resource show \
      --ids "<selected-resource-id>" \
      --api-version 2020-02-02 \
      --query properties.WorkspaceResourceId \
      -o tsv
  )

If `WORKSPACE_RESOURCE_ID` is empty, th