---

name: edit-app description: "Use when the user wants to iterate on an existing generated Power Apps mobile app after /create-mobile-app: update Application Insights configuration, the plan, data model, native capabilities, design, screens, generated app code, and preview without restarting the full project flow." user-invocable: true allowed-tools: Read, Write, Edit, Glob, Grep, Bash, AskUserQuestion, Task, 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 — read first.

Edit App (/edit-app)

Post-generation editor for an existing mobile app. native-app-plan.md remains the source of truth, but the default outcome is a fixed generated app, not a plan-only diff. After the user approves the plan delta, continue into Dataverse/native/design/screen mutations, run verification, update memory-bank.md, and regenerate the static preview when UI changed.

Use --plan-only only when the user explicitly asks to update planning docs without changing app code. Normal follow-up prompts in Copilot Chat Agent mode should apply the app change end to end.

When to use

• "Improve the search screen to make it easier to use on mobile"
• "Add loading, empty, and error states to the list screen"
• "Add a detail screen for the selected record"
• "Update the design to better match the company branding"
• "Add a form to create a new record in Dataverse"
• "Add barcode scanning and use the scanned value to search records"
• "Generate a new static preview of the updated app"
• "Add a case table to the data model"
• "Replace the Drawer navigation with Tabs"
• "Add expo-camera to the native capabilities"
• "Add signature capture to approvals and store it in Dataverse"
• "Generate an evidence PDF and retain it on the inspection record"
• "Add a View PDF action for an HTTPS report URL"
• "Reorder screens — move profile out of tabs, into a modal from the home header"
• "Enable Application Insights for this app"
• "Change the Application Insights resource used by this app"
• "Disable Application Insights for this app"

When NOT to use

