@pega/sdk 0.0.1 → 0.0.3

package/templates/react-sdk-reference/.cursor/rules/prompts/generate-dse-components.mdrules

@@ -0,0 +1,131 @@
+---
+description: generate-dse-components.prompt
+alwaysApply: false
+---
+
+## Step 0 — Resolve inputs
+
+Read the user's message carefully. Extract:
+
+- **Design system** — the UI library to use (e.g. `Ant Design`, `Chakra UI`, `Carbon`, `Radix UI`)
+- **Output base path** — the folder where DSE components should be generated (e.g. `src/components/designSystemExtension/`)
+- **Component list** — which components to generate (default: all 11 listed below)
+
+Both **design system** and **output base path** are required. If either is missing or ambiguous, ask both unresolved items in one numbered list. Do not assume or default the output path — the client's folder structure may differ from the reference app.
+
+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. Where should the DSE components be generated? (e.g. `src/components/designSystemExtension/`)
+
+If the user specified a subset (e.g., "just AlertBanner and FieldValueList"), restrict the list accordingly.
+
+Once both are known, continue to Step 1.
+
+### Full component list (default — 11 DSE components)
+
+| Component | Pattern | DS needed? |
+|---|---|---|
+| AlertBanner | B — Pure display | Yes |
+| Banner | B — Pure display | Yes |
+| CaseSummaryFields | A — PConnect display | Minimal |
+| DetailsFields | A — PConnect display | Minimal |
+| FieldGroup | C — Complex display | No |
+| FieldGroupList | C — Complex display | No |
+| FieldValueList | A — PConnect display | No (CSS only) |
+| Operator | B — Pure display | Yes |
+| Pulse | C — Complex display | No |
+| RichTextEditor | C — Complex display | No |
+| WssQuickCreate | B — Pure display | Yes |
+
+---
+
+## Step 1 — Read `design-system-extension.md` (once, for the entire session)
+
+Read the full contents of `.cursor/rules/skills/design-system-extension.mdrules`.
+
+This gives you:
+- All three implementation patterns (Pure display, Field value display, Complex display with PConnect)
+- The `// [DS RENDER]` placeholder approach for Pattern B components
+- The Design System Adaptation section — pattern categorisation, variant mapping table, DS discovery guidance
+- Styling patterns — when to use CSS files vs DS style props
+- Registration conventions
+
+Keep this context active throughout the entire generation session. Do not re-read it per component.
+
+---
+
+## Step 2 — Install and discover the design system (once)
+
+Execute **Step 3** from `.cursor/rules/prompts/add-component.mdrules` 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 `.cursor/rules/prompts/add-component.mdrules` exactly as written:
+- Read the DS README from `node_modules`
+- Discover exported components from `dist/index.d.ts`
+- Focus on display primitives used by Pattern B components: Alert, Card, Avatar, Badge, Tag, Notification
+- Read prop interfaces for these components from `.d.ts` files
+
+> Pattern A/C components (FieldValueList, FieldGroup, Pulse, etc.) use PConnect bridge or plain CSS — they do not use the DS API. Only Pattern B components consume DS primitives.
+
+Build a **DS display primitive reference map** from this discovery. Reuse it for every Pattern B component — do not repeat these commands per component.
+
+---
+
+## Step 3 — Overwrite check (all at once)
+
+For each component in the list, check whether `<outputPath>/<ComponentName>/<ComponentName>.tsx` already exists.
+
+If **any** exist, report them all at once and ask:
+> "The following N components already exist: [list]. 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"
+
+Wait for the user's answer before proceeding. If none exist, continue immediately.
+
+---
+
+## Step 4 — Generate each component (loop)
+
+For each component in the resolved list (in the order listed in Step 0):
+
+### 4a — Read the component-specific skill file
+Execute **Step 2** from `.cursor/rules/prompts/add-component.mdrules` for this component:
+- Read `.cursor/rules/skills/design-system-extension-skills/<ComponentName>.mdrules` fully
+- Identify the component's pattern (B / A / C) from the skill file
+- Pay attention to:
+  - **Behavioral Contract** — prop handling, variant mapping, rendering logic, edge cases
+  - **Design System Mapping** table — the recommended DS primitive for Pattern B components
+
+### 4b — Generate the component files
+Execute **Step 5** from `.cursor/rules/prompts/add-component.mdrules` for this component:
+- Create `<outputPath>/<ComponentName>/` directory
+- Create `<ComponentName>.tsx` using:
+  - **Pattern B** (Pure display — AlertBanner, Banner, Operator, WssQuickCreate): use DS alert/card/avatar primitive from Step 2 API map in the `// [DS RENDER]` section; apply variant mapping from the skill file
+  - **Pattern A** (PConnect display — CaseSummaryFields, DetailsFields, FieldValueList): use CSS classes or DS typography props; no DS component primitives
+  - **Pattern C** (Complex display — FieldGroup, FieldGroupList, Pulse, RichTextEditor): use PConnect bridge (`createElement(createPConnectComponent(), ...)`); no DS primitives
+- Create `index.tsx` if required by the skill file:
+  ```typescript
+  export { default } from './<ComponentName>';
+  ```
+- Create any CSS file required by the skill file
+
+### 4c — Register the component
+Execute **Step 6** from `.cursor/rules/prompts/add-component.mdrules` for this component:
+- Add the import to `src/components/component-map.ts` in the Design System Extension section
+- Add the entry to `getSampleComponentMap()` under the DSE comment
+- Do not reorder or restructure any existing entries
+
+### 4d — Report progress
+After each component: "`<ComponentName>` ✓ — Pattern `<B/A/C>`<`, using <DS primitive>` if Pattern B>"
+
+---
+
+## Step 5 — Verify the build
+
+Execute **Step 7** from `.cursor/rules/prompts/add-component.mdrules` exactly as written:
+- Run `npm run build`
+- Fix any TypeScript or build errors before reporting completion
+- Report a summary: list of all files created and all entries added to `component-map.ts`

