القائمة
Create a new design system component
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when building or scoping a screen, page, or feature with the Government of Alberta Design System starting from a user-facing intent ("worker tool for case management", "public form for licence renewal", "error page for payment failure") rather than from a specific component or token.
Use when adding a PR playground test page for a bug fix or feature in apps/prs. Covers the React and Angular wiring, which differ. Every PR needs BOTH a React and an Angular page so reviewers can verify the change in each framework.
Use to answer questions about the Government of Alberta Design system evolution, including approved terminology, the migration timeline and support windows, version changes for Web components, Angular, and React, and what the change means for product teams. Source of truth for evolution terms, FAQs, and glossary definitions.
Use when opening a pull request for a fix or feature in GovAlta/ui-components. Covers rebasing onto latest dev (to avoid stale-branch CI failures), filling the PR template, the draft-and-do-not-mark-ready convention, and commit and PR message style.
Use when writing or revising longer-form content for the Design system website, including component and pattern documentation, usage guidance, how-to steps, release notes, and FAQ-style explanations. Enforces plain-language voice, mechanics, inclusive language, and approved terminology. Do not use for in-component microcopy or code.
Use when filing a new GitHub issue for the Design system (bug, feature, or task). Covers the title and body template, the required priority and component labels, and setting the issue Type via GraphQL rather than a label. Do not use for writing PR descriptions.
| name | create-component |
| description | Create a new design system component |
To create a new component you will have to use the following steps:
libs/web-components/src/components/{component-name}/{ComponentName}.svelte (use kebab-case for the folder name and PascalCase for the file name)libs/web-components/src/index.tslibs/react-components/src/lib/{component-name}/{component-name}.tsx (use kebab-case for the folder name and file name)libs/react-components/src/lib/{component-name}/{component-name}.test.ts with tests for passing values to the web-component and receiving events from the web-componentlibs/react-components/src/index.tslibs/angular-components/src/lib/components/{component-name}/{component-name}.ts (use kebab-case for the folder name and file name)libs/angular-components/src/lib/components/{component-name}/{component-name}.test.ts with tests for passing values to the web-component and receiving events from the web-componentlibs/angular-components/src/lib/components/index.tslibs/web-components/src/components/{component-name}/{ComponentName}.spec.tslibs/react-components/specs/{component-name}.browser.spec.tsxdocs/src/content/components/{component-name}.mdxdocs/src/data/configurations/{component-name}.tsMake sure to follow the rules including component-authoring, common-utilities, testing, framework-wrappers when creating the component and its tests.create-playground-page.
Create the playground pages for the component using the create-playground-page skill.
All behaviour and logic should be in the Svelte web-component, the React and Angular framework wrappers should be as thin as possible. The framework wrappers should not contain any logic, and should only pass props/events to/from the web-component.