From 97536c7946c72ce6dcd31b747efb686b710ea4bd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Beno=C3=AEt=20CORTIER?= Date: Mon, 10 Aug 2026 01:35:37 +0900 Subject: [PATCH 1/4] chore(skills): clarify CI commit type Select Conventional Commit types by affected surface so automation fixes remain classified as CI changes. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --- .agents/skills/commit-and-pr-conventions/SKILL.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/.agents/skills/commit-and-pr-conventions/SKILL.md b/.agents/skills/commit-and-pr-conventions/SKILL.md index 048f6b173..53c63d85a 100644 --- a/.agents/skills/commit-and-pr-conventions/SKILL.md +++ b/.agents/skills/commit-and-pr-conventions/SKILL.md @@ -16,7 +16,10 @@ Treat the PR title and initial body as the exact commit message that squash-and- - For standalone commits, wrap body lines at 72 characters. Explain why the change was needed, how it solves it, and material side effects. - Put an existing ticket key or link in a footer, not the subject: `Issue: PROJECT-123`. Follow repository-specific footer format when an issue exists. When none exists, omit the footer rather than fabricating `Issue: N/A`. - Add applicable Conventional Commit footers and `Co-authored-by: Name ` trailers for collaborators. -- Use `fix` for bugs, `feat` for features, `build` for build or dependencies, `chore` for non-product tools or configuration, `ci` for automation, `docs` for documentation only, `style` for non-semantic edits, `refactor` for restructuring, `test` for tests, and `perf` for performance. +- Choose the type by the affected surface, not by whether the change fixes a defect. +- Use `ci` for CI, workflow, and automation changes, including fixes to that automation, and reserve `fix` for product or runtime bugs. +- Use `feat` for features, `build` for build or dependencies, `chore` for non-product tools or configuration, `docs` for documentation only, `style` for non-semantic edits, `refactor` for non-breaking restructuring, `test` for tests, and `perf` for performance. +- Use `fix`, not `refactor`, for breaking restructuring and mark the change with `!` or a `BREAKING CHANGE` footer. - Keep every non-squashed development commit coherent and conventional. ```text From 0b7ef0b6de3e04bce547b20523f854f3df06a476 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Beno=C3=AEt=20CORTIER?= Date: Mon, 10 Aug 2026 01:38:46 +0900 Subject: [PATCH 2/4] chore(skills): separate breaking marker Keep the semantic type accurate when a change is breaking and represent breakingness with its dedicated marker. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --- .agents/skills/commit-and-pr-conventions/SKILL.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.agents/skills/commit-and-pr-conventions/SKILL.md b/.agents/skills/commit-and-pr-conventions/SKILL.md index 53c63d85a..ecece2fe8 100644 --- a/.agents/skills/commit-and-pr-conventions/SKILL.md +++ b/.agents/skills/commit-and-pr-conventions/SKILL.md @@ -18,8 +18,8 @@ Treat the PR title and initial body as the exact commit message that squash-and- - Add applicable Conventional Commit footers and `Co-authored-by: Name ` trailers for collaborators. - Choose the type by the affected surface, not by whether the change fixes a defect. - Use `ci` for CI, workflow, and automation changes, including fixes to that automation, and reserve `fix` for product or runtime bugs. -- Use `feat` for features, `build` for build or dependencies, `chore` for non-product tools or configuration, `docs` for documentation only, `style` for non-semantic edits, `refactor` for non-breaking restructuring, `test` for tests, and `perf` for performance. -- Use `fix`, not `refactor`, for breaking restructuring and mark the change with `!` or a `BREAKING CHANGE` footer. +- Use `feat` for features, `build` for build or dependencies, `chore` for non-product tools or configuration, `docs` for documentation only, `style` for non-semantic edits, `refactor` for restructuring, `test` for tests, and `perf` for performance. +- Mark breaking changes with `!` or a `BREAKING CHANGE` footer without changing an otherwise accurate type. - Keep every non-squashed development commit coherent and conventional. ```text From f7374f1f1834ba1650a539421b1e108e11820af8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Beno=C3=AEt=20CORTIER?= Date: Mon, 10 Aug 2026 01:47:07 +0900 Subject: [PATCH 3/4] chore(skills): classify public API changes Distinguish externally consumed API-boundary changes from internal restructuring while preserving CI classification by affected surface. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --- .agents/skills/commit-and-pr-conventions/SKILL.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/.agents/skills/commit-and-pr-conventions/SKILL.md b/.agents/skills/commit-and-pr-conventions/SKILL.md index ecece2fe8..87daf4b67 100644 --- a/.agents/skills/commit-and-pr-conventions/SKILL.md +++ b/.agents/skills/commit-and-pr-conventions/SKILL.md @@ -17,8 +17,9 @@ Treat the PR title and initial body as the exact commit message that squash-and- - Put an existing ticket key or link in a footer, not the subject: `Issue: PROJECT-123`. Follow repository-specific footer format when an issue exists. When none exists, omit the footer rather than fabricating `Issue: N/A`. - Add applicable Conventional Commit footers and `Co-authored-by: Name ` trailers for collaborators. - Choose the type by the affected surface, not by whether the change fixes a defect. -- Use `ci` for CI, workflow, and automation changes, including fixes to that automation, and reserve `fix` for product or runtime bugs. -- Use `feat` for features, `build` for build or dependencies, `chore` for non-product tools or configuration, `docs` for documentation only, `style` for non-semantic edits, `refactor` for restructuring, `test` for tests, and `perf` for performance. +- Use `ci` for CI, workflow, and automation changes, including fixes to that automation. +- Use `fix` for product or runtime bugs and non-feature changes to externally consumed public API boundaries. +- Use `feat` for features, `build` for build or dependencies, `chore` for non-product tools or configuration, `docs` for documentation only, `style` for non-semantic edits, `refactor` for internal restructuring, `test` for tests, and `perf` for performance. - Mark breaking changes with `!` or a `BREAKING CHANGE` footer without changing an otherwise accurate type. - Keep every non-squashed development commit coherent and conventional. From 8fa97b327330506c5262a6bd3f434388a0d3fb47 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Beno=C3=AEt=20CORTIER?= Date: Mon, 10 Aug 2026 01:51:00 +0900 Subject: [PATCH 4/4] chore(agents): standardize skill scope Use the agents scope for agent instructions and reusable skills, matching the convention established in IronRDP. Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com> --- .agents/skills/commit-scope/SKILL.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/.agents/skills/commit-scope/SKILL.md b/.agents/skills/commit-scope/SKILL.md index 58f43678a..85cf17d8e 100644 --- a/.agents/skills/commit-scope/SKILL.md +++ b/.agents/skills/commit-scope/SKILL.md @@ -25,7 +25,8 @@ A shared component receives each product scope whose behavior changes. Merely bu 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`, `skills`, `dependabot`, `miri`, `tokengen`, or `dotnet-utils`; omit the scope if none helps. Prefer a precise current name over generic `tools` or `dotnet`. +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 ` pattern when cutting a release.