clawbox-release-publish

Name: clawbox-release-publish
Author: CommonstackAI

22stars1forks

How to install clawbox-release-publish?

commonstackai/clawbox/clawbox-release-publish

$npx -y skills add CommonstackAI/ClawBox --skill clawbox-release-publish

Installs into the current project.

Summary

Use when the user asks to prepare, cut, validate, tag, or publish a ClawBox desktop release. Covers the UTC date-based version flow (npm run release:version), release validation commands, release commit/tag creation, and pushing the matching v tag for the current package vers

Files · 1

View on GitHub

SKILL.md

1	# ClawBox Release Publish
2
3	Use this skill to run the current ClawBox release process end to end.
4
5	## Read first
6
7	- `docs/releasing.md`
8	- `.github/release-notes-template.md`
9	- `docs/releases/`
10	- `package.json`
11	- `scripts/release-version.mjs`
12	- `scripts/sync-version.mjs`
13	- `.github/workflows/release.yml`
14	- `git status --short --branch`
15
16	If the user also asks to create the commit or push the branch/tag, read `.agents/skills/clawbox-git-commit-push/SKILL.md`.
17
18	## Workflow
19
20	1. Inspect the worktree before starting. Stop if unrelated dirty changes would be mixed into the release.
21	2. Fetch tags with `git fetch --tags` before generating a version. The UTC day sequence is based on local tags.
22	3. Run `npm run release:version`. This updates `package.json`, `package-lock.json`, `src-tauri/tauri.conf.json`, and `src-tauri/Cargo.toml`.
23	4. Read back the selected version with `node -p "require('./package.json').version"` and use that exact value for the release commit and tag.
24	5. If the user wants curated release notes, copy `.github/release-notes-template.md` to `docs/releases/v<version>.md` and fill it in before the release commit. If that file is missing, GitHub falls back to auto-generated notes.
25	6. Run the standard release validation set unless the user explicitly scopes it down:
26	- `npm run scan:repo`
27	- `npm run audit:licenses`
28	- `npm run audit:deps`
29	- `npm run build:frontend`
30	- `npm run build:backend`
31	- `cargo check --manifest-path src-tauri/Cargo.toml`
32	7. If the user wants the release prepared but not published, stop after reporting the version, changed files, release notes status, and validation status.
33	8. If the user wants the release published, create a focused commit for the release files, create tag `v<version>`, push the branch, then push the tag.
34
35	## Expected commands
36
37	Prepare the next release version:
38
39	```bash
40	git fetch --tags
41	npm run release:version
42	```
43
44	Validate the release:
45
46	```bash
47	npm run scan:repo
48	npm run audit:licenses
49	npm run audit:deps
50	npm run build:frontend
51	npm run build:backend
52	cargo check --manifest-path src-tauri/Cargo.toml
53	```
54
55	Publish after validation:
56
57	```bash
58	VERSION=$(node -p "require('./package.json').version")
59	cp .github/release-notes-template.md "docs/releases/v${VERSION}.md"
60
61	git add package.json package-lock.json src-tauri/tauri.conf.json src-tauri/Cargo.toml docs/releases/v${VERSION}.md
62	git commit -m "release: v$VERSION"
63	git tag "v$VERSION"
64	git push origin HEAD
65	git push origin "v$VERSION"
66	```
67
68	## Guardrails
69
70	- Do not hand-edit the version fields when the goal is to cut a release. Use `npm run release:version`.
71	- Do not create or push a tag that differs from `v<package.json version>`. The release workflow rejects mismatches.
72	- Do not silently skip `git fetch --tags`; without it, the same UTC day can generate the wrong `-N`.
73	- Do not stage unrelated files, generated artifacts, or user work that is outside the release scope.
74	- Do not assume release notes are mandatory; if `docs/releases/<tag>.md` is absent, the workflow falls back to GitHub-generated notes.
75	- Do not claim Windows signing was performed unless `WIN_SIGN_THUMBPRINT` or equivalent signing prerequisites were actually available.
76	- If validation is incomplete, say exactly which commands were skipped or failed.
77
78	## Verification
79
80	- Confirm `package.json`, `package-lock.json`, `src-tauri/tauri.conf.json`, and `src-tauri/Cargo.toml` all reflect the same version after `npm run release:version`.
81	- Run `npm run sync-version` after version generation only when you need to verify the sync chain; it should not create additional diffs.
82	- After commit/tag creation, report the version, commit hash, branch, and pushed tag.

