菜单
Decide the correct change kind and semantically align branch names, PR titles, commit prefixes, and PR template types. Use when choosing Conventional Commit or branch prefixes for fix, refactor, chore, docs, feat, perf, test, or CI changes.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Turn a HardwareVisualizer maintainer correction, repeated failure, surprising invariant, or costly investigation into an evidence-backed learning record and the right durable guardrail. Use when asked to record learnings, prevent the same AI mistake, update AGENTS/rules/hooks/skills, or when completed work reveals a reusable repository-specific lesson.
Review or shape HardwareVisualizer product and architecture changes against the maintainer's design principles. Use when planning, implementing, or reviewing behavior that affects hardware availability, collection cost, live/history semantics, settings, persistence, user selection, Core/App ownership, optional components, privacy, or user-visible evidence.
Triage and optionally address AI-generated GitHub PR review feedback from Copilot, CodeRabbit, or similar bots. Use when the user asks to check AI review comments, decide whether comments require action, ignore non-actionable suggestions, fix required/should-fix/worth-fixing feedback, or summarize bot review findings on a pull request.
| name | change-kind-naming |
| description | Decide the correct change kind and semantically align branch names, PR titles, commit prefixes, and PR template types. Use when choosing Conventional Commit or branch prefixes for fix, refactor, chore, docs, feat, perf, test, or CI changes. |
Before committing, pushing, or opening a PR, classify the actual change type and make these four surfaces agree semantically under the repository's allowed branch prefixes:
If they disagree, stop and fix the naming before publishing.
Use fix only when the change corrects externally observable broken behavior, user-facing wrong output, a failing workflow, data loss, security exposure, or a regression.
Use refactor when the change preserves behavior but improves internal structure, terminology, names, boundaries, generated bindings, or code organization.
Use feat when the change adds a new user-visible capability or supported workflow.
Use docs when the shipped code behavior does not change and the diff is documentation-only.
Use test when the diff only adds or changes tests.
Use ci when the diff only changes CI/CD automation.
Use chore for maintenance that is not product behavior, architecture, docs, tests, or CI.
Prefer fix over refactor when the old state caused a real user or integration failure.
Prefer refactor over fix when the old state was confusing, inconsistent, or poorly named but still worked.
Prefer feat over refactor when users can now do something they could not do before.
Prefer docs over refactor when only docs changed, even if the docs clarify architecture.
Prefer the highest-impact type when one PR intentionally mixes types. If the mixed change is accidental, split it.
Use branch prefixes that match the final classification:
feat/...feature/...fix/...docs/...perf/...refactor/...chore/...This repository's CI does not allow test/... or ci/... branches. For a
test-only or CI-only change, use a chore/... branch while keeping the more
precise test: or ci: Conventional Commit and PR title. Select Other in the
PR template. Alignment is semantic here; it does not require the branch and
commit prefix strings to be identical.
Do not use:
test/...ci/...codex/...claude/...In repositories that define branch rules, such as this repository's
CONTRIBUTING.md, the repository rule wins over generic agent defaults.
Never use tool-dependent prefixes such as codex/... or claude/...
when the project requires change-kind branch prefixes.
Use the same Conventional Commit prefix in the commit subject and PR title:
refactor: rename hardware archive retention setting
In the PR template, check the matching Type of Change. Do not leave Bug fix checked for a refactor: PR.
Run this before git commit, git push, or gh pr create:
fix.refactor.Renaming refreshIntervalDays to retentionDays while preserving compatibility is refactor, not fix, because the old setting worked but used misleading terminology.
Use:
refactor/hardware-archive-retention-namingrefactor: rename hardware archive retention settingrefactor: rename hardware archive retention settingRefactoring