$npx -y skills add microsoft/power-platform-skills --skill add-sample-dataUse when the user wants to seed Dataverse tables with realistic sample records so a freshly-scaffolded code app shows real-looking data on first launch. Generates contextually appropriate rows from each table's schema and inserts them in dependency order. Mirrors microsoft/power-
| 1 | **📋 Shared instructions: [shared-instructions.md](${CLAUDE_SKILL_DIR}/../../shared/shared-instructions.md)** — read first. |
| 2 | |
| 3 | # Add Sample Data |
| 4 | |
| 5 | Populate Dataverse tables with realistic sample records so a freshly-scaffolded code app shows real-looking data on first launch. Generates rows from each table's schema and inserts them in dependency order. Use after `/add-dataverse` (or `/setup-datamodel`) has created the tables. |
| 6 | |
| 7 | ## Core principles |
| 8 | |
| 9 | - **Coverage over volume — every table in the manifest gets seeded.** The #1 failure mode of a freshly-scaffolded code app is a home / dashboard / list screen that renders an empty state on first launch because its source table has zero rows. An empty downstream table is **worse than a 3-row table.** Default to minimal-but-complete: small counts everywhere, no table left empty. Volume is a secondary knob — coverage is the contract. |
| 10 | - **Insertion order matters.** Parent / referenced tables must be inserted before child / referencing tables so lookup IDs are available. |
| 11 | - **Contextual data, not Lorem Ipsum.** Generate values that match column names + types. A `cr3e9_sitename` column in an inspection app gets "Westside Construction Site", not "Sample Name 1". |
| 12 | - **Scenario-aware rows.** Read `native-app-plan.md` and, when present, `### Shared Conventions` / `Scenario archetype` from [power-apps-scenario-archetypes.md](${CLAUDE_SKILL_DIR}/../../shared/references/power-apps-scenario-archetypes.md). Seed rows should exercise the app's actual workflow: statuses, dates, relationships, priority/severity, media metadata, and edge cases that make the planned first viewport light up. |
| 13 | - **Fail gracefully.** On insertion failure, log the error and continue with remaining records — never auto-rollback. The user can re-run after fixing the issue. |
| 14 | - **Idempotent re-runs.** If a previous run partially completed, the second run reads `memory-bank.md`'s seeded-data table and skips records already inserted. |
| 15 | - **Solution-scoped inserts.** Always pass `--solution <uniqueName>` so records land in our solution, not the default. |
| 16 | |
| 17 | ## Workflow |
| 18 | |
| 19 | 1. Verify project + auth → 2. Discover tables → 3. Select tables + count → 4. Generate + preview → 5. Insert → 6. Summary |
| 20 | |
| 21 | ## Prototype Seed Reuse |
| 22 | |
| 23 | `--from-seed` is used by `/prototype-to-real-app` after a mock prototype is converted to Dataverse. In this mode, prefer existing prototype seed files before generating new rows: |
| 24 | |
| 25 | ```text |
| 26 | src/generated/services/*/*.seed.json |
| 27 | src/generated/services/*.seed.json |
| 28 | ``` |
| 29 | |
| 30 | Map seed objects to Dataverse payloads using `.datamodel-manifest.json`: |
| 31 | |
| 32 | - Keep values only for real manifest columns. |
| 33 | - Translate lookup references into exact `<schemaName>@odata.bind` keys from the manifest. |
| 34 | - Keep picklist integers from the manifest; do not invent values from labels. |
| 35 | - Skip local-only prototype fields that have no Dataverse column. |
| 36 | - Preserve dependency-tier insertion order. |
| 37 | |
| 38 | If a seed file cannot be mapped safely, fall back to generated contextual sample rows for that table and record `DONE_WITH_CONCERNS` in the summary. `--from-seed` is a preference, not permission to insert malformed data. |
| 39 | |
| 40 | --- |
| 41 | |
| 42 | ### Step 1 — Verify project & auth |
| 43 | |
| 44 | ```bash |
| 45 | test -f power.config.json && test -f app.config.js |
| 46 | node "${CLAUDE_SKILL_DIR}/../../scripts/resolve-environment.js" "$(node -e \"console.log(require('./power.config.json').environmentId)\")" |
| 47 | ``` |
| 48 | |
| 49 | Capture the **environment URL** for subsequent script calls. If resolution fails, instruct `az login --tenant <env-tenant>` or ask for the environment URL directly, then stop. |
| 50 | |
| 51 | Verify Azure CLI auth (the script needs an Azure CLI token): |
| 52 | |
| 53 | ```bash |
| 54 | az account show --query "user.name" -o tsv |
| 55 | ``` |
| 56 | |
| 57 | If empty, instruct `az login` and stop. |
| 58 | |
| 59 | ### Step 2 — Discover tables |
| 60 | |
| 61 | #### Step 2a — Path A: read `.datamodel-manifest.json` (preferred) |
| 62 | |
| 63 | ```bash |
| 64 | test -f .datamodel-manifest.json |
| 65 | ``` |
| 66 | |
| 67 | If present, parse the JSON. It already contains `logicalName`, `displayName`, `status` (`new` / `extended` / `reused`), and `columns` for every table the project uses. **This is the preferred path** — fast, no API calls. |
| 68 | |
| 69 | ```bash |
| 70 | cat .datamodel-manifest.json | jq '.tables[] | { logicalName, displayName, columnCount: (.columns | length) }' |
| 71 | ``` |
| 72 | |
| 73 | Skip Step 2b. |
| 74 | |
| 75 | #### Step 2b — Path B: query OData (fallback) |
| 76 | |
| 77 | If `.datamodel-manifest.json` is missing, discover custom tables via the script: |
| 78 | |
| 79 | ```bash |
| 80 | node "${CLAUDE_SKILL_DIR}/../../scripts/dataverse-request.js" <envUrl> GET \ |
| 81 | "EntityDefinitions?\$select=LogicalName,DisplayName,EntitySetName&\$fil |