release-maintainer

Name: release-maintainer
Author: Undertone0809

247stars30forks

How to install release-maintainer?

undertone0809/rudder/release-maintainer

$npx -y skills add Undertone0809/rudder --skill release-maintainer

Installs into the current project.

Summary

Use when maintaining or executing Rudder releases: npm publish, canary/stable promotion, GitHub Releases, Desktop assets, tags, dist-tags, version bumps, rollback, install smoke, release workflow failures, and release-state decisions.

Files · 1

View on GitHub

SKILL.md

1	# Release Maintainer
2
3	Help the user ship Rudder without losing track of release surfaces.
4
5	Rudder's release model has several moving parts: npm packages, git tags, GitHub
6	Releases, Desktop portable assets, release notes, and smoke tests. Your job is to
7	turn the current repo and remote state into a concrete release plan, then
8	execute only the steps the user has authorized.
9
10	When the user authorizes hands-on release work, operate with local and remote
11	tools instead of stopping at guidance. Prefer `git`, `gh`, `npm`, and repository
12	scripts for discoverable state. Ask the user only for secrets or decisions that
13	cannot be safely inferred.
14
15	## First Principles
16
17	- npm publishes the CLI and public runtime/workspace packages.
18	- Desktop binaries are GitHub Release assets, not npm packages.
19	- Canary git tags keep the `canary/` namespace, for example
20	`canary/v0.1.0-canary.2`, but the GitHub Release display title should be the
21	clean version name, for example `v0.1.0-canary.2`.
22	- The public npm scope is `@rudderhq`. Treat old examples using `@rudder` as
23	stale unless the repository explicitly reintroduces that scope.
24	- The stable user entrypoint is `npx @rudderhq/cli@latest start`. Bare
25	`npx @rudderhq/cli start` resolves npm's `latest` dist-tag.
26	- After the persistent CLI exists, `rudder <command>` and
27	`npx @rudderhq/cli@latest <command>` are the same CLI surface when they resolve
28	to the same CLI version. The `npx` form is the first-run or explicit dist-tag
29	form.
30	- Canaries publish from `main` automatically after the exact commit's `CI`
31	workflow succeeds, and use npm dist-tag `canary`. The release workflow must
32	consume that CI result instead of repeating the full operating-system test
33	matrix.
34	- Canary git tags use `canary/vX.Y.Z-canary.N`. The matching GitHub Release
35	display title should be clean `vX.Y.Z-canary.N`, not the full tag name, and
36	it should be marked prerelease.
37	- A tag pushed by GitHub Actions' `GITHUB_TOKEN` does not trigger another
38	workflow by itself. If canary npm publish creates the tag, `release.yml` must
39	explicitly dispatch `desktop-release.yml`, or the maintainer must do it.
40	- Stables are manually promoted from an explicitly chosen source ref and use
41	npm dist-tag `latest`.
42	- Stable preflight must fail closed unless `npm-stable` has required reviewers,
43	`main` is protected, and GitHub Actions is allowed to create pull requests.
44	Do not bypass these checks or treat the confirmation string as a substitute
45	for the repository safeguards.
46	- Stable tags point at the original source commit, not at a generated release
47	commit.
48	- After a stable `vX.Y.Z` is published and verified, older canary GitHub
49	Releases and `canary/*` git tags for released-or-older base versions should
50	be cleaned up unless the user asks to preserve them. This cleanup does not
51	unpublish npm package versions; npm `-canary.` versions are immutable
52	package history and should remain published.
53	- For stable releases, `main` is only a selector until you resolve it. Before
54	the real publish, lock the source to an immutable commit SHA or stable tag and
55	use that same ref for dry-run, publish, Desktop recovery, and verification.
56	Do not chase newer `main` commits or newer canaries during the stable unless
57	the user explicitly asks to retarget the release.
58	- A stable release is not done until verification, npm, GitHub Release, Desktop
59	assets, and public notes/announcement are all handled.
60	- Stable release notes use the standard changelog categories `New Features`,
61	`Improvements`, and `Bug Fixes`, in that order. GitHub Release source files
62	use those categories as `##` headings. Public docs changelog entries keep
63	`## vX.Y.Z` as the version heading, then use the same category labels inside
64	the entry.
65	- Pre-stable public canaries may temporarily be the default `latest` install
66	path if there is no stable npm version yet and the user explicitly wants
67	`npx @rudderhq/cli@latest start` or bare `npx @rudderhq/cli start` to work
68	immediately. Call this out as an alpha/bootstrap exception, not the normal
69	canary policy.
70	- During the pre-stable bootstrap exception, npm `latest` must not move to a
71	canary until the matching Desktop GitHub Release has all portable assets and
72	`SHASUMS256.txt`. Otherwise `npx @rudderhq/cli@latest start` can resolve a CLI
73	version whose Desktop release is not installable yet.
74	- A `--dry-run` smoke only proves version and asset selection. It does not prove
75	download, checksum, extraction, symlink preservation, quarantine cleanup, or
76	app launchability. Do not claim the public Desktop install path is fixed until
77	a non-dry-run isolated `npx ... start --no-open` install succeeds on the
78	av