package/templates/react-sdk-reference/.cursor/rules/prompts/generate-field-components.mdrules

@@ -0,0 +1,144 @@
+---
+description: generate-field-components.prompt
+alwaysApply: false
+---
+
+## Step 0 — Resolve inputs
+
+Read the user's message carefully. Extract:
+
+- **Design system** — the UI library to use (e.g. `Ant Design`, `Chakra UI`, `Carbon`, `Radix UI`)
+- **Output base path** — the folder where field components should be generated (e.g. `src/components/field/`, `app/ui/fields/`)
+- **Component list** — which components to generate (default: all 27 listed below)
+
+Both **design system** and **output base path** are required. If either is missing or ambiguous, ask both unresolved items in one numbered list. Do not assume or default the output path — the client's folder structure may differ from the reference app.
+
+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. Where should the field components be generated? (e.g. `src/components/field/`)
+
+If the user specified a subset (e.g., "just TextInput and Dropdown"), restrict the list accordingly.
+
+Once both are known, continue to Step 1.
+
+### Full component list (default)
+
+| Component | Pega Name |
+|---|---|
+| AutoComplete | AutoComplete |
+| CancelAlert | CancelAlert |
+| Checkbox | Checkbox |
+| Currency | Currency |
+| Date | Date |
+| DateTime | DateTime |
+| Decimal | Decimal |
+| Dropdown | Dropdown |
+| Email | Email |
+| Group | Group |
+| Integer | Integer |
+| Location | Location |
+| Multiselect | Multiselect |
+| ObjectReference | ObjectReference |
+| Percentage | Percentage |
+| Phone | Phone |
+| RadioButtons | RadioButtons |
+| RichText | RichText |
+| ScalarList | ScalarList |
+| SelectableCard | SelectableCard |
+| SemanticLink | SemanticLink |
+| TextArea | TextArea |
+| TextContent | TextContent |
+| TextInput | TextInput |
+| Time | Time |
+| URL | URL |
+| UserReference | UserReference |
+
+---
+
+## Step 1 — Read `field-components.md` (once, for the entire session)
+
+Read the full contents of `.cursor/rules/skills/field-components.mdrules`.
+
+This gives you:
+- The behavioral skeleton every field component must follow (state, effects, event handling, display modes)
+- The Design System Adaptation guide (prop mapping conventions, form layout wrappers)
+- The abstract template to use as a base for all components
+
+Keep this context active throughout the entire generation session. Do not re-read it per component.
+
+---
+
+## Step 2 — Install and discover the design system (once)
+
+Execute **Step 3** from `.cursor/rules/prompts/add-component.mdrules` 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 `.cursor/rules/prompts/add-component.mdrules` exactly as written:
+- Read the DS README from `node_modules`
+- Discover all exported components from `dist/index.d.ts`
+- Read prop interfaces for the control types needed across the component list
+- Note form layout wrappers, size/variant conventions, icon packages, and design tokens
+
+Build a **DS API reference map** from this discovery. You will reuse it for every component — do not repeat these commands per component.
+
+---
+
+## Step 3 — Overwrite check (all at once)
+
+For each component in the list, check whether `<outputPath>/<ComponentName>/<ComponentName>.tsx` already exists.
+
+If **any** exist, report them all at once and ask:
+> "The following N components already exist: [list]. 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"
+
+Wait for the user's answer before proceeding. If none exist, continue immediately.
+
+---
+
+## Step 4 — Generate each component (loop)
+
+For each component in the resolved list (in the order listed in Step 0):
+
+### 4a — Read the component-specific skill file
+Execute **Step 2** from `.cursor/rules/prompts/add-component.mdrules` for this component:
+- Read `.cursor/rules/skills/field-skills/<ComponentName>.mdrules` fully
+- Pay attention to:
+  - **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
+
+### 4b — Generate the component files
+Execute **Step 5** from `.cursor/rules/prompts/add-component.mdrules` for this component:
+- Create `<outputPath>/<ComponentName>/` directory
+- Create `<ComponentName>.tsx` using:
+  - The abstract behavioral skeleton from `field-components.md` (read in Step 1)
+  - The Behavioral Contract from the component skill file
+  - The DS API confirmed in Step 2 (from the DS API reference map — no new terminal commands needed)
+  - Display mode guards (`DISPLAY_ONLY`, `STACKED_LARGE_VAL`) via `getComponentFromRegistry('FieldValueList')`
+  - `data-test-id={testId}` on the underlying interactive element
+- Create `index.tsx`:
+  ```typescript
+  export { default } from './<ComponentName>';
+  ```
+
+### 4c — Register the component
+Execute **Step 6** from `.cursor/rules/prompts/add-component.mdrules` for this component:
+- Add the import to `src/components/component-map.ts` in the Fields section
+- Add the entry to `getSampleComponentMap()` under the fields comment
+- Do not reorder or restructure any existing entries
+
+### 4d — Report progress
+After each component: "`<ComponentName>` ✓ — using `<DS component name>`"
+
+---
+
+## Step 5 — Verify the build
+
+Execute **Step 7** from `.cursor/rules/prompts/add-component.mdrules` exactly as written:
+- Run `npm run build`
+- Fix any TypeScript or build errors before reporting completion
+- Report a summary: list of all files created and all entries added to `component-map.ts`

