@sigitcode-old / sigit / commits / 60996b8

Fork 1

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

Drop the MCP Registry workflow from the release skill

The listing moved to getsigit/si, so this repo has no release-mcp-registry.yml and a release note that points at one sends the reader looking for a file that is not there. Replace it with what the flow actually does now, and add the two post-release checks that were missing: winget only goes live when its manifest PR merges, and each registry has to be verified by the name it publishes under (PyPI is `sigit-code`, not `sigit`). Co-Authored-By: siGit Code v1.7.5-acp <noreply@sigit.si>

keypair34 committed Oct 27, 2026 at 14:05 UTC 60996b8e28016f5d679ba4c675a9486db3f5d150

1 file changed +7 -6

.agents/skills/sigit-code-release/SKILL.md

+7 -6

@@ -31,15 +31,15 @@ Use this skill when preparing a release for this repository.

31 - Every npm package publishes twice, under `@getsigit` and under `@smbcloud`. `@smbcloud` is the pre-1.5.5 name, mirrored so an install predating the rename keeps updating; `@getsigit` is canonical and is what the README, the Homebrew tap, and the ACP registry entry point at. All fourteen names (two base packages, twelve platform packages) publish over OIDC and each needs its own Trusted Publisher on npm pointing at `release-npm.yml`.

32 - The scope is a render-time argument, not a second copy of the packaging: `render-platform-package.cjs` takes it as a fifth argument, and the base package picks it up from `package-main.json.tmpl` versus `package-compat.json.tmpl`. `npm/sigit/src/index.ts` is built once and shipped under both names — it reads its own `package.json` at runtime to decide which scope to resolve the platform binary from, and prints the migration notice only when it finds itself running as `@smbcloud/sigit`.

33 - 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 `crates/cli/Cargo.toml`, which inherits the workspace version.

34 -- 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.

34 +- Release workflows are tag-driven. `release-github.yml`, `release-npm.yml`, `release-pypi.yml`, `release-crates.yml`, `release-homebrew.yml`, and `release-nuget.yml` all derive `RELEASE_VERSION` from a `v*.*.*` tag or a manually supplied tag input.

35 - 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.

36 -- `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`.

36 +- `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`, by contrast, is tag-triggered directly like the other language-registry workflows, not dispatched from `release-github.yml`. `release-aur.yml` exists but its dispatch line in `release-github.yml` is commented out (`// New AUR account registration is temporarily closed`), so AUR does not update on a normal release — an absent AUR bump is expected, not a failure.

37 - 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.

38 - The GitHub release body is generated, not hand-written: `release-github.yml`'s release job checks out the tag, awk-extracts the `## <version>` section from `CHANGELOG.md` (a missing section is a hard failure), appends a full-changelog link and a `sigit.si/code` footnote, and publishes it via `body_path: release_notes.md`. The only file a release-prep change needs to touch is `CHANGELOG.md` — never edit release notes in the GitHub UI, because the next tag push would overwrite them.

39 - 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.

40 - 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.