People who liked this also viewed

6 picks

Type

release-maintainer

247stars30forks

View on GitHub

How to install release-maintainer?

undertone0809/rudder/release-maintainer

$npx -y skills add Undertone0809/rudder --skill release-maintainer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Release Maintainer
2
3	Help the user ship Rudder without losing track of release surfaces.
4
5	Rudder's release model has several moving parts: npm packages, git tags, GitHub
6	Releases, Desktop portable assets, release notes, and smoke tests. Your job is to
7	turn the current repo and remote state into a concrete release plan, then
8	execute only the steps the user has authorized.
9
10	When the user authorizes hands-on release work, operate with local and remote
11	tools instead of stopping at guidance. Prefer `git`, `gh`, `npm`, and repository
12	scripts for discoverable state. Ask the user only for secrets or decisions that
13	cannot be safely inferred.
14
15	## First Principles
16
17	- npm publishes the CLI and public runtime/workspace packages.
18	- Desktop binaries are GitHub Release assets, not npm packages.
19	- Canary git tags keep the `canary/` namespace, for example
20	`canary/v0.1.0-canary.2`, but the GitHub Release display title should be the
21	clean version name, for example `v0.1.0-canary.2`.
22	- The public npm scope is `@rudderhq`. Treat old examples using `@rudder` as
23	stale unless the repository explicitly reintroduces that scope.
24	- The stable user entrypoint is `npx @rudderhq/cli@latest start`. Bare
25	`npx @rudderhq/cli start` resolves npm's `latest` dist-tag.
26	- After the persistent CLI exists, `rudder <command>` and
27	`npx @rudderhq/cli@latest <command>` are the same CLI surface when they resolve
28	to the same CLI version. The `npx` form is the first-run or explicit dist-tag
29	form.
30	- Canaries publish from `main` automatically after the exact commit's `CI`
31	workflow succeeds, and use npm dist-tag `canary`. The release workflow must
32	consume that CI result instead of repeating the full operating-system test
33	matrix.
34	- Canary git tags use `canary/vX.Y.Z-canary.N`. The matching GitHub Release
35	display title should be clean `vX.Y.Z-canary.N`, not the full tag name, and
36	it should be marked prerelease.
37	- A tag pushed by GitHub Actions' `GITHUB_TOKEN` does not trigger another
38	workflow by itself. If canary npm publish creates the tag, `release.yml` must
39	explicitly dispatch `desktop-release.yml`, or the maintainer must do it.
40	- Stables are manually promoted from an explicitly chosen source ref and use
41	npm dist-tag `latest`.
42	- Stable preflight must fail closed unless `npm-stable` has required reviewers,
43	`main` is protected, and GitHub Actions is allowed to create pull requests.
44	Do not bypass these checks or treat the confirmation string as a substitute
45	for the repository safeguards.
46	- Stable tags point at the original source commit, not at a generated release
47	commit.
48	- After a stable `vX.Y.Z` is published and verified, older canary GitHub
49	Releases and `canary/*` git tags for released-or-older base versions should
50	be cleaned up unless the user asks to preserve them. This cleanup does not
51	unpublish npm package versions; npm `-canary.` versions are immutable
52	package history and should remain published.
53	- For stable releases, `main` is only a selector until you resolve it. Before
54	the real publish, lock the source to an immutable commit SHA or stable tag and
55	use that same ref for dry-run, publish, Desktop recovery, and verification.
56	Do not chase newer `main` commits or newer canaries during the stable unless
57	the user explicitly asks to retarget the release.
58	- A stable release is not done until verification, npm, GitHub Release, Desktop
59	assets, and public notes/announcement are all handled.
60	- Stable release notes use the standard changelog categories `New Features`,
61	`Improvements`, and `Bug Fixes`, in that order. GitHub Release source files
62	use those categories as `##` headings. Public docs changelog entries keep
63	`## vX.Y.Z` as the version heading, then use the same category labels inside
64	the entry.
65	- Pre-stable public canaries may temporarily be the default `latest` install
66	path if there is no stable npm version yet and the user explicitly wants
67	`npx @rudderhq/cli@latest start` or bare `npx @rudderhq/cli start` to work
68	immediately. Call this out as an alpha/bootstrap exception, not the normal
69	canary policy.
70	- During the pre-stable bootstrap exception, npm `latest` must not move to a
71	canary until the matching Desktop GitHub Release has all portable assets and
72	`SHASUMS256.txt`. Otherwise `npx @rudderhq/cli@latest start` can resolve a CLI
73	version whose Desktop release is not installable yet.
74	- A `--dry-run` smoke only proves version and asset selection. It does not prove
75	download, checksum, extraction, symlink preservation, quarantine cleanup, or
76	app launchability. Do not claim the public Desktop install path is fixed until
77	a non-dry-run isolated `npx ... start --no-open` install succeeds on the
78	av

People who liked this also viewed

6 picks

Type