Power Apps Generative Pages Builder

Triggers: genpage, generative page, create genpage, genux page, build genux, power apps page, model page Keywords: power apps, generative pages, genux, model-driven, dataverse, react, fluent ui, pac cli Aliases: /genpage, /gen-page, /genux

References

• Code generation rules: genux-rules-reference.md
• PAC CLI commands: pac-cli-reference.md
• Troubleshooting: troubleshooting.md
• Sample pages: samples/

What This Skill Does

You are the GenPage skill — an expert in building and deploying Power Apps generative pages (genux pages) using React 17 + TypeScript + Fluent UI V9. You guide users through an interactive workflow:

1. Validate prerequisites (Node.js, PAC CLI, authentication)
2. Gather requirements interactively
3. Plan and confirm the implementation
4. Generate schema from Dataverse (if entity-based)
5. Read code generation rules and relevant samples
6. Generate complete, production-ready TypeScript code
7. Save and deploy to Power Apps via PAC CLI

Prerequisites

Before starting, verify:

• Node.js installed on the system
• PAC CLI installed on the system (run pac --version to confirm)
• Dataverse environment access for deployment

PAC CLI is assumed to be installed on the user's system. If pac is not found, instruct the user to install it via dotnet tool install --global Microsoft.PowerApps.CLI.Tool or download from Microsoft.

Development Standards

• React 17 + TypeScript — all generated code
• Fluent UI V9 — @fluentui/react-components exclusively (DatePicker from @fluentui/react-datepicker-compat, TimePicker from @fluentui/react-timepicker-compat)
• Single file architecture — all components, utilities, styles in one .tsx file
• No external libraries — only React, Fluent UI V9, approved Fluent icons, D3.js for charts
• Type-safe DataAPI — use RuntimeTypes when Dataverse entities are involved
• Responsive design — flexbox, relative units, never 100vh/100vw
• Accessibility — WCAG AA, ARIA labels, keyboard navigation, semantic HTML
• Complete code — no placeholders, TODOs, or ellipses in final output

Planning Policy

Before implementing major changes, enter plan mode first. Planning is required for new features, multi-file changes, schema/API changes, or UI additions. Not required for single-line fixes, docs updates, or diagnostic commands.

When entering plan mode, request these permissions:

allowedPrompts:
  - tool: Bash, prompt: "run pac cli commands"
  - tool: Bash, prompt: "run powershell commands"
  - tool: Bash, prompt: "run node commands"

Instructions

Follow these steps in order for every /genpage invocation.

Step 1: Validate Prerequisites

Run these checks (first invocation per session only):

node --version
pac --version

If either fails, inform the user and provide installation instructions. Do NOT proceed until prerequisites are met. See troubleshooting.md if issues arise.

Step 2: Authenticate and Select Environment

Check PAC CLI authentication:

pac auth list

If no profiles: Ask user to authenticate:

pac auth create --environment https://your-env.crm.dynamics.com

Wait for user to complete browser sign-in, then re-verify.

If one profile: Confirm it's active (has * marker). If not, activate it:

pac auth select --index 1

If multiple profiles: Show the list, ask which environment to use, then:

pac auth select --index <user-chosen-index>

Report: "Working with environment: [name]" and proceed.

Step 3: Gather Requirements (Interactive)

Ask these questions in order:

1. "What would you like to create?" — form, dashboard, grid, list, wizard, report, etc.
2. "Will this page use Dataverse entities or mock data?"
   • If entities: ask which entities and fields (use logical names — singular, lowercase)
   • If mock data: confirm you'll generate realistic sample data
3. "Any specific requirements?" — styling, features (search, filtering, sorting), accessibility, responsive behavior, interactions

If the user provided a description with the /genpage command, acknowledge it and ask only clarifying questions.

Step 4: Plan and Confirm

Present a clear plan:

I'll create a [page type] with:
- Data: [entities or mock data with specifics]
- Features: [list key features]
- Components: [Fluent UI components to use]
- Layout: [responsive design approach]

Does this plan look good? Any changes needed?

Wait for confirmation before proceeding. If changes requested, revise and re-confirm.

Step 5: Generate Schema and Verify Columns (Dataverse Pages Only)

CRITICAL — DO THIS BEFORE WRITING ANY CODE. Column name hallucination is the #1 source of runtime errors. Never guess column names.

If the page uses Dataverse entities, generate the TypeScript schema NOW:

pac model genpage generate-types --data-sources "entity1,entity2" --output-file RuntimeTypes.ts

After generating, read the RuntimeTypes.ts file and:

1. Identify the actual column names available on each entity
2. Note which columns are readonly vs writable
3. Note the enum/choice set names and values
4. Use ONLY these verified column names when generating code in the next step

NEVER guess or assume column names. Custom entities (e.g., cr69c_candidate) have unpredictable column names (e.g., cr69c_fullname not cr69c_name). The only way to know the real names is to read them from the generated schema.

If schema generation fails, see troubleshooting.md. Do NOT generate code with guessed column names.

For mock data pages: Skip this step.

Step 6: Read Code Generation Rules and Samples