package/templates/react-sdk-reference/.cursor/rules/prompts/generate-template-components.mdrules

@@ -0,0 +1,156 @@
+---
+description: generate-template-components.prompt
+alwaysApply: false
+---
+
+## Step 0 — Resolve inputs
+
+Read the user's message carefully. Extract:
+
+- **Design system** — the UI library to use (e.g. `Ant Design`, `Chakra UI`, `Carbon`, `Radix UI`)
+- **Output base path** — the folder where template components should be generated (e.g. `src/components/template/`)
+- **Component list** — which templates to generate (default: all 32 listed below)
+
+Both **design system** and **output base path** are required. If either is missing or ambiguous, ask both unresolved items in one numbered list. Do not assume or default the output path — the client's folder structure may differ from the reference app.
+
+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. Where should the template components be generated? (e.g. `src/components/template/`)
+
+> **Note:** The design system applies only to **layout templates** (TwoColumn, OneColumn, NarrowWide, WideNarrow, and their sub-variants). Form templates and page templates use the PConnect bridge pattern and are design-system agnostic — they will be generated without DS primitives regardless of your choice.
+
+If the user specified a subset (e.g., "just TwoColumn and OneColumn"), restrict the list accordingly.
+
+Once both are known, continue to Step 1.
+
+### Full component list (default — 32 templates)
+
+| Component | Category |
+|---|---|
+| AdvancedSearch | Page |
+| AppShell | Page |
+| BannerPage | Page |
+| CaseSummary | Page |
+| CaseView | Page |
+| CaseViewActionsMenu | Widget |
+| Confirmation | Page |
+| DataReference | Form |
+| DefaultForm | Form |
+| DefaultPage | Page |
+| Details | Layout |
+| DetailsSubTabs | Layout |
+| DetailsThreeColumn | Layout |
+| DetailsTwoColumn | Layout |
+| DynamicTabs | Navigation |
+| FieldGroupTemplate | Form |
+| HierarchicalForm | Form |
+| InlineDashboard | Page |
+| InlineDashboardPage | Page |
+| ListPage | Page |
+| ListView | Page |
+| MultiReferenceReadOnly | Display |
+| NarrowWide | Layout |
+| OneColumn | Layout |
+| PromotedFilters | Widget |
+| SelfServiceCaseView | Page |
+| SimpleTable | Table |
+| SingleReferenceReadOnly | Display |
+| SubTabs | Navigation |
+| TwoColumn | Layout |
+| WideNarrow | Layout |
+| WssNavBar | Navigation |
+
+---
+
+## Step 1 — Read `template-components.md` (once, for the entire session)
+
+Read the full contents of `.cursor/rules/skills/template-components.mdrules`.
+
+This gives you:
+- **Layout template pattern** — DS-agnostic grid skeleton with `// [DS GRID]` placeholder; `templateCol` parsing logic; responsive behavior rules
+- **Design System Adaptation section** — how to map the chosen DS's grid/flex primitive to the computed column ratios
+- **Form template pattern** — PConnect bridge via `createElement(createPConnectComponent(), ...)` and `connectToState`; no DS involved
+- **Page template pattern** — region extraction via `getRawMetadata()` and PConnect bridge; no DS involved
+- Registration conventions and helper utilities
+
+Keep this context active throughout the entire generation session. Do not re-read it per component.
+
+---
+
+## Step 2 — Install and discover the design system (once)
+
+Execute **Step 3** from `.cursor/rules/prompts/add-component.mdrules` 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 `.cursor/rules/prompts/add-component.mdrules` exactly as written:
+- Read the DS README from `node_modules`
+- Discover exported layout components (Grid, Columns, Flex, SimpleGrid, etc.) from `dist/index.d.ts`
+- Read prop interfaces for the grid/layout components needed by layout templates
+- Note responsive breakpoint APIs and column sizing conventions
+
+> You only need layout-related DS components. Form and page templates do not use the DS.
+
+Build a **DS layout API reference** from this discovery. Reuse it for every layout template — do not repeat these commands per component.
+
+---
+
+## Step 3 — Overwrite check (all at once)
+
+For each component in the list, check whether `<outputPath>/<ComponentName>/<ComponentName>.tsx` already exists.
+
+If **any** exist, report them all at once and ask:
+> "The following N components already exist: [list]. 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"
+
+Wait for the user's answer before proceeding. If none exist, continue immediately.
+
+---
+
+## Step 4 — Generate each component (loop)
+
+For each component in the resolved list (in the order listed in Step 0):
+
+### 4a — Read the component-specific skill file
+Execute **Step 2** from `.cursor/rules/prompts/add-component.mdrules` for this component:
+- Read `.cursor/rules/skills/template-skills/<ComponentName>.mdrules` fully
+- Identify the template category from the skill file:
+  - **Layout** — uses DS grid primitives from Step 2's API reference
+  - **Form** — uses PConnect bridge + CSS classes; ignore DS
+  - **Page** — uses region extraction + PConnect bridge; ignore DS
+- Pay attention to Behavioral Contract, sub-variants, and any Design System Mapping table
+
+### 4b — Generate the component files
+Execute **Step 5** from `.cursor/rules/prompts/add-component.mdrules` for this component:
+- Create `<outputPath>/<ComponentName>/` directory
+- Create `<ComponentName>.tsx` using:
+  - **Layout templates**: DS-agnostic skeleton from `template-components.md` with the `// [DS GRID]` section filled in using DS layout API confirmed in Step 2
+  - **Form/Page templates**: PConnect bridge pattern from `template-components.md`; no DS primitives
+  - 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 (e.g., `DefaultForm.css` with grid classes)
+
+### 4c — Register the component
+Execute **Step 6** from `.cursor/rules/prompts/add-component.mdrules` for this component:
+- Add the import to `src/components/component-map.ts` in the Templates section
+- Add the entry to `getSampleComponentMap()` under the templates comment
+- For sub-variants (e.g., TwoColumnPage, TwoColumnTab), register each key separately pointing to its own file or a shared implementation as specified in the skill file
+- Do not reorder or restructure any existing entries
+
+### 4d — Report progress
+After each component: "`<ComponentName>` ✓ — `<Layout | Form | Page>` template`<, using <DS component name> for grid>` if layout"
+
+---
+
+## Step 5 — Verify the build
+
+Execute **Step 7** from `.cursor/rules/prompts/add-component.mdrules` exactly as written:
+- Run `npm run build`
+- Fix any TypeScript or build errors before reporting completion
+- Report a summary: list of all files created and all entries added to `component-map.ts`

