菜单
Writing tests and specs for components
用 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.
Create a new design system component
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.
| name | writing-specs |
| description | Writing tests and specs for components |
When writing specs always favour using getByTestId to locate elements, unless it is expected that the element will not exist, in which case queryByTestId should be used. This is because getByTestId will throw an error if the element is not found, which is useful for ensuring that the element exists before proceeding with further assertions.
