• 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.
• Use TaskCreate/TaskUpdate: Track all progress throughout all phases — create the todo list upfront with all phases before starting any work.

Prerequisites:

• An existing Power Pages code 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

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

• .datamodel-manifest.json

  — List of tables and their columns

• src/**/*.{ts,tsx,js,jsx,vue,astro}

  — Source code files that reference table data, mock data, or placeholder API calls
• Existing

  /_api/

  fetch patterns in the code
• TypeScript interfaces or types that map to Dataverse table schemas
• Component files that display or manipulate data from Dataverse tables
• Mock data files or hardcoded arrays that should be replaced with API calls

• TODO

  or

  FIXME

  comments mentioning API integration

"Analyze this Power Pages code site and identify all Dataverse tables that need Web API integration. Check

.datamodel-manifest.json

for the data model, then search the source code for: mock data arrays, hardcoded data, placeholder fetch calls to

/_api/

, TypeScript interfaces matching Dataverse column patterns (publisher prefix like

cr*_

), TODO/FIXME comments about API integration, and components that display table data. For each table found, report: the table logical name, the entity set name (plural), which source files reference it, what operations are needed (read/create/update/delete), and whether an existing API client or service already exists in

src/shared/

or

src/services/

. Also check if

src/shared/powerPagesApi.ts

already exists."

• Whether

  src/shared/powerPagesApi.ts

  (or equivalent API client) already exists
• Which tables already have service files in

  src/shared/services/

  or

  src/services/

• Which tables already have type definitions in

  src/types/

• Any framework-specific hooks/composables already created

1. The tables that were identified for Web API integration
2. For each table: which files reference it, what operations are needed
3. Whether a shared API client already exists or needs to be created
4. Any tables that were skipped (already have services)

Task

webapi-integration

${CLAUDE_PLUGIN_ROOT}/agents/webapi-integration.md

"Integrate Power Pages Web API for the [Table Display Name] table.

• Table logical name:

  [logical_name]

• Entity set name:

  [entity_set_name]

• Operations needed: [read/create/update/delete]
• Framework: [React/Vue/Angular/Astro]
• Project root: [path]
• Source files referencing this table: [list of files]
• Data model manifest path: [path to .datamodel-manifest.json if available]

Create the TypeScript types, CRUD service layer, and framework-specific hooks/composables. Replace any mock data or placeholder API calls in the referencing source files with the new service."

powerPagesApi.ts

• Verify the shared API client was created at

  src/shared/powerPagesApi.ts

• Then invoke all remaining tables in parallel using multiple

  Task

  calls — each table creates independent files (its own types in

  src/types/

  , service in

  src/shared/services/

  , and hook/composable), so there are no conflicts

• Check that the expected files were created (types, service, hook/composable)
• Confirm the shared API client exists after the first table is processed
• Note any issues reported by the agent

• Type definition in

  src/types/

  (e.g.,

  src/types/product.ts

  )
• Service file in

  src/shared/services/

  or

  src/services/

  (e.g.,

  productService.ts

  )
• Framework-specific hook/composable (e.g.,

  src/shared/hooks/useProducts.ts

  for React,

  src/composables/useProducts.ts

  for Vue)

• Shared API client at

  src/shared/powerPagesApi.ts

  exists
• Each service file references

  /_api/

  endpoints
• Each service file imports from the shared API client

npm run build

• Missing imports between generated files
• Type mismatches between service and type definitions
• Framework-specific compilation errors

1. Ask the user to provide their permissions diagram. Supported formats:
   • Image file (PNG, JPG) — Use the

     Read

     tool to view the image and extract web roles, table permissions, CRUD flags, scopes, and site settings from it
   • Mermaid syntax — The user can paste a Mermaid flowchart diagram text directly in chat
   • Text description — A structured list of web roles, table permissions, scopes, and site settings
2. Parse the diagram into structured format:
   • Web roles: Match with existing roles from

     .powerpages-site/web-roles/

     by name to get their UUIDs
   • Table permissions: Permission name, table logical name, web role UUID(s), scope, CRUD flags (read/create/write/delete/append/appendto), parent permission and relationship name (if Parent scope)
   • Site settings:

     Webapi/<table>/enabled

     and

     Webapi/<table>/fields

     — CRITICAL: fields normally list specific column logical names; only use

     *

     when the site relies on aggregate OData queries (

     $apply

     /aggregate) that otherwise fail with 403