package/templates/react-sdk-reference/.cursor/rules/prompts/generate-widget-components.mdrules

@@ -0,0 +1,129 @@
+---
+description: generate-widget-components.prompt
+alwaysApply: false
+---
+
+## Step 0 — Resolve inputs
+
+Read the user's message carefully. Extract:
+
+- **Design system** — the UI library to use (e.g. `Ant Design`, `Chakra UI`, `Carbon`, `Radix UI`)
+- **Output base path** — the folder where widget components should be generated (e.g. `src/components/widget/`)
+- **Component list** — which widgets to generate (default: all 9 listed below)
+
+Both **design system** and **output base path** are required. If either is missing or ambiguous, ask both unresolved items in one numbered list. Do not assume or default the output path — the client's folder structure may differ from the reference app.
+
+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. Where should the widget components be generated? (e.g. `src/components/widget/`)
+
+If the user specified a subset (e.g., "just ToDo and Attachment"), restrict the list accordingly.
+
+Once both are known, continue to Step 1.
+
+### Full component list (default — 9 widgets)
+
+| Component | Description |
+|---|---|
+| AppAnnouncement | System-wide announcements |
+| Attachment | File upload/download |
+| CaseHistory | Case audit trail |
+| FileUtility | File management utility |
+| Followers | Case followers list |
+| QuickCreate | Quick case creation buttons |
+| SummaryItem | Single summary card |
+| SummaryList | List of summary cards |
+| ToDo | Assignment worklist |
+
+---
+
+## Step 1 — Read `widget-components.md` (once, for the entire session)
+
+Read the full contents of `.cursor/rules/skills/widget-components.mdrules`.
+
+This gives you:
+- The DS-agnostic data-fetching skeleton with `// [DS RENDER]` placeholder
+- The Design System Adaptation guide (primitive mapping table, icon discovery rules)
+- All common Pega APIs used in widgets: `PCore.getDataPageUtils()`, `PCore.getMashupApi()`, `PCore.getAttachmentUtils()`, `pConn.getCaseInfo()`, etc.
+- Registration conventions
+
+> The PCore data-fetching logic is always identical regardless of design system. Only the `// [DS RENDER]` section changes per DS.
+
+Keep this context active throughout the entire generation session. Do not re-read it per component.
+
+---
+
+## Step 2 — Install and discover the design system (once)
+
+Execute **Step 3** from `.cursor/rules/prompts/add-component.mdrules` 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 `.cursor/rules/prompts/add-component.mdrules` exactly as written:
+- Read the DS README from `node_modules`
+- Discover exported components from `dist/index.d.ts`
+- Focus on presentation primitives used in widgets: Card, List, Table, Button, Badge, Spinner, Skeleton, Empty state
+- Read prop interfaces for these components from `.d.ts` files
+- If the DS has a companion icon package, discover its exports
+
+Build a **DS UI primitive reference map** from this discovery. Reuse it for every widget — do not repeat these commands per component.
+
+---
+
+## Step 3 — Overwrite check (all at once)
+
+For each component in the list, check whether `<outputPath>/<ComponentName>/<ComponentName>.tsx` already exists.
+
+If **any** exist, report them all at once and ask:
+> "The following N components already exist: [list]. 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"
+
+Wait for the user's answer before proceeding. If none exist, continue immediately.
+
+---
+
+## Step 4 — Generate each component (loop)
+
+For each component in the resolved list (in the order listed in Step 0):
+
+### 4a — Read the component-specific skill file
+Execute **Step 2** from `.cursor/rules/prompts/add-component.mdrules` for this component:
+- Read `.cursor/rules/skills/widget-skills/<ComponentName>.mdrules` fully if it exists
+- Pay attention to:
+  - **Behavioral Contract** — data fetching logic, PCore API calls, state management, action handlers
+  - **Design System Mapping** table — the recommended DS component for presentation
+- If no skill file exists (e.g., `SummaryList`), use the general data-fetching pattern from `widget-components.md`
+
+### 4b — Generate the component files
+Execute **Step 5** from `.cursor/rules/prompts/add-component.mdrules` for this component:
+- Create `<outputPath>/<ComponentName>/` directory
+- Create `<ComponentName>.tsx` using:
+  - The DS-agnostic data-fetching skeleton from `widget-components.md` (read in Step 1)
+  - The Behavioral Contract from the component skill file (PCore API calls, state, actions)
+  - The DS UI primitives confirmed in Step 2 (from the DS primitive reference map — no new terminal commands needed) filling in the `// [DS RENDER]` section
+- Create `index.tsx` if required by the skill file:
+  ```typescript
+  export { default } from './<ComponentName>';
+  ```
+- Create any CSS or utility files required by the skill file
+
+### 4c — Register the component
+Execute **Step 6** from `.cursor/rules/prompts/add-component.mdrules` for this component:
+- Add the import to `src/components/component-map.ts` in the Widgets section
+- Add the entry to `getSampleComponentMap()` under the widgets comment
+- Do not reorder or restructure any existing entries
+
+### 4d — Report progress
+After each component: "`<ComponentName>` ✓ — using `<DS card/list primitive>`"
+
+---
+
+## Step 5 — Verify the build
+
+Execute **Step 7** from `.cursor/rules/prompts/add-component.mdrules` exactly as written:
+- Run `npm run build`
+- Fix any TypeScript or build errors before reporting completion
+- Report a summary: list of all files created and all entries added to `component-map.ts`

