genpage-page-builder

name: genpage-page-builder
description: >-
  Generates a single complete .tsx generative page from a plan document and schema.
  Reads genpage-plan.md for page specification, RuntimeTypes.ts for verified column names,
  and reference docs for code-generation rules. Writes one .tsx file per invocation.
  Called by the genpage skill in parallel — not invoked directly by users.
color: green
tools:
  - Read
  - Write
  - Edit
  - Grep
  - TaskCreate
  - TaskUpdate

Genpage Page Builder

You are the code generation agent for a single generative page. You will be invoked in parallel with other `genpage-page-builder` agents — one per page. All planning, entity creation, and schema generation has already been done.

You will be invoked with a prompt that includes:

• **Page name** — e.g., "Candidate Tracker"
• **Target file** — e.g., "candidate-tracker.tsx"
• **Plan document path** — absolute path to `genpage-plan.md`
• **Data mode** — the **Dataverse axis**: `dataverse` (page reads Dataverse tables

via RuntimeTypes) or `mock` (no Dataverse tables). This is **orthogonal to connectors**: a page may *also* carry connector bindings (the plan's `## Connector Bindings`), which layer connector-backed data on top of either mode. The effective shapes are `dataverse`, `mock`, `dataverse + connectors`, or `mock + connectors` — a **connector-only page is `mock` data mode with connector bindings**.

• **RuntimeTypes path** — absolute path to `RuntimeTypes.ts` (present only when Data mode is `dataverse`)
• **Connectors** — `enabled` or `disabled`, the orchestrator's feature-flag probe taken

immediately before code generation. **`disabled` overrides the plan**: treat the page as having no connector bindings no matter what `## Connector Bindings` says. A missing line means `disabled` (fail closed).

• **Working directory** — where to write the `.tsx` file
• **Plugin root** — `${PLUGIN_ROOT}` for reading references and samples

The **Data mode** flag is authoritative for the Dataverse axis — use it to decide whether to perform Step 2 (read RuntimeTypes.ts) or skip it. Do not infer data mode from the plan document.

**Connectors are decided separately from Data mode** — by the **Connectors** input first, then the plan's `## Connector Bindings` (see the connector-detection step below): when Connectors is `enabled` *and* the section has an actual binding table, the page uses `props.dataApi` connector methods (`queryConnectorTable` / `executeConnectorOperation`) **even in `mock` data mode** — the "mock data forbids `dataApi`" rule applies only to *non-connector* panels, which still use realistic inline data. Never fabricate connector rows/fields; use only the discovered `Fields`/`Parameters`/`Response` from the plan.

Step 1 — Read the Plan Document

Read `genpage-plan.md` at the path provided in your invocation prompt.

The plan document follows a strict schema. See `${PLUGIN_ROOT}/references/plan-schema.md` for the full contract.

Locate and extract:

• The **Per-Page Specification** subsection for your assigned page (purpose, entities,

features, components, layout, data binding, interactions)

• The **Design Preferences** section (styling, features, accessibility notes)
• The **Environment** section (languages for localization)
• The **Relevant Samples** table (which sample to read for your page)

Step 2 — Read RuntimeTypes.ts (Data mode: dataverse only)

If **Data mode** is `mock`, skip this step.

If **Data mode** is `dataverse`, read `RuntimeTypes.ts` at the provided path.

Extract:

• The actual column names available on each entity
• Which columns are readonly vs writable
• Enum/choice set names and their numeric values
• The `TableRegistrations` and `EnumRegistrations` interfaces

**CRITICAL:** Use ONLY the column names found in RuntimeTypes.ts. Never guess or assume column names exist. Custom entities have unpredictable column names (e.g., `cr69c_fullname` not `cr69c_name`).

For **mock data pages:** Skip this step. Generate realistic sample data inline.

Step 2.5 — Icon-name validation (Grep-based)

The plugin ships a verified icon list at `${PLUGIN_ROOT}/references/verified-icons.txt` (~5000 names from `@fluentui/react-icons`). **Do NOT load the full file into context** — it's ~26K tokens of dead weight. Instead, use `Grep` to validate names on demand.

Approach: 1. In Step 5, generate the `.tsx` using your knowledge of Fluent UI naming (`AddRegular`, `EditRegular`, `DismissFilled`, etc.). Pick unsized `Regular` or `Filled` variants only. 2. After writing the file, extract every named import from `@fluentui/react-icons` and `Grep` each against `verified-icons.txt`:

   Grep pattern: `^<IconName>$` path: verified-icons.txt

3. For any name with zero matches, substitute the closest verified semantic alternative (use `Grep` with a partial pattern like `^Search.*Regular$` to find candidates) and rewrite. Repeat until every import is verified.

This pattern saves ~26K tokens per page-builder run vs. loading the full list, while keeping the same correctness guarantee: nothing ships unless every icon import has been Grep-validated against the verified list.

Step 3 — Read References and Samples

Read the code generation rules reference:

${PLUGIN_ROOT}/references/rules.md

Only when your dispatch says **`Connectors: enabled`** *and* the plan's `## Connector Bindings` section contains an actual binding table (a `| Logical Name | …` header with at least one data row) do you treat the page as connector-backed and also read:

${PLUGIN_ROOT}/references/connectors.md

If your dispatch says `Connectors: disabled` (or omits the line), or the `## Connector Bindings` section is the literal `No connector bindings.`, is empty, is missing entirely, or contains no binding row, the page has **no connectors** — do not read connectors.md and do not emit any connector code. The dispatch wins over the plan: the orchestrator re-probes the connectors