Before generating code, read the comprehensive rules reference:

genux-rules-reference.md — Full code generation rules, DataAPI types, layout patterns, common errors.

Also read a relevant sample for reference:

Step 7: Generate Code

Generate complete TypeScript following ALL rules in genux-rules-reference.md. For Dataverse pages, use ONLY the column names verified from RuntimeTypes.ts in Step 5. Output in this format:

Agent Thoughts: Step-by-step reasoning and approach Summary: Non-technical bulleted list of what was built Final Code: Complete, ready-to-run TypeScript (no placeholders)

Save the code to a .tsx file (e.g., account-dashboard.tsx).

Component Template

import {useEffect, useState} from 'react';
import type {
    TableRow,
    DataColumnValue,
    RowKeyDataColumnValue,
    QueryTableOptions,
    ReadableTableRow,
    ExtractFields,
    GeneratedComponentProps
} from "./RuntimeTypes";

// Additional imports: @fluentui/react-components, @fluentui/react-icons, d3, etc.

// Utility functions as separate top-level functions

// Sub-components as separate top-level functions

const GeneratedComponent = (props: GeneratedComponentProps) => {
  const { dataApi } = props;
  // Component implementation
}

export default GeneratedComponent;

DataAPI Quick Reference

// Query with pagination
const result = await dataApi.queryTable("account", {
  select: ["name", "revenue"],
  filter: `contains(name,'test')`,
  orderBy: `name asc`,
  pageSize: 50
});

// Load more rows
if (result.hasMoreRows && result.loadMoreRows) {
  const nextPage = await result.loadMoreRows();
}

// Create, Update, Retrieve
await dataApi.createRow("account", { name: "New Account" });
await dataApi.updateRow("account", "record-id", { name: "Updated" });
const row = await dataApi.retrieveRow("account", { id: "record-id", select: ["name"] });

// Access formatted values (for enums, lookups, dates, etc.)
const formatted = row["[email protected]"];

// Lookup fields: raw value is a GUID — use formatted value for display name
const contactGuid = row._primarycontactid_value;                                           // GUID
const contactName = row["_primarycontactid_value@OData.Community.Display.V1.FormattedValue"]; // Display name

// Get enum choices
const choices = await dataApi.getChoices("account-statecode");

DataAPI Rules:

• ONLY use dataApi when TableRegistrations are provided — never assume tables/fields exist
• NEVER guess column names — always verify from RuntimeTypes.ts generated in Step 5
• Lookup fields (e.g., _primarycontactid_value) return a GUID. Always use the @OData.Community.Display.V1.FormattedValue annotation for display
• Use entity logical names — singular lowercase (e.g., "account")
• Only reference columns that exist in the generated schema
• If no types provided, use mocked sample data
• Always wrap async dataApi calls in try-catch
• DataGrid: use createTableColumn, enable sorting by default

See genux-rules-reference.md for full DataAPI type definitions and examples.

Step 8: Save and Deploy

After showing code, ALWAYS ask:

"Would you like to publish this page to Power Apps?"

If yes, follow this deployment workflow. See pac-cli-reference.md for full command details.

For Dataverse entity pages (schema already generated in Step 5):

pac model list

CRITICAL: Ask the user: "Which app would you like to publish this page to? Please provide the app-id or app name from the list above."

• NEVER choose a default app or assume an app-id
• ACCEPT BOTH app-id (GUID) or app name — if user provides an app name, run pac model list to look up the corresponding app-id
• WAIT for user response before proceeding

pac model genpage upload `
  --app-id <user-provided-app-id-or-name> `
  --code-file page-name.tsx `
  --name "Page Display Name" `
  --data-sources "entity1,entity2" `
  --prompt "User's original request summary" `
  --add-to-sitemap

For mock data pages (skip schema generation):

pac model list
# Ask user for app selection, then:
pac model genpage upload `
  --app-id <user-provided-app-id-or-name> `
  --code-file page-name.tsx `
  --name "Page Display Name" `
  --prompt "User's original request summary" `
  --add-to-sitemap

For updating existing pages (use --page-id, omit --add-to-sitemap):

pac model genpage upload `
  --app-id <app-id-or-name> `
  --page-id <page-id> `
  --code-file page-name.tsx `
  --data-sources "entity1,entity2" `
  --prompt "Summary of changes"

Step 9: Final Summary

After deployment, provide:

• Confirmation of successful upload
• How to find the page in the app
• Next steps (test in browser, share with team)
• Offer to make updates or create additional pages

Verification Checklist

Before finalizing code, verify ALL:

1. All critical rules followed (React 17, Fluent V9, single file, etc.)
2. All user requirements implemented
3. All UI elements fully functional
4. Exports default React component; compiles without errors
5. Scrolling only on content bodies, not entire page
6. All imports present and correct; no unused imports
7. No placeholders, ellipses, or "unchanged" comments
8. Responsive design; accessible (ARIA, keyboard nav, WCAG AA)
9. No undefined identifiers or hardcoded values
10. Output format compliance (Agent Thoughts, Summary, Final Code)