@pega/sdk 0.0.3 → 0.0.4

package/templates/react-sdk-reference/.github/prompts/generate-all-components.prompt.md

@@ -11,9 +11,12 @@ Read the user's message carefully. Extract:
 - **Base components folder** — the root folder that contains (or will contain) the component type subfolders (e.g. `src/components/`)
 - **Component types in scope** — which types to generate (default: all four if not specified)
 
-Both **design system** and **base components folder** are required. If either is missing or ambiguous, ask both unresolved items in one numbered list. Do not assume or default the base folder — the client's folder structure may differ.
+Both **design system** and **base components folder** are required. If either is missing or ambiguous, you MUST stop and ask the user before proceeding. Do not infer any value from the project structure, `.instructions.md` files, existing folders, or any other source.
+
+⛔ **STOP** — If the user's message does not explicitly state BOTH the design system AND the base components folder, ask for the missing items now. Do not proceed to Step 1 until you have explicit answers from the user for all required inputs.
 
 Example questions (ask only the ones that are actually missing):
+
 1. Which design system should I use? (e.g. Ant Design, Chakra UI, Carbon, Radix UI)
 2. What is your base components folder? (e.g. `src/components/`) — subfolders `field/`, `template/`, `widget/`, and `designSystemExtension/` will be used under it.
 
@@ -21,13 +24,13 @@ Example questions (ask only the ones that are actually missing):
 
 Extract which types the user wants from the message:
 
-| User says | Types in scope |
-|---|---|
-| "generate all components" | field + template + widget + designSystemExtension |
-| "generate field and widget components" | field + widget |
-| "generate widget, template components" | widget + template |
-| "generate all components except templates" | field + widget + designSystemExtension |
-| "replace everything" | field + template + widget + designSystemExtension |
+| User says                                  | Types in scope                                    |
+| ------------------------------------------ | ------------------------------------------------- |
+| "generate all components"                  | field + template + widget + designSystemExtension |
+| "generate field and widget components"     | field + widget                                    |
+| "generate widget, template components"     | widget + template                                 |
+| "generate all components except templates" | field + widget + designSystemExtension            |
+| "replace everything"                       | field + template + widget + designSystemExtension |
 
 Default to **all four types** if the message does not restrict the scope.
 
@@ -35,11 +38,11 @@ Default to **all four types** if the message does not restrict the scope.
 
 Once the base folder is known, derive the output path for each type in scope:
 
-| Type | Derived path |
-|---|---|
-| field | `<base>/field/` |
-| template | `<base>/template/` |
-| widget | `<base>/widget/` |
+| Type                  | Derived path                    |
+| --------------------- | ------------------------------- |
+| field                 | `<base>/field/`                 |
+| template              | `<base>/template/`              |
+| widget                | `<base>/widget/`                |
 | designSystemExtension | `<base>/designSystemExtension/` |
 
 Once design system, base folder, and type scope are resolved, continue to Step 1.
@@ -50,11 +53,11 @@ Once design system, base folder, and type scope are resolved, continue to Step 1
 
 Read the general skill file for every type in scope. Do this upfront — do not re-read per component.
 
-| Type | Skill file to read |
-|---|---|
-| field | `.github/skills/field-components.md` |
-| template | `.github/skills/template-components.md` |
-| widget | `.github/skills/widget-components.md` |
+| Type                  | Skill file to read                          |
+| --------------------- | ------------------------------------------- |
+| field                 | `.github/skills/field-components.md`        |
+| template              | `.github/skills/template-components.md`     |
+| widget                | `.github/skills/widget-components.md`       |
 | designSystemExtension | `.github/skills/design-system-extension.md` |
 
 Keep all loaded skill files active throughout the entire session.
@@ -63,20 +66,58 @@ Keep all loaded skill files active throughout the entire session.
 
 ## Step 2 — Install and discover the design system (once)
 
