@sigitcode-old / sigit / commits / c89d35e
Fork 1

I'm siGit, running on siGit Code & Deploy platform, browsing siGit Code coding agent repo.

Restructure release skill into full-release and scoped-patch flows

Replace the single development-based release flow with two explicit flows under one Git release flow heading: a full release cut from development, and a scoped patch cut from the last tag that merges release/v<version> directly into main (never development -> main) with a scope audit. Remove the older redundant standalone scoped-patch section, and reconcile the release checklist into a two-bullet full/scoped form. Co-Authored-By: siGit Code v1.6.7-acp <noreply@sigit.si>

Seto Elkahfi committed Oct 12, 2026 at 15:14 UTC c89d35e4a3333a5c43c8c19f56d45c265f466b87
1 file changed +39 -3
.agents/skills/sigit-code-release/SKILL.md
+39 -3
@@ -43,7 +43,13 @@ Use this skill when preparing a release for this repository.
43
44 ## Git release flow
45
46 -Releases are cut from `development` and shipped on `main`. The published tags (`v1.2.0`, `v1.2.1`) point at the `main`-side merge commit, never at a release branch or at `development`. Follow this order:
46 +Releases are shipped on `main`, and the published tags (`v1.2.0`, `v1.2.1`) point at the
47 +`main`-side merge commit, never at a release branch or at `development`. There are two flows,
48 +and picking the wrong one ships the wrong set of commits. Decide first which this is.
49 +
50 +### Full release (minor/major — ships everything on `development`)
51 +
52 +Cut from `development` when the release is meant to carry all the work that has accumulated there.
53
54 1. Branch `release/v<version>` off `development`.
55 2. Apply the version bump and changelog edits, then commit (e.g. `Release v<version>`).
@@ -51,10 +57,38 @@ Releases are cut from `development` and shipped on `main`. The published tags (`
57 4. Merge `development` into `main` (commit message: `Merge development into main for v<version> release`).
58 5. Tag `v<version>` on that `main` merge commit, then push `main` and the tag.
59
54 -Step 4 is the only way commits are meant to reach `main`. A feature or fix PR targeting `main` breaks that: it puts work on the release branch that `development` does not have, so the next release is cut without it. Such PRs belong on `development` (see the pull request target rule in `AGENTS.md`).
60 +For a full release, step 4 is the only way commits are meant to reach `main`. A feature or fix
61 +PR targeting `main` breaks that: it puts work on the release branch that `development` does not
62 +have, so the next release is cut without it. Such PRs belong on `development` (see the pull
63 +request target rule in `AGENTS.md`).
64 +
65 +### Scoped patch (hotfix — ships only specific fixes on top of the last tag)
66 +
67 +Use this when the patch must ship **only** a named set of fixes on top of the last released tag,
68 +**not** the unreleased work sitting on `development` (e.g. a patch over `v1.6.7` that must carry
69 +just a winget/Windows hotfix while ACP features stay unreleased). The giveaway is wording like
70 +"scoped patch off `v<prev>`" or "hotfix" — if `development` is far ahead, a `development → main`
71 +merge would drag all of it out under a patch tag, which is wrong.
72 +
73 +1. Branch `release/v<version>` off the **last released tag** (`v<prev>`), not `development`.
74 +2. Cherry-pick (or commit) only the in-scope fixes, then the version bump + changelog, and commit
75 + (e.g. `Release v<version>`).
76 +3. Merge `release/v<version>` back into `development` so the bump and changelog carry forward.
77 +4. Merge `release/v<version>` **directly into `main`** (commit message: `Release v<version>`) —
78 + **never `development → main` for a scoped patch**, since that would pull `development`'s
79 + unreleased work onto `main`.
80 +5. Tag `v<version>` on that `main` merge commit, then push `main` and the tag.
81 +
82 +Before tagging a scoped patch, audit the scope: `git log --oneline v<prev>^{commit}..main` and
83 +`git diff --stat v<prev>^{commit}..main` must show only the intended fixes and the release
84 +metadata files (`Cargo.toml`, `Cargo.lock`, `CHANGELOG.md`), nothing from `development`.
85
86 Pushing the `v*.*.*` tag is what fires every release workflow, so create and push it only after the merge into `main` has landed. Do not commit, tag, or push until the user explicitly asks — confirm the version and that they want the release to go out first.
87
88 +Decide up front which flow you are in and confirm the exact scope with the user. If in doubt about
89 +whether a release ships everything on `development` or only a scoped set of fixes, ask — the two
90 +flows start from different base commits and are not interchangeable.
91 +
92 ## Typical files to inspect
93
94 - `Cargo.toml`
@@ -79,7 +113,9 @@ Pushing the `v*.*.*` tag is what fires every release workflow, so create and pus
113 - `npm/sigit/package.json` is left at `0.0.0-dev` unless the packaging flow itself changed.
114 - `pypi/pyproject.toml` still uses dynamic versioning unless there is a deliberate packaging change.
115 - Release workflows still derive their version from the tag as expected.
82 -- Git flow followed: bump committed on `release/v<version>`, merged back to `development`, then `development` merged into `main`, with `v<version>` tagged on the `main` merge commit.
116 +- Correct git flow for the release type followed, with `v<version>` tagged on the `main` merge commit either way:
117 + - **Full release:** bump committed on `release/v<version>` (off `development`), merged back to `development`, then `development` merged into `main`.
118 + - **Scoped patch:** `release/v<version>` branched off the last tag `v<prev>`, in-scope fixes + bump committed, merged back to `development`, then `release/v<version>` merged **directly into `main`** (never `development → main`), and the scope audited (`git log --oneline v<prev>^{commit}..main` / `git diff --stat v<prev>^{commit}..main`) to show only the intended fixes plus release metadata.
119 - Release notes or changelog entries match the actual changes.
120 - CI-equivalent local checks pass for the relevant platform or target.
121 - Package names, install commands, and branding stay consistent across npm, PyPI, crates.io, Homebrew, NuGet, Scoop, winget, AUR, and the `.deb`/`.rpm` packages.