People who liked this also viewed

6 picks

Type

clawbox-release-publish

22stars1forks

View on GitHub

How to install clawbox-release-publish?

commonstackai/clawbox/clawbox-release-publish

$npx -y skills add CommonstackAI/ClawBox --skill clawbox-release-publish

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# ClawBox Release Publish
2
3	Use this skill to run the current ClawBox release process end to end.
4
5	## Read first
6
7	- `docs/releasing.md`
8	- `.github/release-notes-template.md`
9	- `docs/releases/`
10	- `package.json`
11	- `scripts/release-version.mjs`
12	- `scripts/sync-version.mjs`
13	- `.github/workflows/release.yml`
14	- `git status --short --branch`
15
16	If the user also asks to create the commit or push the branch/tag, read `.agents/skills/clawbox-git-commit-push/SKILL.md`.
17
18	## Workflow
19
20	1. Inspect the worktree before starting. Stop if unrelated dirty changes would be mixed into the release.
21	2. Fetch tags with `git fetch --tags` before generating a version. The UTC day sequence is based on local tags.
22	3. Run `npm run release:version`. This updates `package.json`, `package-lock.json`, `src-tauri/tauri.conf.json`, and `src-tauri/Cargo.toml`.
23	4. Read back the selected version with `node -p "require('./package.json').version"` and use that exact value for the release commit and tag.
24	5. If the user wants curated release notes, copy `.github/release-notes-template.md` to `docs/releases/v<version>.md` and fill it in before the release commit. If that file is missing, GitHub falls back to auto-generated notes.
25	6. Run the standard release validation set unless the user explicitly scopes it down:
26	- `npm run scan:repo`
27	- `npm run audit:licenses`
28	- `npm run audit:deps`
29	- `npm run build:frontend`
30	- `npm run build:backend`
31	- `cargo check --manifest-path src-tauri/Cargo.toml`
32	7. If the user wants the release prepared but not published, stop after reporting the version, changed files, release notes status, and validation status.
33	8. If the user wants the release published, create a focused commit for the release files, create tag `v<version>`, push the branch, then push the tag.
34
35	## Expected commands
36
37	Prepare the next release version:
38
39	```bash
40	git fetch --tags
41	npm run release:version
42	```
43
44	Validate the release:
45
46	```bash
47	npm run scan:repo
48	npm run audit:licenses
49	npm run audit:deps
50	npm run build:frontend
51	npm run build:backend
52	cargo check --manifest-path src-tauri/Cargo.toml
53	```
54
55	Publish after validation:
56
57	```bash
58	VERSION=$(node -p "require('./package.json').version")
59	cp .github/release-notes-template.md "docs/releases/v${VERSION}.md"
60
61	git add package.json package-lock.json src-tauri/tauri.conf.json src-tauri/Cargo.toml docs/releases/v${VERSION}.md
62	git commit -m "release: v$VERSION"
63	git tag "v$VERSION"
64	git push origin HEAD
65	git push origin "v$VERSION"
66	```
67
68	## Guardrails
69
70	- Do not hand-edit the version fields when the goal is to cut a release. Use `npm run release:version`.
71	- Do not create or push a tag that differs from `v<package.json version>`. The release workflow rejects mismatches.
72	- Do not silently skip `git fetch --tags`; without it, the same UTC day can generate the wrong `-N`.
73	- Do not stage unrelated files, generated artifacts, or user work that is outside the release scope.
74	- Do not assume release notes are mandatory; if `docs/releases/<tag>.md` is absent, the workflow falls back to GitHub-generated notes.
75	- Do not claim Windows signing was performed unless `WIN_SIGN_THUMBPRINT` or equivalent signing prerequisites were actually available.
76	- If validation is incomplete, say exactly which commands were skipped or failed.
77
78	## Verification
79
80	- Confirm `package.json`, `package-lock.json`, `src-tauri/tauri.conf.json`, and `src-tauri/Cargo.toml` all reflect the same version after `npm run release:version`.
81	- Run `npm run sync-version` after version generation only when you need to verify the sync chain; it should not create additional diffs.
82	- After commit/tag creation, report the version, commit hash, branch, and pushed tag.

People who liked this also viewed

6 picks

Type