-Execute **Step 3** from `.github/prompts/add-component.prompt.md` exactly as written:
-- Check `package.json` for the DS package
-- Install if missing, including any peer dependencies
-- Report what was installed
-
-Then execute **Step 4** from `.github/prompts/add-component.prompt.md` exactly as written:
-- Read the DS README from `node_modules`
-- Discover all exported components from `dist/index.d.ts`
-- Read prop interfaces for primitives needed across **all types in scope**:
-  - **field**: form input controls (Input, Select, Checkbox, DatePicker, etc.)
-  - **template**: grid/layout primitives (Grid, Flex, Columns, SimpleGrid, etc.)
-  - **widget**: card/list/table/button/badge primitives
-  - **designSystemExtension**: alert/notification/avatar primitives
-- Note form layout wrappers, size/variant conventions, icon packages, and design tokens
+### 2a — Check and install the DS package
+
+Run this command in your terminal:
+
+```bash
+cat package.json | grep "<design-system-package>"
+```
+
+If the design system package is **not** listed in `dependencies` or `devDependencies`, install it:
+
+```bash
+npm install <design-system-package>
+```
+
+Also install any peer dependencies documented in the package's README. Report what was installed.
+
+### 2b — Discover the DS API from installed files
+
+Run these commands to discover the actual API (do NOT rely on training knowledge):
+
+1. Read the README for correct import paths and usage patterns:
+
+   ```bash
+   cat node_modules/<designSystem>/README.md
+   ```
+
+2. List every exported component:
+
+   ```bash
+   grep "^export" node_modules/<designSystem>/dist/index.d.ts 2>/dev/null || grep -rl "^export" node_modules/<designSystem> --include="index.d.ts" | head -3 | xargs grep "^export"
+   ```
+
+3. For every component you plan to use across all types in scope, read its TypeScript prop interface:
+
+   ```bash
+   find node_modules/<designSystem> -name "ComponentName.d.ts" | head -3
+   grep -A 40 "interface.*Props" <path-from-above>
+   ```
+
+   Focus on primitives needed across **all types in scope**:
+   - **field**: form input controls (Input, Select, Checkbox, DatePicker, etc.)
+   - **template**: grid/layout primitives (Grid, Flex, Columns, SimpleGrid, etc.)
+   - **widget**: card/list/table/button/badge primitives
+   - **designSystemExtension**: alert/notification/avatar primitives
+
+4. Also check:
+   - Whether the DS has a **form layout wrapper** (label + input + helper text) — use it instead of manual margins
+   - Whether it has **size/density/variant conventions** — use built-in props rather than custom padding
+   - Whether it has a **companion icons package** — read its exports before using any icon name; never guess icon names
+   - Whether it has **CSS tokens** — use design system CSS custom properties for spacing; never hardcode `px` values
+
+Only use component names and prop names confirmed in these files.
 
 Build a unified **DS API reference map** covering all types in scope. Reuse it throughout — do not repeat discovery commands per component.
 
@@ -89,6 +130,7 @@ For every type in scope, check whether each component's `<outputPath>/<Component
 Collect all existing components across all types and report them in one consolidated list:
 
 > "The following N components already exist across [types]: [list grouped by type]. How should I proceed?
+>
 > - **Overwrite all** — replace all existing implementations
 > - **Skip existing** — only generate components that don't exist yet
 > - **Cancel** — stop without generating anything"
@@ -99,56 +141,271 @@ Wait for the user's answer before proceeding. If none exist, continue immediatel
 
 ## Step 4 — Generate field components (skip if field not in scope)
 