package/templates/react-sdk-reference/.cursor/rules/prompts/identify-components.mdrules

@@ -0,0 +1,110 @@
+---
+description: identify-components.prompt
+alwaysApply: false
+---
+
+# identify-components
+
+Analyze the attached screenshot and identify which SDK components from this application are visible in the image.
+
+**Output only a single line** in this exact format — nothing else:
+
+```
+components="ComponentA,ComponentB,ComponentC"
+```
+
+This output can be pasted directly into a `/replace-design-system` invocation.
+
+---
+
+## Visual Recognition Guide
+
+Use the table below to map what you see in the image to SDK component names.
+
+### Structural / layout components
+
+| What you see | SDK component name | Category |
+|---|---|---|
+| Chevron/arrow step bar at the top of a form (e.g. "Step 1 → Step 2 → Step 3") | `Stages` | infra |
+| Full case shell: step bar + case title + **action menu (⋮ or kebab)** + tabbed content area | `CaseView` | template |
+| Row of action buttons at the bottom (Cancel / Save / Submit) | `ActionButtons` | infra |
+| White/card area wrapping form fields | `DefaultForm` | template |
+| Full-page layout with header + sidebar + content area | `AppShell` | template |
+| Left-side vertical tab navigation | `VerticalTabs` | infra |
+| Top navigation bar with logo + user menu | `NavBar` | infra |
+| Top navigation bar (WSS / self-service variant) | `WssNavBar` | template |
+| Two-column layout (equal or narrow/wide split) | `TwoColumn` / `NarrowWide` / `WideNarrow` | template |
+| Single-column stacked layout | `OneColumn` | template |
+| Tabbed panel inside a form or page | `SubTabs` / `Details` | template |
+
+### Field components
+
+| What you see | SDK component name | Category |
+|---|---|---|
+| Single-line text input box | `TextInput` | field |
+| Multi-line text input / textarea | `TextArea` | field |
+| Dropdown / select menu (chevron on right) | `Dropdown` | field |
+| Phone input with country code prefix (e.g. "+1 ▼") | `Phone` | field |
+| Date picker input (calendar icon) | `Date` | field |
+| Date + time picker input | `DateTime` | field |
+| Time-only picker | `Time` | field |
+| Currency input ($ prefix or formatted number) | `Currency` | field |
+| Percentage input (% suffix) | `Percentage` | field |
+| Decimal / float number input | `Decimal` | field |
+| Integer-only number input | `Integer` | field |
+| Email input (envelope icon or @-hint) | `Email` | field |
+| URL input (link icon or http-hint) | `URL` | field |
+| Checkbox with label | `Checkbox` | field |
+| Radio button group | `RadioButtons` | field |
+| Multi-select / tag-style select with chips | `Multiselect` | field |
+| Type-ahead / autocomplete input with suggestions | `AutoComplete` | field |
+| Rich text editor (toolbar with Bold/Italic/etc.) | `RichText` | field |
+| Read-only comma-separated list of values | `ScalarList` | field |
+| Selectable card / tile (click to select, like a plan card) | `SelectableCard` | field |
+| Map / location picker with pin icon | `Location` | field |
+| Link to another object/record | `ObjectReference` | field |
+| Hyperlink displayed inline | `SemanticLink` | field |
+| User avatar + name displayed inline | `UserReference` | field |
+| Inline alert / warning inside a form | `CancelAlert` | field |
+| Static text block / paragraph inside a form | `TextContent` | field |
+| Grouping box around related fields | `Group` | field |
+
+### Widget components
+
+| What you see | SDK component name | Category |
+|---|---|---|
+| To-do / task list card with assignments | `ToDo` | widget |
+| File attachment area with upload button | `Attachment` | widget |
+| Case history / audit trail table | `CaseHistory` | widget |
+| File list with download actions | `FileUtility` | widget |
+| List of follower avatars + "Follow" button | `Followers` | widget |
+| "+" quick-create button with dropdown menu | `QuickCreate` | widget |
+| Summary card for a single record with action menu | `SummaryItem` | widget |
+| List of SummaryItem cards | `SummaryList` | widget |
+| Announcement / news card | `AppAnnouncement` | widget |
+
+### DSE / design system extension components
+
+| What you see | SDK component name | Category |
+|---|---|---|
+| Coloured banner alert bar (info / warning / error / success) | `AlertBanner` | designSystemExtension |
+| Hero-style banner with title + CTA button | `Banner` | designSystemExtension |
+| Read-only field+value pairs in a case summary | `CaseSummaryFields` | designSystemExtension |
+| Read-only label+value pairs in a details view | `DetailsFields` | designSystemExtension |
+| Collapsible section with header (accordion-style) | `FieldGroup` | designSystemExtension |
+| List of field groups with "Add" link | `FieldGroupList` | designSystemExtension |
+| User operator info popover (name + contact) | `Operator` | designSystemExtension |
+| Comment/pulse card with avatar + timestamp | `Pulse` | designSystemExtension |
+| Rich text editor with theme-aware toolbar | `RichTextEditor` | designSystemExtension |
+| Quick-create shortcut links list (WSS sidebar) | `WssQuickCreate` | designSystemExtension |
+
+---
+
+## Rules
+
+1. **Only list components you can actually see rendered in the image.** Do not include components that might be present but are not visible (e.g. a NavBar not shown in the screenshot).
+2. **Do not include `FieldValueList`** — it is an internal rendering helper, not a visible component.
+3. **Structural components that frame a form always count** — if you see a step bar, include `Stages`; if you see action buttons, include `ActionButtons`.
+4. **An avatar + form title alone is NOT `CaseView`** — `CaseView` requires a full case shell with an action/kebab menu and tabbed content. A simple avatar + heading above a form is just part of `DefaultForm`.
+5. **When in doubt between two similar components** (e.g. `NarrowWide` vs `WideNarrow`), pick the one whose column ratio best matches the image proportions, or include both separated by a comma.
+6. **Output only the single `components="..."` line.** No explanation, no list, no markdown — just that line.