菜单
Select commit and PR scopes in the Devolutions Gateway repository. Use whenever composing or reviewing a Conventional Commit subject, especially for shared libraries, packaging, tests, documentation, CI, or changes spanning products.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/Devolutions/devolutions-gateway --skill commit-scope命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Review Devolutions Gateway changes against authoritative external contracts. Use when a diff may affect HTTP or OpenAPI behavior, WebSocket behavior, relay or tunneling semantics, configuration schemas, or agent and platform protocols.
Perform an evidence-driven, change-averse code review. Use when assessing the correctness, necessity, scope, or design of a proposed change.
Review Devolutions Gateway pull requests and diffs using focused contract, compression, documentation, prose, and skeptical passes. Use whenever Copilot code review is requested or a proposed change needs review.
基于 SOC 职业分类
正在显示 SKILL.md
| name | commit-scope |
| description | Select commit and PR scopes in the Devolutions Gateway repository. Use whenever composing or reviewing a Conventional Commit subject, especially for shared libraries, packaging, tests, documentation, CI, or changes spanning products. |
Choose scopes by affected deliverable, not file location or internal component.
cliff.toml; the completed subject and footers determine whether git-cliff includes the commit.| Scope | Area |
|---|---|
dgw | Devolutions Gateway service, runtime, API, configuration, or product-specific tests/docs/build logic |
installer | Devolutions Gateway installers, packages, installation behavior, or installer-specific tests/docs/build logic |
agent | Devolutions Agent services, updater, runtime, or product-specific tests/docs/build logic |
agent-installer | Devolutions Agent installers, packages, installation behavior, or installer-specific tests/docs/build logic |
jetsocat | Jetsocat runtime, packages, or product-specific tests/docs/build logic |
webapp | Anything affecting the standalone Gateway web application |
A shared component receives each product scope whose behavior changes. Merely bundling an updated runtime does not add installer or agent-installer; add those scopes only when installation or packaging behavior changes. Do not use internal component names such as jmux or pedm: JMUX changes commonly affect dgw,jetsocat; PEDM changes commonly affect agent and sometimes agent-installer.
For included commits, use only product scopes. Scopes containing openapi, npm, nuget, dotnet-*, or ts-* cause git-cliff to suppress the entry. The deps scope suppresses only exact chore(deps) and build(deps) subjects; do not use it with other included types or as part of a broader scope.
Scopes are more flexible when git-cliff excludes the commit, whether by type, scope, or Changelog: ignore. Keep the semantic type: an npm package feature may use feat(npm): ... because the scope suppresses it. For chore, ci, style, refactor, and test, use a concise target when useful, such as openapi, deps, toolchain, package, agents, dependabot, miri, tokengen, or dotnet-utils; omit the scope if none helps. Prefer a precise current name over generic tools or dotnet.
Use agents for agent instructions and reusable skills.
Use the established chore(release): prepare for <version> pattern when cutting a release.
For multiple products, separate scopes with commas and no spaces in this order: dgw,installer,agent,agent-installer,jetsocat,webapp.
Examples:
fix(dgw,agent): ...perf(dgw,jetsocat): ...feat(webapp): ...feat(dgw): ...feat(npm): ...chore(openapi): ...chore(release): prepare for 2026.3.0