3. Validate column names against Dataverse — Even when using a user-provided diagram, query Dataverse for each table's column LogicalNames and verify that every column in the

   Webapi/<table>/fields

   values uses the exact Dataverse LogicalName (case-sensitive). Correct any mismatches before creating files.
4. Cross-check with existing configuration in

   .powerpages-site/

   to identify which permissions and site settings are new vs. already exist.
5. Generate a Mermaid flowchart from the parsed data (if the user provided an image or text) for visual confirmation.
6. Present the parsed permissions plan to the user for approval using

   AskUserQuestion

   :

   Question	Options
   Does this permissions plan look correct?	Approve and create files (Recommended), Request changes, Cancel

7. Proceed directly to section 6.4: Create Permission & Settings Files with the parsed data.

Task

table-permissions-architect

${CLAUDE_PLUGIN_ROOT}/agents/table-permissions-architect.md

"Analyze this Power Pages code site and propose table permissions. The following tables have been integrated with Web API: [list of tables integrated in Phase 4]. Check for existing web roles and table permissions. Propose a complete table permissions plan covering all integrated tables. After I approve the plan, create the web role and table permission YAML files using the deterministic scripts."

1. Analyze the site and propose a plan (with Mermaid diagram)
2. Present the plan via plan mode for user approval
3. After approval, create any needed web roles using

   create-web-role.js

4. Create all table permission files using

   create-table-permission.js

5. Return a summary of created files

Task

webapi-settings-architect

${CLAUDE_PLUGIN_ROOT}/agents/webapi-settings-architect.md

"Analyze this Power Pages code site and propose Web API site settings. The following tables have been integrated with Web API: [list of tables integrated in Phase 4]. Check for existing site settings and query Dataverse for exact column LogicalNames. Propose site settings with case-sensitive validated column names. After I approve the plan, create the site setting YAML files using the deterministic scripts."

1. Analyze the site, query Dataverse for exact column LogicalNames
2. Cross-validate column names (case-sensitive)
3. Present the plan via plan mode for user approval
4. After approval, create all site setting files using

   create-site-setting.js

5. Return a summary of created files

Reference:

${CLAUDE_PLUGIN_ROOT}/references/skill-tracking-reference.md

--skillName "IntegrateWebApi"

AskUserQuestion

/deploy-site

"No problem! Remember to deploy your site using

/deploy-site

when you're ready. The Web API calls will not work until the site is deployed with the new permissions."

• Test the API: Open the deployed site and verify Web API calls work in the browser's Network tab
• Check permissions: If any API call returns 403, verify table permissions and site settings are correct. The most common cause of 403 errors is column names in

  Webapi/<table>/fields

  not matching the exact Dataverse LogicalName (case-sensitive — must be all lowercase). If the failing request uses aggregate OData (

  $apply

  ,

  aggregate

  , grouped totals), also verify

  Webapi/<table>/fields

  is set to

  *

  .
• Disable innererror in production: If

  Webapi/error/innererror

  was enabled for debugging, disable it before going live
• Web roles: Users must be assigned the appropriate web roles to access protected APIs

• Use TaskCreate/TaskUpdate to track progress at every phase
• Ask for user confirmation at key decision points (see list below)
• First table sequential, then parallel — the first table creates the shared API client; after that, remaining tables can be processed in parallel since each creates independent files
• Commit at milestones — after integration code and after permission files
• Verify each integration — confirm expected files exist after each agent invocation

1. After Phase 2: Confirm which tables to integrate
2. After Phase 3: Approve integration plan
3. At Phase 6.1: Deploy now or skip permissions (if

   .powerpages-site

   missing)
4. At Phase 6.2: Choose permissions source (upload diagram or let the architects analyze)
5. At Phase 6.3: Approve table permissions plan and Web API site settings plan (both agents run in parallel for Path B, each presents its own plan for approval)
6. At Phase 7.2: Deploy now or deploy later