• Brand-new project → /create-mobile-app
• Just adding one connector with no screen changes → /add-connector directly
• Just adding a single native wrapper with no screen changes → /add-native directly
• The plan file is missing → re-run /create-mobile-app (don't try to reconstruct)

Workflow

0. Locate app + health/drift probe → 0.5 Application Insights fast path when applicable → 1. Discover intent + inspect existing app → 1.5 Impact preview → 2. Re-plan affected sections → 3. Gate intent, plan + mutation preview → 4. Write plan diff → 5. Apply app mutations → 6. Rebuild affected screens → 7. Verify + quality sweep → 8. Preview + memory-bank update + optional debug handoff

---

Edit Quality Gate Policy — no quality compromise

This is a focused edit workflow, not a lighter quality bar. Reuse /create-mobile-app gates at edit scale.

Required gates by edit type:

| Edit touches | Required gates | |---|---| | Any source file | Existing-app health gate, final npx tsc --noEmit | | Dataverse/schema/connector | Environment drift gate, data-source/schema gate, Generated Services snapshot refresh, final tsc | | Navigation/routes | Navigation/layout gate, route contract check, final tsc | | New screen | Shared scaffold gate, skeleton gate, screen-builder wave gate, style-quality sweep, route check, final tsc | | Existing screen TSX | Screen edit gate, style-quality sweep, route check when navigation changed, final tsc | | Native capability | Native allowlist gate, wrapper existence gate, final tsc | | Pure-JavaScript dependency | Approved exact-version dependency table, package-content gate, package validation, final tsc | | Design/component/density | Design-system gate, affected-screen style sweep, final tsc, preview | | Application Insights configuration only | Valid app.json, provider appConfig wiring, final tsc only if app/_layout.tsx changed |

When a gate fails: capture full output once, classify by root cause, repair in a batch, rerun the same gate once. Do not make line-by-line fixes with tsc after every tiny edit. Continue only when the gate is clean or record a BLOCKED: / DONE_WITH_CONCERNS: entry in memory-bank.md.

Hard stops:

• Do not run data-source mutations if the app root/environment cannot be identified.
• Do not launch screen-builders from broken generated services, route layouts, shared code, or skeletons.
• Do not import native wrappers in screens before /add-native has generated them.
• Do not hide unsupported native capabilities behind mocks or TODOs just to satisfy TypeScript.
• Do not mark an edit successful if changed screens fail TypeScript, route contracts, or required validators.

Step 0 — Locate app + health/drift probe

Telemetry checkpoint: assess_app_health_and_drift

test -f native-app-plan.md && echo "OK: plan found" || echo "ERROR: no plan"
test -f package.json && echo "OK: package found" || echo "ERROR: no package"
test -d app && echo "OK: app routes found" || echo "ERROR: no app routes"
test -f memory-bank.md && echo "OK: memory bank found" || echo "WARN: no memory bank"
git status --short

If native-app-plan.md is missing → STOP. Tell the user this skill edits an existing generated app; they should re-run /create-mobile-app on a fresh template or manually recreate the plan before using this editor.

Read if present:

• memory-bank.md — project facts, target environment, visual companion flag, prior blocks
• .datamodel-manifest.json — existing Dataverse tables/columns
• brand/design-system.md and brand/tokens.ts — design constraints and token availability
• src/generated/services/*.ts and src/generated/models/*.ts — generated data surface

Run these existing-app health checks before any mutation:

| Check | Action if unhealthy | |---|---| | memory-bank.md exists and has expected headings | If missing/corrupt, ask whether to proceed with reduced resume safety; create/update only after approval | | power.config.json, .resolved-environment.json, and memory bank env agree | For data-source/schema edits, STOP until the user confirms the intended environment | | src/components/index.tsx, src/hooks/index.ts, src/utils/index.ts, src/tokens/index.ts exist | Restore missing shared scaffold from shared/samples/src/ before screen-builder work; do not overwrite existing files | | app/_layout.tsx still wraps providers and SafeAreaProvider correctly | Patch conservatively before screen work; route/safe-area validators depend on this | | src/generated/ compiles when the edit depends on generated services | Regenerate schemas/services first, or block before screen work | | node_modules and package scripts needed for verification exist | If missing, ask user to run install; do not pretend verification passed |

If the worktree has uncommitted changes that overlap likely edit targets, show the affected files and ask before continuing. Do not revert or stash automatically.

If the app already fails npx tsc --noEmit, capture the errors once. Continue only when the failures are in files this edit will touch or are generated-service drift this edit can repair; otherwise surface the pre-existing failure and ask whether to proceed. If the edit would add screens or generated services, clean the prerequisite gate before continuing.

Step 0.5 — Application Insights configuration fast path

Use this fast path when the request is only to enable Application Insights, change its resource, or disable it. Application Insights is host/runtime configuration, not a connector or plan section, so do not run the planner, data-model, native, design, screen, or preview flows.

If the request also adds or changes custom events in app screens, configure Application Insights here first, then continue through the normal edit workflow for those source changes.

All Application Insights logic lives in the dedicated /setup-app-insights skill. Delegate to it rather than duplicating Azure discovery, connection-string handling, provider wiring, or privacy rules here:

Invoke skill: /setup-app-insights

Environment:
  CODE_APPS_NATIVE_ORCHESTRATING=1

Arguments:
  --working-dir <working_dir>
  --action <enable|change-resource|disable>   # omit to let the skill infer + ask

Determine --action from the request (enable / change-resource / disable); omit it if the request only says "update Application Insights" and let the skill ask. The skill owns the mutation preview, approval, app.json + PowerAppsProvider appConfig wiring, memory-bank.md updates, and the selection telemetry emit.

Handle the return per the status protocol (AGENTS.md rule #12):

• DONE → print the action completed. Then, if the return includes instrumentation_offer: available (a successful enable/change-resource), ask the user one question, defaulting to No: "Application Insights is on. Want me to add custom telemetry to your app's major operations (create / update / delete)?"
  • Yes → continue into the normal edit workflow (Step 1 onward) with this brief: "Add custom events at each successful create, update, and delete boundary for the app's main entities; emit named events through getCustomEventsLogger with approved scalar properties only (no operation results, payloads, form values, free text, record titles, personal identifiers, tokens, precise coordinates, nested objects, or complete URLs); use trackScenario() for any duration." Screen-planner and screen-builder own the source edits under their existing privacy allowlist.
  • No (or instrumentation_offer: none) → stop; do not continue to Step 1.
• DONE_WITH_CONCERNS → surface concerns, then stop.
• NEEDS_CONTEXT → surface the question, re-invoke with the answer.
• BLOCKED → surface the error (usually app.json unusable) and stop.

Step 1 — Discover intent + inspect existing app

Infer from $ARGUMENTS when possible, but do not mutate files until you have a concrete edit brief. This is the mini /create-mobile-app requirements phase for one existing-app change.

First inspect the app so questions can use real options instead of abstractions:

find app -name '*.tsx' -not -name '_layout.tsx' -not -name '+not-found.tsx' | sort
ls -1 src/generated/services/*.ts 2>/dev/null | sed 's|src/generated/services/||;s|\.ts$||'
ls -1 src/generated/models/*.ts 2>/dev/null | sed 's|src/generated/models/||;s|\.ts$||'
find src/native -maxdepth 1 -type f -name '*.ts*' 2>/dev/null | sort

Also read the relevant native-app-plan.md sections (## Data Model, ## Native Capabilities, ## Design, ## Screens, and ## Generated Services if present) plus the existing TSX for any candidate screen. If brand/design-system.md exists, read it before asking design/screen questions so the edit preserves product grammar, density, component rules, and negatives.

Ask only for information that cannot be inferred from the app. If there is exactly one plausible screen/table/service, state the inferred choice in the mutation preview instead of asking. If there are multiple plausible choices, ask a small multiple-choice question with those real names.

Build an edit brief before Step 2:

## Edit Brief
- Intent: <what user wants to accomplish>
- Target screens/routes: <existing or new>
- Data surface: <generated service/table/connector, or none>
- Native capability: <wrapper/control needed, or none>
- Design scope: <tokens/component grammar/screen-specific, or none>
- Plan sections to update: <Data Model / Native Capabilities / Screens / Design / Connectors>
- App files likely touched: <routes/layouts/src/native/src/generated/brand/etc.>
- Verification gates: <schema, tsc, ro