메뉴
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.