メニュー
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.
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 | write-issue |
| description | 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. |
Use when creating a GitHub issue in GovAlta/ui-components. The goal is an issue another contributor (or their Claude session) can pick up cold, with no missing scope.
Format: {Component}: {short imperative description of the problem}.
Examples: Button: does not take full width inside ButtonGroup on mobile, DatePicker: month dropdown shows raw value instead of placeholder.
Keep it specific. Avoid vague titles like "Button bug" or "fix styling".
Use these sections, in order:
The body is the source of truth for scope. If a value is unknown (a token name, a colour), say so explicitly and flag it as a question rather than inventing one.
Every issue needs:
P3). Set it from the team's backlog scoring, not by gut feel.Button, DatePicker).The bug / feature / task distinction is the issue Type, not a label (see below).
The issue Type (Bug, Feature, Task) is a GitHub project field, not a label. Setting a bug label does not set the Type. Use the GraphQL API:
# 1. Find the type id for the repo
gh api graphql -f query='
query { repository(owner:"GovAlta", name:"ui-components") {
issueTypes(first:10) { nodes { id name } } } }'
# 2. Apply it to the issue (look up the issue node id first with gh issue view)
gh api graphql -f query='
mutation($issue:ID!, $type:ID!) {
updateIssueIssueType(input:{issueId:$issue, issueTypeId:$type}) {
issue { number issueType { name } } } }' \
-f issue=<ISSUE_NODE_ID> -f type=<TYPE_NODE_ID>