/setup-datamodel

name: setup-datamodel
description: Use when the user wants to design or redesign the Dataverse schema and connector plan for an existing mobile app, or has an ER diagram (image, Mermaid, or text) to apply. Skip when the user is creating a brand-new app — /create-mobile-app handles the data model inline.
user-invocable: true
allowed-tools: Read, Edit, Write, Grep, Glob, Bash, AskUserQuestion, EnterPlanMode, ExitPlanMode, 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](${PLUGIN_ROOT}/shared/shared-instructions.md)** — read first.

Set Up Data Model + Connectors

**Entry routing:** use the shared [App feature entry points](../../shared/shared-instructions.md#app-feature-entry-points) preflight before the workflow below.

**Invocation scope:** follow [Data-source invocation scope](../../shared/shared-instructions.md#data-source-invocation-scope) before any project read or the workflow below.

This standalone data-only workflow does not require a complete app plan. It proposes and approves only the current schema/connector delta; preserve existing app sections without invoking full-app planning or screen generation. When called by an owner, retain its explicit current request, absolute root, phase, and scope, and return proposals or verified results to that owner.

Combined orchestrator for standalone data source planning. Designs the Dataverse schema, plans connectors, gets approval on both, then delegates execution to `/add-dataverse` and `/add-connector`.

| Use this skill when | Use `/add-dataverse` directly when | |---|---| | Standalone schema + connector design (initialized app; data plan optional) | The plan already exists and you just need to apply tables + generate services | | You have an existing ER diagram (image / Mermaid / text) to import | `/create-mobile-app` is invoking this as a sub-step with approved scoped context | | Re-planning the schema or connectors mid-project | You only need to add a single table or a single connector |

Workflow

1. Resolve project root & verify auth → 2. Design data model → 3. Plan connectors → 4. Combined approval → 5. Execute additions/refreshes → 6. Execute connectors → 6.25 Retire approved bindings → 6.5 Reconcile offline profile → 7. Reconcile inventory & summarize

---

Phase 1 — Verify Project & Auth

Resolve one absolute `working_dir` before reading project files or discovering the environment:

• For a nested call, inherit the owner's absolute `working_dir`. If

`--working-dir` is also supplied, both must resolve to the same directory; a mismatch returns `NEEDS_CONTEXT` before any project or cloud work.

• For a direct call, resolve an explicit `--working-dir` against the invocation

directory. Only a direct call without an override may use that invocation directory as its project root.

• Require the selected directory to exist, normalize it to one absolute path,

and retain it for this invocation. A missing nested owner path is an error: never fall back to the shell's current directory or search neighboring apps.

All relative app paths below, including diagram inputs, `native-app-plan.md`, `_dm_section.md`, `.datamodel-manifest.json`, `offline-profile.json`, and `memory-bank.md`, are relative to this resolved root, not a later tool's cwd. Use absolute paths with file tools. Begin every shell invocation that reads or writes app-local files with the single-quoted fail-closed app-root guard; shell state does not carry across tool calls.

Confirm the selected root is a Power Apps mobile app:

For `--plan-only` or a planning-phase handoff, perform the file/environment checks read-only and use the shared proposal-only environment-context rule. The same non-persisting lookup is used before approval in a normal invocation. Incomplete or conflicting context returns `NEEDS_CONTEXT` after read-only recovery; never retry without the safety flags or redirect into app configuration.

cd -- '<working_dir>' || { echo "BLOCKED: cannot enter working_dir" >&2; exit 1; }
if [ ! -f power.config.json ] || [ ! -f app.config.js ]; then
  printf '%s\n' 'ERROR: selected working directory is not an initialized mobile app' >&2
  exit 1
fi
environment_id="$(node -p "require('./power.config.json').environmentId || ''")" || exit 1
if [ -z "$environment_id" ]; then
  printf '%s\n' 'ERROR: selected app has no environmentId' >&2
  exit 1
fi
node "${PLUGIN_ROOT}/scripts/resolve-environment.js" "$environment_id" --no-cache --require-tenant

Stop on failure; do not switch directories or re-scaffold. Capture the **environment URL**, **environment ID**, and **tenant ID** for this root for Phase 5. Pass this same absolute root in every planner/skill handoff and on retries.

Phase 2 — Design Data Model

**Telemetry checkpoint: `design_dataverse_schema`**

Check whether the request needs Dataverse schema first; connector-only requests take Path C. Otherwise check `$ARGUMENTS` for diagram hints (`*.png`, `*.jpg`, `erDiagram`, `||--o{`). If present, take Path A. If a Dataverse requirement is already supplied, take Path B for a read-only proposal. If the choice is still unknown, ask:

> "How would you like to define the data model?"

| Option | What happens | |---|---| | Upload an existing ER diagram | Provide a PNG/JPG path, Mermaid block, or text description | | Let the Data Model Architect propose one (default) | Spawns `data-model-architect` agent to infer from requirements | | Skip — no Dataverse tables needed | Jump to Phase 3 |

Recommend "architect propose" only when Dataverse schema is needed. Connector-only requirements take Path C without inventing Dataverse tables. Empty/cancel input does not approve a choice; wait for an answer or stop.

For Paths A and B, read and execute [dataverse-change-planning.md](../../shared/references/dataverse-change-planning.md). The f