@pega/sdk 0.0.4 → 0.0.6

package/templates/react-sdk-reference/.ai-common/prompts/generate-all-components.md

@@ -0,0 +1,358 @@
+---
+ai-description: Generate components across multiple types (field, template, widget, designSystemExtension) using any design system
+---
+
+## 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`)
+- **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, you MUST stop and ask the user before proceeding. Do not infer any value from the project structure, `{{AI_FILE_EXT}}` 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.
+
+### Component type scope
+
+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 |
+
+Default to **all four types** if the message does not restrict the scope.
+
+### Derived output paths
+
+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/`                |
+| designSystemExtension | `<base>/designSystemExtension/` |
+
+Once design system, base folder, and type scope are resolved, continue to Step 1.
+
+---
+
+## Step 1 — Read general skill files (once, for each type in scope)
+
+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                 | `{{SKILL_DIR}}/field-components.md`        |
+| template              | `{{SKILL_DIR}}/template-components.md`     |
+| widget                | `{{SKILL_DIR}}/widget-components.md`       |
+| designSystemExtension | `{{SKILL_DIR}}/design-system-extension.md` |
+
+Keep all loaded skill files active throughout the entire session.
+
+---
+
+## Step 2 — Install and discover the design system (once)
+
+Check the project's dependency manifest to determine whether the design system package is already installed. If it is **not** listed in the project's dependencies, install it using the project's package manager. Report what was installed.
+
+**Immediately after installation**, read `node_modules/<designSystem>/README.md` in full. From it, note the correct import paths, usage patterns, version-specific guidance, global CSS/styles import path, provider wrapper component name, and any peer dependency requirements. Store this information in your memory and use it for all subsequent steps — do not re-read the README later. If the README lists peer dependencies that are not already installed in the project, install them now — the design system will not function correctly without them.
+
+You MUST also thoroughly inspect the installed design system package:
+
+1. **Discover all available components** — browse the installed package's directory tree under `node_modules/<designSystem>/` to find every component it exports. Do not assume a specific folder structure (e.g. `dist/`) — packages vary widely in how they organize source, types, and entry points. Navigate through the package's folders, read its entry-point files and type definitions, and build a complete list of every component the package actually provides. Store all discovered component names and their import paths in your memory for reference during code generation.
+2. **Map each requested component to the best available DS component** — component names from the skill files may not have an exact name match in the installed design system. Using the complete component list you just discovered, identify which DS component best serves the same purpose. For example, `@carbon/react` does not export an `AutoComplete` component — but it does export `ComboBox`, which provides equivalent autocomplete/typeahead functionality. If no single DS component is a close match, compose the requested behavior from multiple available DS primitives. Never fabricate a component import that does not exist in the installed package.
+3. **Read the props interface of every component you plan to use** — for each component you intend to use, locate and read its TypeScript type definitions (`.d.ts` files or inline types) to understand the exact prop names, types, required vs. optional status, and any relevant enums or union types. Store this information in your memory alongside the component names.
+4. **Use ONLY confirmed component names and prop names** — when generating code, you must exclusively use the component names and prop names you discovered from the installed package. Do not rely on training knowledge of the design system's API, as it may be outdated, inaccurate, or refer to components/props that do not exist in the installed version.
+
+Also check:
+
+- Whether the design system 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 a **tokens or CSS directory** — use design system CSS custom properties for spacing; never hardcode `px` values
+
+### 2.1 — Install the DS styles package and configure global CSS (MANDATORY)
+
+Design systems require their global stylesheet — without it, components render unstyled.
+
+#### Known DS style requirements (examples — verify against the README you already read):
+
+| Design System | Styles Package (example) | CSS Import (example)                     | Provider Wrapper (example) |
+| ------------- | ------------------------ | ---------------------------------------- | -------------------------- |
+| Carbon        | `@carbon/styles`         | `import '@carbon/react/css/styles.css';` | `<Theme>`                  |
+| Ant Design    | (included)               | `import 'antd/dist/reset.css';`          | `<ConfigProvider>`         |
+| Radix Themes  | `@radix-ui/themes`       | `import '@radix-ui/themes/styles.css';`  | `<Theme>`                  |
+| Chakra UI     | (included)               | (none — runtime)                         | `<ChakraProvider>`         |
+| Shadcn/ui     | (Tailwind)               | `import './globals.css';`                | None                       |
+| MUI           | (included)               | (none — CSS-in-JS)                       | `<ThemeProvider>`          |
+
+Above mentioned are **examples** based on common versions. Use the import path and provider name you noted from the README — they take precedence over this table.
+
+If in table and not already configured: install styles package (if separate), add the global CSS import as the **first import** in the application's entry file, and add the Provider wrapper in the application's providers file.
+If not in table: browse the installed design system's folder in `node_modules` for a `styles/` or `dist/` directory containing CSS files, and use what you find there.
+
+Since you have already read the design system's README, install the styles package it specifies (if any). If you have already installed it, skip this step. If the README did not provide enough detail about design-system-specific styles, browse the `styles/` folder within the installed design system package to locate the correct stylesheet and understand how it should be applied. Ensure these design system styles are applied globally so that all generated components render correctly.
+
+Before implementing any component, verify whether design-system-specific styles are already configured in the existing codebase — check the application's entry file for a matching CSS import. If the styles are already imported and configured, skip this step and report "already configured".
+
+Report what was installed/configured (or "already configured").
+
+Keep all DS discovery information active throughout the entire session. Reference it whenever generating a component — do NOT re-run discovery per component.
+
+---
+
+## Step 3 — Overwrite check (all types, all at once)
+
+For every type in scope, check whether each component's file or directory already exists at the derived output path.
+
+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"
+
+Wait for the user's answer before proceeding. If none exist, continue immediately.
+
+⚠️ **This decision is final for the entire session.** Do NOT re-check file existence or re-ask this overwrite question during Steps 4–7. When you encounter a component file that already exists during generation, silently apply the decision made here (overwrite it or skip it) without prompting again. This applies even after retries, transport errors, or subagent restarts — the user's answer here governs all subsequent component generation in this conversation.
+
+---
+
+## Step 4 — Generate field components (skip if field not in scope)
+
+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 `{{SKILL_DIR}}/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 the component's main implementation file using the file naming convention and extension appropriate to the project's framework (determine this by examining existing components in the project).
+
+Follow the implementation structure described in `field-components.md` (loaded in Step 1). That file specifies the exact imports, interface, props destructuring, display mode guards, event handling, and render approach for this project's framework. Use the DS component you identified in Step 2 as the primary input element.
+
+If the component-specific skill file exists, also incorporate its Behavioral Contract (validation rules, option loading, event sequences, edge cases).
+
+If the project uses barrel/re-export files (check existing component directories for the convention), create one in the same directory following the same pattern.
+
+### 4.3 — Register the component
+
+Open the project's component map file (the file that maps component names to their implementations) and:
+
+1. Add an import at the top in the **Fields** section
+2. Add an entry in the component map object under the fields comment
+
+⚠️ **Key name exceptions for fields** — these MUST use explicit key mapping (Pega sends a name that differs from the JS variable):
+
+- `Date: DateField` (not `DateField,`)
+- `URL: URLComponent` (not `URLComponent,`)
+- `Checkbox: CheckboxComponent` (if your variable name differs from `Checkbox`)
+
+### 4.4 — 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, 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 `{{SKILL_DIR}}/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 the component's main implementation file using the file naming convention and extension appropriate to the project's framework.
+
+Follow the implementation structure described in `template-components.md` (loaded in Step 1). That file specifies the layout, form, and page patterns — including how to render child components — for this project's framework.
+
+Apply the Behavioral Contract from the component skill file (sub-variants, region handling, slot rendering logic).
+
+If the project uses barrel/re-export files, create one in the same directory. Also create any CSS file required by the skill file.
+
+### 5.2.1 — Create sub-variant files (MANDATORY for Layout templates)
+
+⛔ **Do NOT skip this step.** Without sub-variants, portal pages and tabs won't render column layouts.
+
+After generating **TwoColumn**, **OneColumn**, **NarrowWide**, or **WideNarrow**, you MUST immediately create these additional files in the same directory:
+
+| Base template | Sub-variant files to create                             |
+| ------------- | ------------------------------------------------------- |
+| TwoColumn     | `TwoColumnPage`, `TwoColumnTab`                         |
+| OneColumn     | `OneColumnPage`, `OneColumnTab`                         |
+| NarrowWide    | `NarrowWideForm`, `NarrowWidePage`                      |
+| WideNarrow    | `WideNarrowDetails`, `WideNarrowForm`, `WideNarrowPage` |
+
+Each sub-variant is a one-line passthrough that delegates to the base component via the project's component registry. It retrieves the base component (e.g. `TwoColumn`) from the registry and renders it with all props forwarded. Follow the same file extension and module pattern used by the rest of the project.
+
+### 5.3 — Register the component
+
+Open the project's component map file and:
+
+1. Add an import at the top in the **Templates** section
+2. Add an entry in the component map object under the templates comment
+3. **Also import and register ALL sub-variant files** created in Step 5.2.1. Each sub-variant gets its own import and its own entry in the map.
+
+### 5.4 — 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, 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 `{{SKILL_DIR}}/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 props type
+
+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 the component's main implementation file using the file naming convention and extension appropriate to the project's framework.
+
+Follow the implementation structure described in `widget-components.md` (loaded in Step 1). That file specifies the imports, interface, data-fetching lifecycle, and render approach for this project's framework. Use the DS components you identified in Step 2 for presentation.
+
+The data-fetching logic comes from the skill file's Behavioral Contract — do NOT invent API calls. Fill in the presentation layer with DS primitives confirmed in Step 2.
+
+If the project uses barrel/re-export files, create one in the same directory. Also create any CSS or utility files required by the skill file.
+
+### 6.3 — Register the component
+
+Open the project's component map file and:
+
+1. Add an import at the top in the **Widgets** section
+2. Add an entry in the component map object under the widgets comment
+
+⚠️ **Key name exception for widgets** — this MUST use explicit key mapping:
+
+- `Todo: ToDo` (not `ToDo,`) — Pega engine sends `Todo` (lowercase 'odo'), not `ToDo`
+
+### 6.4 — 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, 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 `{{SKILL_DIR}}/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 the component's main implementation file using the file naming convention and extension appropriate to the project's framework.
+
+Follow the implementation structure described in `design-system-extension.md` (loaded in Step 1). That file specifies the pattern variants (pure display, PConnect display, complex display) for this project's framework.
+
+Apply the Behavioral Contract from the component skill file (prop handling, variant mapping, rendering logic, edge cases).
+
+If the project uses barrel/re-export files, create one in the same directory. Also create any CSS file required by the skill file.
+
+### 7.3 — Register the component
+
+Open the project's component map file and:
+
+1. Add an import at the top in the **Design System Extension** section
+2. Add an entry in the component map object under the DSE comment
+
+### 7.4 — Report progress
+
+After each component: "`<ComponentName>` ✓ — Pattern `<B/A/C>`"
+
+---
+
+## Step 8 — Verify the build
+
+Run the project's build process to confirm everything compiles without errors. Fix any TypeScript or build errors before reporting completion.
+
+### 8.1 — Validate component map key names
+
+After a clean build, verify these key name exceptions in the component map:
+
+- [ ] `Date: DateField` (not `DateField,`)
+- [ ] `URL: URLComponent` (not `URLComponent,`)
+- [ ] `Todo: ToDo` (not `ToDo,`)
+
+These are cases where the Pega engine sends a component name that differs from the JavaScript variable name. If any are registered using shorthand (e.g., `ToDo,`), fix them to use explicit key mapping (e.g., `Todo: ToDo,`).
+
+Report a final summary:
+
+- Total components generated, grouped by type
+- All entries added to the component map
+- Any components skipped (if "skip existing" was chosen in Step 3)

