@sigitcodereview / sigit
Code Commits Issues Pulls Cloud Agent CI/CD
release/v1.5.6
claude/github-issue-40-0au5ua claude/linked-issue-acp-tui-u4vvpa claude/minor-release-cut-vkugow claude/sigit-acp-local-chat-cx6380 claude/sigit-cloud-agent-expansion-reox0a claude/tool-permission-system claude/zen-feynman-0u78dk development feature/acp-cancel-request feature/acp-session-list-cursor feature/acp-v1-conformance feature/agent-tools-multiedit-glob-todos-remember feature/cargo-workspace feature/hooks feature/load-local-model-explicitly feature/sigit-agent-profile feature/sigit-code-cloud feature/xcode-mcp-server fix/acp-replay-loaded-session-history fix/acp-replay-reasoning-and-attachments fix/dsml-doubled-bar-markers main release/v1.5.10 release/v1.5.6 release/v1.6.1
md 82 lines 7.46 KB
Rendered Raw
1 ---
2 name: sigit-code-release
3 description: Prepare and verify siGit Code releases. Use when bumping versions, checking Cargo, npm, or PyPI package metadata, validating release notes, confirming CI readiness, or assembling a release checklist for a new siGit Code version.
4 ---
5
6 # siGit Code Release
7
8 Use this skill when preparing a release for this repository.
9
10 ## Focus areas
11
12 - Keep the branded product name as `siGit Code` in prose and `sigit` for commands, crate names, repo paths, and package identifiers.
13 - Verify version consistency across release surfaces, but respect which files are real sources of truth versus generated or release-time rewritten artifacts.
14 - Check release-facing docs such as `README.md`, `CHANGELOG.md`, workflow notes, and package metadata for stale version references or incorrect naming.
15 - Validate the local release path pragmatically: formatting, linting, targeted tests, and any repo-specific release checks that matter for the requested version.
16
17 ## Working approach
18
19 1. Read the files that define the release version and distribution metadata before proposing any changes.
20 2. Treat `Cargo.toml` as the primary release version source for the Rust crate and the PyPI package in this repository.
21 3. Check how the release workflows rewrite or derive versions before editing checked-in npm or Python metadata.
22 4. Prefer targeted verification commands that match CI or packaging workflows already present in the repository.
23 5. Report blockers clearly: failed checks, version mismatches, missing changelog entries, or unpublished packaging changes.
24
25 ## Repo-specific release rules
26
27 - Bump the crate version in `Cargo.toml`.
28 - Update the root `sigit` package entry in `Cargo.lock` when the crate version changes.
29 - Add or update the top changelog entry in `CHANGELOG.md` for the release being cut.
30 - Do not treat `npm/sigit/package.json` `0.0.0-dev` as a bug by default. The npm release workflow rewrites it at publish time using `npm/scripts/render-main-package.cjs` and the release tag.
31 - Do not add a hardcoded version to `pypi/pyproject.toml` for normal releases. PyPI uses `maturin` with `dynamic = ["version"]` and derives the published package version from `Cargo.toml`.
32 - Release workflows are tag-driven. `release-github.yml`, `release-npm.yml`, `release-pypi.yml`, `release-crates.yml`, `release-homebrew.yml`, `release-nuget.yml`, and `release-mcp-registry.yml` all derive `RELEASE_VERSION` from a `v*.*.*` tag or a manually supplied tag input.
33 - The crate is published to crates.io (`release-crates.yml`) and the Homebrew tap is updated (`release-homebrew.yml`) as part of the tag-driven flow. Per the siGit release flow, Homebrew is auto-triggered — do not dispatch it manually.
34 - `release-github.yml` builds the binaries, attaches them (plus a `.deb`/`.rpm` per Linux target built with nfpm from `packaging/nfpm.yaml`) to the GitHub release, then dispatches `release-homebrew`, `release-scoop`, `release-winget`, and `release-aur`. A dispatch failure in any one of those four is logged as a warning, not a hard failure — an unconfigured channel doesn't block the rest of the release. `release-nuget.yml` and `release-mcp-registry.yml`, by contrast, are tag-triggered directly like the other language-registry workflows, not dispatched from `release-github.yml`.
35 - Every release asset carries a `.sha256` sidecar (not just the macOS Homebrew tarball). Scoop, winget, and the AUR PKGBUILD each consume the raw binaries plus their sidecar checksum, rather than the tarball.
36 - npm and NuGet publish via OIDC trusted publishing — neither has a stored token in the repo. On npm this is configured per package (each `@getsigit/*` name has a trusted publisher pointing at `release-npm.yml`), so a new package needs the same setup before its first publish will work. OIDC requires npm >= 11.5.1 and Node >= 22.14.0.
37 - The NuGet package (`SiGit.Code`, `dotnet tool install --global SiGit.Code`) bundles all six platform binaries under `native/<os>-<arch>/` behind a managed shim, rather than shipping one package per platform like npm/PyPI. Watch the nuget.org 250 MB package-size limit if it ever grows.
38 - The baked-in official MCP server is separately listed in the public MCP Registry as `si.sigit/sigit` (`release-mcp-registry.yml`, driven by `server.json` at the repo root). It's a remote Streamable-HTTP listing, so it's verified by a DNS TXT record on the `sigit.si` domain rather than the GitHub-OIDC scheme used for package listings.
39
40 ## Git release flow
41
42 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:
43
44 1. Branch `release/v<version>` off `development`.
45 2. Apply the version bump and changelog edits, then commit (e.g. `Release v<version>`).
46 3. Merge `release/v<version>` back into `development`.
47 4. Merge `development` into `main` (commit message: `Merge development into main for v<version> release`).
48 5. Tag `v<version>` on that `main` merge commit, then push `main` and the tag.
49
50 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`).
51
52 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.
53
54 ## Typical files to inspect
55
56 - `Cargo.toml`
57 - `Cargo.lock`
58 - `CHANGELOG.md`
59 - `README.md`
60 - `npm/sigit/package.json`
61 - `npm/scripts/render-main-package.cjs`
62 - `npm/`
63 - `pypi/`
64 - `nuget/sigit/` (bundled-binary `.NET` tool packaging)
65 - `packaging/` (`nfpm.yaml` for `.deb`/`.rpm`, plus `aur/` and `winget/` templates)
66 - `server.json` (MCP Registry listing)
67 - `.github/workflows/` (`release-github.yml`, `release-npm.yml`, `release-pypi.yml`, `release-crates.yml`, `release-homebrew.yml`, `release-scoop.yml`, `release-winget.yml`, `release-aur.yml`, `release-nuget.yml`, `release-mcp-registry.yml`)
68
69 ## Release checklist
70
71 - Version bump is applied everywhere it needs to be.
72 - `Cargo.toml` and the root crate entry in `Cargo.lock` match.
73 - `CHANGELOG.md` has a correct top entry for the new release.
74 - `npm/sigit/package.json` is left at `0.0.0-dev` unless the packaging flow itself changed.
75 - `pypi/pyproject.toml` still uses dynamic versioning unless there is a deliberate packaging change.
76 - Release workflows still derive their version from the tag as expected.
77 - 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.
78 - Release notes or changelog entries match the actual changes.
79 - CI-equivalent local checks pass for the relevant platform or target.
80 - Package names, install commands, and branding stay consistent across npm, PyPI, crates.io, Homebrew, NuGet, Scoop, winget, AUR, and the `.deb`/`.rpm` packages.
81 - Every release asset (including the new `.deb`/`.rpm`/raw binaries consumed by Scoop, winget, and AUR) has a matching `.sha256` sidecar.
82 - Any known release limitations are called out explicitly, including a dispatch failure in `release-scoop`/`release-winget`/`release-aur` (non-fatal — logged as a warning by `release-github.yml`) versus a hard failure in a directly tag-triggered workflow like `release-nuget` or `release-mcp-registry`.