-If `field` is in scope, execute **Step 4** from `.github/prompts/generate-field-components.prompt.md` in full:
-- Use the derived field output path: `<base>/field/`
-- The general skill (`field-components.md`) is already loaded from Step 1 — do not re-read it
-- The DS API reference map is already built from Step 2 — do not repeat discovery commands
-- For each of the 27 field components: read skill file → generate → register in `component-map.ts`
-- Report progress after each component
+If `field` is in scope, generate each of the 27 field components in order:
+
+**For each field component:**
+
+### 4.1 — Read the component-specific skill file (MANDATORY — do not skip)
+
+Read the file `.github/skills/field-skills/<ComponentName>.md` using your file reading tool. This step is **required** for every component that has a skill file — do not rely solely on the general `field-components.md`.
+
+After reading, extract and keep active:
+
+- **Behavioral Contract** — state management, option loading, edge cases specific to this component
+- **Design System Mapping** table — the recommended DS component for the chosen design system
+- **UI control type** — use this to select the closest DS primitive if the chosen DS is not in the mapping table
+
+If no skill file exists at that path, use the general behavioral skeleton from `field-components.md` loaded in Step 1.
+
+⚠️ The general skill provides the skeleton. The component-specific skill provides the **exact event handling, option-loading logic, and edge cases**. Both are needed.
+
+### 4.2 — Generate the component files
+
+Create the directory `<base>/field/<ComponentName>/`.
+
+Create `<ComponentName>.tsx` using this structure from `field-components.md` (loaded in Step 1):
+
+1. Imports: React hooks + `handleEvent` from `../../helpers/event-utils` + `getComponentFromRegistry` from `@pega/sdk-react` + `PConnFieldProps` + DS input from Step 2
+2. Interface extending `PConnFieldProps` with any extra props from the component skill file
+3. Destructure: `getPConnect`, `label`, `required`, `disabled`, `value`, `validatemessage`, `status`, `readOnly`, `testId`, `helperText`, `displayMode`, `hideLabel`, `placeholder`
+4. Display mode guards: if `DISPLAY_ONLY` or `STACKED_LARGE_VAL` → return `FieldValueList`
+5. Return → DS form input from Step 2, with `onBlur` calling `handleEvent(actions, 'changeNblur', propName, inputValue)`
+
+Pass `data-test-id={testId}` on the underlying interactive element.
+
+Create `index.tsx`:
+
+```typescript
+export { default } from './<ComponentName>';
+```
+
+### 4.3 — Register the component
+
+Edit `src/components/component-map.ts`:
+
+1. Add an import at the top in the **Fields** section
+2. Add an entry in `getSampleComponentMap()` under the fields comment
+
+### 4.4 — Batch checkpoint
+
+After every **5 field components**, run:
+
+```bash
+npm run build
+```
+
+Fix any errors before continuing.
+
+### 4.5 — Report progress
+
+After each component: "`<ComponentName>` ✓ — using `<DS component name>`"
 
 ---
 
 ## Step 5 — Generate template components (skip if template not in scope)
 
-If `template` is in scope, execute **Step 4** from `.github/prompts/generate-template-components.prompt.md` in full:
-- Use the derived template output path: `<base>/template/`
-- The general skill (`template-components.md`) is already loaded from Step 1 — do not re-read it
-- The DS layout API is already discovered from Step 2 — do not repeat discovery commands
-- For each of the 32 template components: read skill file → generate → register in `component-map.ts`
-- Report progress after each component
+If `template` is in scope, generate each of the 32 template components in order:
+
+**For each template component:**
+
+### 5.1 — Read the component-specific skill file (MANDATORY — do not skip)
+
+Read the file `.github/skills/template-skills/<ComponentName>.md` using your file reading tool. This step is **required** for every component — do not rely solely on the general `template-components.md`.
+
+After reading, extract and keep active:
+
+- **Template category** — Layout (uses DS grid from Step 2) | Form (PConnect bridge + CSS) | Page (region extraction + PConnect bridge)
+- **Behavioral Contract** — sub-variants, region handling, slot rendering logic
+- **Design System Mapping** table — the recommended DS layout primitive (for Layout templates only)
+
+If no skill file exists at that path, use the general pattern from `template-components.md` loaded in Step 1.
+
+⚠️ The general skill provides the pattern skeletons. The component-specific skill provides the **exact region structure, sub-variant keys, and rendering logic**. Both are needed.
+
+### 5.2 — Generate the component files
+
+Create the directory `<base>/template/<ComponentName>/`.
+
+Create `<ComponentName>.tsx` using the structure matching the template category from `template-components.md` (loaded in Step 1):
+
+- **Layout**: `PropsWithChildren` + `templateCol` parsing (split on whitespace, strip units, compute ratios) + DS grid/flex from Step 2 rendering children in computed column ratios. On mobile: columns must stack to full width.
+- **Form**: `createElement(createPConnectComponent(), ...)` for each child from `getPConnect().getChildren()[0].getPConnect().getChildren()`. No DS primitives.
+- **Page**: `createElement(createPConnectComponent(), ...)` for each region from `getPConnect().getChildren()`. No DS primitives.
+
+Apply the Behavioral Contract from the component skill file.
+
+Create `index.tsx` if required by the skill file:
+
+```typescript
+export { default } from './<ComponentName>';
+```
+
+Create any CSS file required by the skill file.
+
+### 5.3 — Register the component
+
+Edit `src/components/component-map.ts`:
+
+1. Add an import at the top in the **Templates** section
+2. Add an entry in `getSampleComponentMap()` under the templates comment
+3. For sub-variants (e.g., TwoColumnPage, TwoColumnTab), register each key separately
+
+### 5.4 — Batch checkpoint
+
+After every **5 template components**, run:
+
+```bash
+npm run build
+```
+
+Fix any errors before continuing.
+
+### 5.5 — Report progress
+
+After each component: "`<ComponentName>` ✓ — `<Layout | Form | Page>` template"
 
 ---
 
 ## Step 6 — Generate widget components (skip if widget not in scope)
 