41 - The winget channel (`release-winget.yml`) files a Package Request issue first and then opens the manifest PR that resolves it, authored by **two separate classic PATs** (not fine-grained) — `WINGET_ISSUE_TOKEN` for the issue and `WINGET_PR_TOKEN` for the PR, replacing the old single `WINGET_TOKEN`. `WINGET_ISSUE_TOKEN` needs `public_repo`. `WINGET_PR_TOKEN` needs `public_repo` **plus `read:org` and `read:discussion`**: wingetcreate forks `microsoft/winget-pkgs` and opens the PR (fork needs `public_repo`; a fine-grained PAT scoped to `getsigit/sigit` can't fork an outside repo and 403/404s), and the "Set the winget PR body" step then runs `gh pr edit`, whose GraphQL query resolves org/team and discussion fields and fails with a scope error on a `public_repo`-only token (CI run 38262301933). The PR token is passed as `WINGET_CREATE_GITHUB_TOKEN` (not `--token`) so it doesn't leak into logs. `wingetcreate update` only works on a package that already exists in `microsoft/winget-pkgs`, so the workflow checks `manifests/g/getSigit/siGitCode` first and falls back to `wingetcreate submit` with `packaging/winget/*.yaml.in` for the first release; every later release takes the `update` path. If a winget release fails on the fork step, check the token type; if it fails on the `gh pr edit` step with a scope error, check `WINGET_PR_TOKEN`'s scopes before re-dispatching.

42 -- 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.

42 +- The baked-in official MCP server is listed in the public MCP Registry as `si.sigit/sigit`, but **that listing is not published from this repo**. Its `server.json` and `release-mcp-registry.yml` moved to [`getsigit/si`](https://github.com/getsigit/si) (commit `5aa0be3`, "Move the MCP Registry listing to getsigit/si"), because the hosted server is that repo's product. Its version tracks the sigit.si API, not the CLI, so it does not bump with a siGit Code release and nothing in the release flow needs to touch it. It's a remote Streamable-HTTP listing verified by a DNS TXT record on the `sigit.si` domain rather than the GitHub-OIDC scheme used for package listings.

44 ## Git release flow

@@ -102,8 +102,7 @@ flows start from different base commits and are not interchangeable.

102 - `pypi/`

103 - `nuget/sigit/` (bundled-binary `.NET` tool packaging)

104 - `packaging/` (`nfpm.yaml` for `.deb`/`.rpm`, plus `aur/` and `winget/` templates)

105 -- `server.json` (MCP Registry listing)

106 -- `.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`)

105 +- `.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`) — there is deliberately no `release-mcp-registry.yml`; the MCP Registry listing lives in `getsigit/si`

106

107 ## Release checklist

108

@@ -120,5 +119,7 @@ flows start from different base commits and are not interchangeable.

119 - CI-equivalent local checks pass for the relevant platform or target.

120 - Package names, install commands, and branding stay consistent across npm, PyPI, crates.io, Homebrew, NuGet, Scoop, winget, AUR, and the `.deb`/`.rpm` packages.

121 - Every release asset (including the new `.deb`/`.rpm`/raw binaries consumed by Scoop, winget, and AUR) has a matching `.sha256` sidecar.

123 -- 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`.

122 +- Any known release limitations are called out explicitly, including a dispatch failure in `release-homebrew`/`release-scoop`/`release-winget` (non-fatal — logged as a warning by `release-github.yml`) versus a hard failure in a directly tag-triggered workflow like `release-nuget`.

123 +- winget is the one channel that is not live at release time even when its run is green: `release-winget.yml` opens a manifest PR against `microsoft/winget-pkgs`, and a human reviewer has to merge it. The manifests directory will still show the previous version and `winget install` will still serve it until then. Report it as "PR opened, awaiting review" with the PR link, never as a failure.

124 +- Verify each registry after the runs finish, by the name it actually publishes under: crates.io `sigit`, npm `@getsigit/sigit` **and** `@smbcloud/sigit`, PyPI **`sigit-code`** (not `sigit` — that name belongs to an unrelated package stuck at 0.0.58), NuGet `SiGit.Code` (`https://api.nuget.org/v3-flatcontainer/sigit.code/index.json`), Homebrew `getsigit/homebrew-tap/Formula/sigit.rb`, Scoop `getsigit/scoop-bucket/bucket/sigit.json`, winget `microsoft/winget-pkgs/manifests/g/getSigit/siGitCode`. crates.io rejects a bare `curl` with 403, so send a `User-Agent`.

125 - The winget channel uses two classic PATs (not fine-grained): `WINGET_ISSUE_TOKEN` (`public_repo`) for the Package Request issue and `WINGET_PR_TOKEN` (`public_repo` + `read:org` + `read:discussion`) for the manifest PR, so wingetcreate can fork `microsoft/winget-pkgs` and `gh pr edit` can set the PR body. If a winget release fails on the fork step, verify the token type; if it fails on the `gh pr edit` step, verify `WINGET_PR_TOKEN`'s scopes before re-dispatching.