菜单
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.
用 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 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 | open-pr |
| description | 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. |
Rebase before opening the PR, and before every subsequent push. A branch that has fallen behind dev fails CI checks (for example Docs Freshness) even when the diff is correct.
git fetch origin
git rebase origin/dev
Resolve conflicts, re-run the relevant tests, then push.
One fix or feature per PR, ideally one commit. Amend or squash follow-ups rather than stacking noise.
Commit message: fix(#{N}): short imperative description (or feat(#{N}): ..., chore(#{N}): ...). Include the issue number. The branch name does not need the issue number.
Fixes #{N} in the body so the issue closes on merge.create-playground-page skill).Open the PR in draft state. Do not mark it ready for review. The person who owns the work verifies the diff and marks it ready themselves.
If gh is unavailable, push the branch and report that the PR must be opened manually.
No em dashes or en dashes anywhere in the commit message or PR body. Use periods, commas, or colons.