claude/elegant-carson-l1menh
claude/code-feature-parity-q003hm
claude/elegant-carson-l1menh
claude/sigit-acp-local-chat-cx6380
claude/sigit-cloud-agent-expansion-reox0a
claude/tool-permission-system
claude/zen-feynman-0u78dk
development
feature/agent-tools-multiedit-glob-todos-remember
feature/background-commands
feature/commit-coauthor-attribution
feature/headless-mode
feature/init-command
feature/load-local-model-explicitly
feature/session-persistence-compaction
feature/sigit-code-cloud
feature/subagent-tool
feature/tool-permission-system
feature/tui-repo-tabs
feature/tui-tabs
main
release/v1.3.1
| 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`, and `release-homebrew.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 | |
| 35 | ## Typical files to inspect |
| 36 | |
| 37 | - `Cargo.toml` |
| 38 | - `Cargo.lock` |
| 39 | - `CHANGELOG.md` |
| 40 | - `README.md` |
| 41 | - `npm/sigit/package.json` |
| 42 | - `npm/scripts/render-main-package.cjs` |
| 43 | - `npm/` |
| 44 | - `pypi/` |
| 45 | - `.github/workflows/` (`release-github.yml`, `release-npm.yml`, `release-pypi.yml`, `release-crates.yml`, `release-homebrew.yml`) |
| 46 | |
| 47 | ## Release checklist |
| 48 | |
| 49 | - Version bump is applied everywhere it needs to be. |
| 50 | - `Cargo.toml` and the root crate entry in `Cargo.lock` match. |
| 51 | - `CHANGELOG.md` has a correct top entry for the new release. |
| 52 | - `npm/sigit/package.json` is left at `0.0.0-dev` unless the packaging flow itself changed. |
| 53 | - `pypi/pyproject.toml` still uses dynamic versioning unless there is a deliberate packaging change. |
| 54 | - Release workflows still derive their version from the tag as expected. |
| 55 | - Release notes or changelog entries match the actual changes. |
| 56 | - CI-equivalent local checks pass for the relevant platform or target. |
| 57 | - Package names, install commands, and branding stay consistent. |
| 58 | - Any known release limitations are called out explicitly. |