/edit-app

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. Natural-language triggers include 'the app already exists', 'edit my app', 'change this screen', and 'add a feature to this app'."
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](../../shared/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.

Edit documentation protocol

Keep two HTML files current during every edit:

• `<edit-temp-dir>/edit-app-progress.html` shows the live operation checklist.
• `docs/create-app-plan.html` remains the living description of the app.

Both are best-effort documentation. A rendering failure does not authorize a mutation, cancel an approval gate, or turn a failed verification into success.

Progress page

As soon as Step 0 resolves `working_dir`, before inferred-plan sync or the first progress write, ask `app-docs.js` for a namespaced directory inside the user's OS temp directory:

node "${PLUGIN_ROOT}/scripts/app-docs.js" --working-dir '<working_dir>' temp

Use the returned `directory`, `progress`, `progressHtml`, and `sync` paths for the rest of the run. Do not create progress files inside the project. Create `<edit-temp-dir>/edit-app-progress.json` with one row per operation this edit will run. Use stable IDs such as `inspect`, `impact`, `plan`, `approve`, `save-plan`, `data`, `native`, `design`, `screens`, `verify`, `preview`, and `sync-plan`. Omit operations that do not apply. Each row has `id`, `label`, `status` (`pending`, `active`, `waiting`, `done`, `skipped`, or `failed`), and an optional `note`. Add a top-level `changes` array for the Changes tab. Keep it empty during initial inspection. After Step 2, every entry requires `kind`, `title`, `rationale`, and optional `detail`. Use `kind: general` for text-only changes. Use structured diagram data for data-model and screen changes:

{
  "changes": [
    {
      "kind": "data-model",
      "title": "Add inspection evidence",
      "detail": "Create a child table for photos and signatures.",
      "rationale": "One inspection can have several evidence records with independent metadata.",
      "dataModel": {
        "tables": [
          {
            "name": "Inspection",
            "columns": [{ "name": "inspectionid", "type": "guid", "primaryKey": true }]
          },
          {
            "name": "Evidence",
            "columns": [
              { "name": "evidenceid", "type": "guid", "primaryKey": true },
              { "name": "inspectionid", "type": "guid", "foreignKey": true }
            ]
          }
        ],
        "relationships": [
          {
            "from": "Inspection",
            "to": "Evidence",
            "cardinality": "one-to-many",
            "label": "contains"
          }
        ]
      }
    },
    {
      "kind": "screen",
      "title": "Add inspection detail",
      "detail": "Add a route that shows findings and evidence.",
      "rationale": "Inspectors need a focused review surface before updating a record.",
      "screenGraph": {
        "screens": [
          { "id": "list", "name": "Inspections", "route": "/inspections" },
          { "id": "detail", "name": "Inspection detail", "route": "/inspections/[id]" }
        ],
        "edges": [
          { "from": "list", "to": "detail", "label": "Select inspection" }
        ]
      }
    }
  ]
}

Derive data-model tables, columns, and relationships from the validated schema proposal. Derive screen nodes and edges from the updated Screen Map and Navigation Contracts. When multiple screens are shown, include every navigation edge needed to explain how the user moves between them. Do not hand-author Mermaid source in the payload. `app-docs.js` derives and renders the ER diagram or screen graph from the structured data. Retain the approved wording, rationale, and graph data through implementation and verification.

Rewrite that JSON at every numbered step boundary and run:

node "${PLUGIN_ROOT}/scripts/app-docs.js" --working-dir '<working_dir>' progress \
  --json-file '<edit-temp-dir>/edit-app-progress.json'

Every progress payload is a complete snapshot, not a patch. Carry every operation row forward and update all rows whose state changed before publishing. When the top-level phase advances, no row from an earlier phase may remain `active` or `waiting`. In particular, an approval wait must show inspection and planning as complete and the approval row as `waiting`.

The top-level object also carries `phase`, `status`, `note`, `waiting`, and `devicePreviewReady`. Set the current row to `waiting` and `waiting: true` before every user question. Set completed rows to `done`; do not leave the first row active for the whole run. On failure, mark the failed row and top-level status `failed`. The page keeps a phone preview on the right while work is active. Keep `devicePreviewReady: false` until this edit's Step 8 phone command succeeds. The