-If `widget` is in scope, execute **Step 4** from `.github/prompts/generate-widget-components.prompt.md` in full:
-- Use the derived widget output path: `<base>/widget/`
-- The general skill (`widget-components.md`) is already loaded from Step 1 — do not re-read it
-- The DS UI primitive map is already built from Step 2 — do not repeat discovery commands
-- For each of the 9 widget components: read skill file → generate → register in `component-map.ts`
-- If no skill file exists for a component (e.g., `SummaryList`), use the general pattern from `widget-components.md`
-- Report progress after each component
+If `widget` is in scope, generate each of the 9 widget components in order:
+
+**For each widget component:**
+
+### 6.1 — Read the component-specific skill file (MANDATORY — do not skip)
+
+Read the file `.github/skills/widget-skills/<ComponentName>.md` using your file reading tool. This step is **required** for every component that has a skill file — do not rely solely on the general `widget-components.md`.
+
+After reading, extract and keep active:
+
+- **Behavioral Contract** — the exact PCore API calls, state variables, event handlers, and edge cases specific to this widget
+- **Design System Mapping** table — the recommended DS primitive for this component's presentation layer
+- **Props interface** — any required/optional props beyond the base `PConnProps`
+
+If no skill file exists at that path (e.g., `SummaryList`), use the general data-fetching pattern from `widget-components.md` loaded in Step 1.
+
+⚠️ The general skill provides the skeleton. The component-specific skill provides the **exact data flow and behavioral logic**. Both are needed — generating from only the general skill will produce components that render but don't fetch or display data correctly.
+
+### 6.2 — Generate the component files
+
+Create the directory `<base>/widget/<ComponentName>/`.
+
+Create `<ComponentName>.tsx` using this structure from `widget-components.md` (loaded in Step 1):
+
+1. Imports (React hooks + DS components from Step 2 + `PConnProps` from `@pega/sdk-react`)
+2. Interface extending PConnProps with props from the component skill file's Props table
+3. Component function: destructure `getPConnect`, call `getPConnect()` to get `pConn`
+4. `useEffect` → data fetch using the exact PCore API call from the skill file's Behavioral Contract
+5. Return → DS Card/List/Table primitive from Step 2 API map, rendering the fetched data
+
+Fill in the `// [DS RENDER]` section with DS primitives confirmed in Step 2. The data-fetching logic comes from the skill file's Behavioral Contract — do NOT invent API calls.
+
+Create `index.tsx`:
+
+```typescript
+export { default } from './<ComponentName>';
+```
+
+Create any CSS or utility files required by the skill file.
+
+### 6.3 — Register the component
+
+Edit `src/components/component-map.ts`:
+
+1. Add an import at the top in the **Widgets** section
+2. Add an entry in `getSampleComponentMap()` under the widgets comment
+
+### 6.4 — Batch checkpoint
+
+After every **5 widget components**, run:
+
+```bash
+npm run build
+```
+
+Fix any errors before continuing.
+
+### 6.5 — Report progress
+
+After each component: "`<ComponentName>` ✓ — using `<DS card/list primitive>`"
 
 ---
 
 ## Step 7 — Generate design system extension components (skip if DSE not in scope)
 