package/templates/react-sdk-reference/.ai-common/prompts/generate-dse-components.md

@@ -0,0 +1,165 @@
+---
+ai-description: Generate all (or a subset of) design system extension components using any design system
+---
+
+## 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, you MUST stop and ask the user before proceeding. Do not infer any value from the project structure, `{{AI_FILE_EXT}}` files, existing folders, or any other source.
+
+⛔ **STOP** — If the user's message does not explicitly state BOTH the design system AND the output path, 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. 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 `{{SKILL_DIR}}/design-system-extension.md`.
+
+This gives you:
+
+- All three implementation patterns (Pure display, Field value display, Complex display with PConnect)
+- 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.
+
+> 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.
+
+---
+
+## Step 2 — Install and discover the design system (once)
+
+Check the project's dependency manifest to determine whether the design system package is already installed. If it is **not** listed in the project's dependencies, install it using the project's package manager. Report what was installed.
+
+**Immediately after installation**, read `node_modules/<designSystem>/README.md` in full. From it, note the correct import paths, usage patterns, version-specific guidance, global CSS/styles import path, provider wrapper component name, and any peer dependency requirements. Store this information in your memory and use it for all subsequent steps — do not re-read the README later. If the README lists peer dependencies that are not already installed in the project, install them now — the design system will not function correctly without them.
+
+You MUST also thoroughly inspect the installed design system package, focusing on display primitives (Alert, Card, Avatar, Badge, Tag, Notification) since only Pattern B components consume DS primitives:
+
+1. **Discover all available display primitives** — browse the installed package's directory tree under `node_modules/<designSystem>/` to find every component it exports. Do not assume a specific folder structure (e.g. `dist/`) — packages vary widely in how they organize source, types, and entry points. Navigate through the package's folders, read its entry-point files and type definitions, and build a complete list of every display primitive the package actually provides. Store all discovered component names and their import paths in your memory for reference during code generation.
+2. **Map each Pattern B component to the best available DS primitive** — component names from the skill files may not have an exact name match in the installed design system. Using the complete list you just discovered, identify which DS primitive best serves the same purpose (e.g. an alert/notification primitive for AlertBanner). If no single DS component is a close match, compose the requested behavior from multiple available DS primitives. Never fabricate a component import that does not exist in the installed package.
+3. **Read the props interface of every primitive you plan to use** — for each component you intend to use, locate and read its TypeScript type definitions (`.d.ts` files or inline types) to understand the exact prop names, types, required vs. optional status, and any relevant enums or union types. Pay special attention to **variant/type/severity prop names** — each DS uses different names for alert severity (e.g., `type`, `status`, `severity`, `variant`). Store this information in your memory alongside the component names.
+4. **Use ONLY confirmed component names and prop names** — when generating code, you must exclusively use the component names and prop names you discovered from the installed package. Do not rely on training knowledge of the design system's API, as it may be outdated, inaccurate, or refer to components/props that do not exist in the installed version.
+
+### 2.1 — Install the DS styles package and configure global CSS (MANDATORY)
+
+Design systems require their global stylesheet — without it, components render unstyled.
+
+#### Known DS style requirements (examples — verify against the README you already read):
+
+| Design System | Styles Package (example) | CSS Import (example)                     | Provider Wrapper (example) |
+| ------------- | ------------------------ | ---------------------------------------- | -------------------------- |
+| Carbon        | `@carbon/styles`         | `import '@carbon/react/css/styles.css';` | `<Theme>`                  |
+| Ant Design    | (included)               | `import 'antd/dist/reset.css';`          | `<ConfigProvider>`         |
+| Radix Themes  | `@radix-ui/themes`       | `import '@radix-ui/themes/styles.css';`  | `<Theme>`                  |
+| Chakra UI     | (included)               | (none — runtime)                         | `<ChakraProvider>`         |
+| Shadcn/ui     | (Tailwind)               | `import './globals.css';`                | None                       |
+| MUI           | (included)               | (none — CSS-in-JS)                       | `<ThemeProvider>`          |
+
+Above mentioned are **examples** based on common versions. Use the import path and provider name you noted from the README — they take precedence over this table.
+
+If in table and not already configured: install styles package (if separate), add the global CSS import as the **first import** in the application's entry file, and add the Provider wrapper in the application's providers file.
+If not in table: browse the installed design system's folder in `node_modules` for a `styles/` or `dist/` directory containing CSS files, and use what you find there.
+
+Before implementing any component, verify whether design-system-specific styles are already configured in the existing codebase — check the application's entry file for a matching CSS import. If the styles are already imported and configured, skip this step and report "already configured".
+
+Report what was installed/configured (or "already configured").
+
+Keep all DS discovery information active throughout the entire session. Reference it whenever generating a component — do NOT re-run discovery per component.
+
+---
+
+## Step 3 — Overwrite check (all at once)
+
+For each component in the list, check whether the component's file or directory already exists at the output path.
+
+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 (MANDATORY — do not skip)
+
+Read the file `{{SKILL_DIR}}/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 file (`design-system-extension.md`) provides the pattern skeletons. The component-specific skill file provides the **exact prop interface, variant logic, and edge cases**. Both are needed — generating from only the general skill will produce components that render empty or with incorrect variant handling.
+
+### 4b — Generate the component files
+
+Create the directory `<outputPath>/<ComponentName>/`.
+
+Create the component's main implementation file using the file naming convention and extension appropriate to the project's framework (determine this by examining existing components in the project).
+
+Follow the implementation structure described in `design-system-extension.md` (loaded in Step 1) for the component's pattern classification — B (Pure display), A (PConnect display), or C (Complex display) — as identified in Step 4a. That file specifies the framework-specific approach for each pattern. Pattern B components should use the DS display primitive you identified in Step 2.
+
+Apply the Behavioral Contract from the component skill file (exact props, variant logic, edge cases).
+
+If the project uses barrel/re-export files (check existing component directories for the convention), create one in the same directory following the same pattern. Create any CSS file required by the skill file.
+
+### 4c — Register the component
+
+Open the project's component map file (the file that maps component names to their implementations) and:
+
+1. Add an import at the top of the file in the **Design System Extension** section
+2. Add an entry in the component map object 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
+
+Run the project's build process to confirm everything compiles without errors. Fix any build errors before reporting completion. Report a summary: list of all files created and all entries added to the component map.