/integrate-webapi

name: integrate-webapi
description: >-
  Integrates Power Pages Web API into a site's frontend code with proper permissions and
  deployment. Orchestrates the full integration lifecycle: code integration, table permissions
  setup, and deployment for Dataverse CRUD operations. Also supports PAC-downloaded non-SPA
  sites by preferring native Forms, Lists, and Liquid before custom Web API JavaScript. Use when
  the user wants to add Web API calls, connect to Dataverse, add data fetching to their frontend,
  or integrate a non-SPA page with Dataverse.
user-invocable: true
allowed-tools: Read, Write, Edit, Bash, Grep, Glob, AskUserQuestion, Skill, Task, TaskCreate, TaskUpdate, TaskList
model: opus

> **Plugin check**: Run `node "${PLUGIN_ROOT}/scripts/check-version.js"` — if it outputs a message, show it to the user before proceeding.

Integrate Web API

Integrate a Power Pages site with Dataverse. SPA sites retain the framework-specific client, service, and hook workflow. Non-SPA sites use native Forms, Lists, and Liquid first, adding Web API JavaScript only when the requested client interaction requires it.

Site Type Routing

Before reading or executing the workflow below, perform the existing SPA project lookup first:

• Look for `powerpages.config.json` in the current directory or immediate subdirectories using the

existing file-search patterns.

• If found, continue with the existing SPA workflow below. Do not run any non-SPA site

detection or change the SPA phases, prompts, gates, generated files, or deployment behavior.

• Only when that existing SPA lookup finds no `powerpages.config.json`, run:

  node "${PLUGIN_ROOT}/scripts/lib/detect-project-context.js"

• If it returns `siteType: "non-spa"`, read and follow the complete seven-phase workflow in

`${PLUGIN_ROOT}/skills/integrate-webapi/references/non-spa-site-workflow.md`. Do not execute any of the SPA workflow below.

• Otherwise, continue to Phase 1 and preserve its existing not-found handling.

The non-SPA route supports request-focused and discovery invocation as defined in its workflow reference. SPA invocation semantics remain those defined by the existing workflow below. When `$ARGUMENTS` contains `[CALLED-BY-PARENT-SKILL]`, pass that sentinel and its optional `caller=<skill-name>` token into the non-SPA workflow. It suppresses commits and deployment handoffs only; it does not bypass the non-SPA scope approval or security planning.

---

Core Principles

• **First table sequential, then parallel**: The first table must be processed alone because it creates the shared `powerPagesApi.ts` client. Once that exists, remaining tables can be processed in parallel since each creates independent files (types, service, hooks).
• **Parallelize independent agents**: The `table-permissions-architect` and `webapi-settings-architect` agents are independent — invoke them in parallel rather than sequentially.
• **Permissions require deployment**: The `.powerpages-site` folder must exist before table permissions and site settings can be configured. Integration code can be written without it, but permissions cannot.
• **AI-only read mode is opt-in**: When invoked by another skill (e.g. `/add-ai-webapi`) with the `[AI-READ-ONLY]` sentinel in `$ARGUMENTS`, the flow produces read-only code and hardens the settings/permissions for AI summarization reads. See Phase 1.6 for the contract. Human invocations never trigger this mode.
• **Use TaskCreate/TaskUpdate**: Track all progress throughout all phases — create the todo list upfront with all phases before starting any work.
• **Preserve site integrity**: Before an agent changes mock-backed or data-driven UI, read `${PLUGIN_ROOT}/references/site-modification-integrity.md`; localize every new visible state when a manifest exists and keep the component bidirectional and expansion-safe.

> **Prerequisites:** > > - An existing Power Pages SPA site created via `/create-site` > - A Dataverse data model (tables/columns) already set up via `/setup-datamodel` or created manually > - The site must be deployed at least once (`.powerpages-site` folder must exist) for permissions setup

**Initial request:** $ARGUMENTS

---

Workflow

1. **Verify Site Exists** — Locate the Power Pages project and verify prerequisites 2. **Explore Integration Points** — Analyze site code and data model to identify tables needing Web API integration 3. **Review Integration Plan** — Present findings to the user and confirm which tables to integrate 4. **Implement Integrations** — Use the `webapi-integration` agent for each table 5. **Verify Integrations** — Validate all expected files exist and the project builds successfully 6. **Setup Permissions & Settings** — Choose permissions source (upload diagram or let the architects analyze), then configure table permissions and Web API site settings with case-sensitive validated column names 7. **Review & Deploy** — Ask the user to deploy the site and invoke `/deploy-site` if confirmed

---

Phase 1: Verify Site Exists

**Goal**: Locate the Power Pages project root and confirm that prerequisites are met

**Actions**:

1.1 Locate Project

Look for `powerpages.config.json` in the current directory or immediate subdirectories to find the project root. Use your file-search tool (e.g., `Glob` with patterns `powerpages.config.json` and `*/powerpages.config.json`) rather than a shell-specific command.

**If not found**: Tell the user to create a site first with `/create-site`.

1.2 Read Existing Config

Read `powerpages.config.json` to get the site name.

1.3 Detect Framework

Read `package.json` to determine the framework (React, Vue, Angular, or Astro). See `${PLUGIN_ROOT}/references/framework-conventions.md` for the full framework detection mapping.

1.4 Check for Data Model

Look for `.datamodel-manifest.json` to discover available tables:

**/.datamodel-manifest.json

If found, read it — this is the primary source for t