-If `designSystemExtension` is in scope, execute **Step 4** from `.github/prompts/generate-dse-components.prompt.md` in full:
-- Use the derived DSE output path: `<base>/designSystemExtension/`
-- The general skill (`design-system-extension.md`) is already loaded from Step 1 — do not re-read it
-- The DS display primitive map is already built from Step 2 — do not repeat discovery commands
-- For each of the 11 DSE components: read skill file → generate → register in `component-map.ts`
-- Apply the Pattern B/A/C branching as specified in the skill file and `design-system-extension.md`
-- Report progress after each component
+If `designSystemExtension` is in scope, generate each of the 11 DSE components in order:
+
+**For each DSE component:**
+
+### 7.1 — Read the component-specific skill file (MANDATORY — do not skip)
+
+Read the file `.github/skills/design-system-extension-skills/<ComponentName>.md` using your file reading tool. This step is **required** for every component that has a skill file — do not rely solely on the general `design-system-extension.md`.
+
+After reading, extract and keep active:
+
+- **Pattern classification** — B (Pure display) / A (PConnect display) / C (Complex display)
+- **Behavioral Contract** — prop handling, variant mapping, rendering logic, edge cases
+- **Design System Mapping** table — the recommended DS primitive (Pattern B components only)
+
+If no skill file exists at that path, use the general pattern from `design-system-extension.md` loaded in Step 1.
+
+⚠️ The general skill provides the pattern skeletons. The component-specific skill provides the **exact prop interface, variant logic, and edge cases**. Both are needed.
+
+### 7.2 — Generate the component files
+
+Create the directory `<base>/designSystemExtension/<ComponentName>/`.
+
+Create `<ComponentName>.tsx` using the structure matching the pattern from `design-system-extension.md` (loaded in Step 1):
+
+- **Pattern B** (Pure display — AlertBanner, Banner, Operator, WssQuickCreate): variant mapping (urgent→error, warning→warning, info→info, success→success) + DS Alert/Card/Avatar primitive from Step 2. No `getPConnect`.
+- **Pattern A** (PConnect display — CaseSummaryFields, DetailsFields, FieldValueList): CSS classes + optional DS typography, no DS component primitives. May use `getPConnect`.
+- **Pattern C** (Complex display — FieldGroup, FieldGroupList, Pulse, RichTextEditor): `createElement(createPConnectComponent(), ...)` for PConnect children, semantic HTML. No DS primitives.
+
+Apply the Behavioral Contract from the component skill file.
+
+Create `index.tsx` if required by the skill file:
+
+```typescript
+export { default } from './<ComponentName>';
+```
+
+Create any CSS file required by the skill file.
+
+### 7.3 — Register the component
+
+Edit `src/components/component-map.ts`:
+
+1. Add an import at the top in the **Design System Extension** section
+2. Add an entry in `getSampleComponentMap()` under the DSE comment
+
+### 7.4 — Batch checkpoint
+
+After every **5 DSE components**, run:
+
+```bash
+npm run build
+```
+
+Fix any errors before continuing.
+
+### 7.5 — Report progress
+
+After each component: "`<ComponentName>` ✓ — Pattern `<B/A/C>`"
 
 ---
 
 ## Step 8 — Verify the build
 
-Execute **Step 7** from `.github/prompts/add-component.prompt.md` exactly as written:
-- Run `npm run build`
-- Fix any TypeScript or build errors before reporting completion
-- Report a final summary:
-  - Total components generated, grouped by type
-  - All entries added to `component-map.ts`
-  - Any components skipped (if "skip existing" was chosen in Step 3)
+Run:
+
+```bash
+npm run build
+```
+
+Fix any TypeScript or build errors before reporting completion.
+
+Report a final summary:
+
+- Total components generated, grouped by type
+- All entries added to `component-map.ts`
+- Any components skipped (if "skip existing" was chosen in Step 3)