菜单
Write commit messages and PR titles that follow the Conventional Commits standard. Use when committing changes, drafting a commit message, squashing, or naming a pull request, and you need the correct type(feat/fix/docs/...), scope, breaking-change marker, and imperative subject line.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Manage agent skills with gh skill. Use this skill to discover, preview, install, update, and publish Agent Skills so an agent can self-manage the skills available in its environment.
Patterns for invoking the GitHub CLI (gh) from agents. Use when the task mentions GitHub, gh, pull requests/PRs, issues, releases, gists, Actions/workflow runs, forks, repo cloning, reviews, or you need exact gh commands. Covers structured output, pagination, repo targeting, search vs list, issue types/sub-issues/discussions, projects, rulesets, and gh api fallback.
Token-frugal, multi-dimension code review for a diff/branch/PR. Use when reviewing changes, checking a PR, running a review→fix loop, or the task mentions "code review", "review my changes", "review this PR", "找 bug", "审查代码". Scales review depth to diff size, reports findings by dimension and severity, and calibrates against the project's threat model to avoid severity inflation. Reports findings; never rewrites code unless explicitly asked.
Run a lightweight, spec-driven change workflow — capture WHY/WHAT in a proposal, define WHAT the system does in specs, decide HOW in a design, break work into a tasks checklist, implement, then archive. Use when the task is a non-trivial feature or behavior change that benefits from durable, git-tracked planning artifacts, or when the request mentions "spec", "proposal", "propose a change", "spec-driven", "openspec", "design doc", "requirements", or "tasks checklist". Not for one-line fixes or pure Q&A.
Structured workflow for complex/heavy tasks that benefit from a review-gated, phased approach. Use when the task involves 3+ files, a major refactor, or architectural changes — or when the task mentions "deep work", "complex refactor", "multi-phase", "staged rollout". Creates durable artifacts (plan, verify, report) so the orchestrator can track progress across sessions.
Review recent work to identify recurring friction and propose minimal, durable improvements to the opencode config (agents, skills, commands, rules). Use when the user says "reflect", "what can we improve", "review our setup", "optimize the config", or after a series of related sessions reveals a pattern worth codifying.
| name | conventional-commits |
| description | Write commit messages and PR titles that follow the Conventional Commits standard. Use when committing changes, drafting a commit message, squashing, or naming a pull request, and you need the correct type(feat/fix/docs/...), scope, breaking-change marker, and imperative subject line. |
| license | MIT |
| compatibility | opencode |
| metadata | {"audience":"developers","workflow":"git"} |
Produce commit messages and PR titles in the Conventional Commits format so history stays machine-readable and changelogs/version bumps can be automated. Spec: https://www.conventionalcommits.org
<type>(<optional scope>): <imperative subject>
<optional body — what changed and why, wrapped at ~72 cols>
<optional footer(s) — BREAKING CHANGE:, Closes #123, Co-authored-by:>
| Type | Use for | SemVer |
|---|---|---|
feat | a new user-facing feature | minor |
fix | a bug fix | patch |
docs | documentation only | — |
style | formatting/whitespace, no behavior change | — |
refactor | code change that neither fixes a bug nor adds a feat | — |
perf | performance improvement | patch |
test | adding or fixing tests | — |
build | build system or dependencies | — |
ci | CI configuration and scripts | — |
chore | maintenance that doesn't touch src or tests | — |
revert | reverts a previous commit | — |
feat(parser): ....! after the type/scope and/or a
BREAKING CHANGE: footer explaining the migration.Closes #42), not the subject.feat(auth): add OAuth2 device-code login flow
fix(api): guard against null user before serializing
docs: clarify skill auto-discovery paths in README
refactor(orchestrator)!: drop legacy qwen routing table
BREAKING CHANGE: the `qwen3.7-max` route is removed; callers must
use the deepseek-v4 tiers instead.
For a tiny one-file tweak, a single-line type: subject is enough — a body is
only needed when the why isn't obvious from the diff. Match the repository's
existing commit style if it already follows a different but consistent convention.
Before proposing a format, check the repo's recent history:
git log --oneline -20 # see actual commit style in use
If the repo uses a different convention (e.g., [fix] subject or module prefixes
like auth: subject), follow the existing style — not the spec.