How do I install the Release Rome Image skill?

Run npx skillmds@latest add rome-os/release-rome-image in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Release Rome Image safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Release Rome Image?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Release Rome Image free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Release Rome Image?

rome-os (@rome-os) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Release Rome Image by rome-os — Agent Skill

Name: Release Rome Image
Author: rome-os

Release Rome Image

Release a new Rome runtime image by pushing a `vX.Y.Z` tag — pick the version, verify main is releasable, push the tag, and confirm the image published to Docker Hub. Covers the `v*` runtime-image tag only, not the desktop app (`desktop-v*`) and not npm packages (`ui-v*`, `app-runtime-v*`).

rome-os e0acb14 3.4 KB Updated Sep 17, 2026

File contents

Release a new Rome image

A pushed vX.Y.Z tag is the release. .github/workflows/docker-publish.yml builds the multi-arch image and publishes it to yunfanye/rome, with no approval gate between the push and Docker Hub. Get explicit confirmation before the push. Verify the published image after it.

The tagging contract covering the semver gate, tag immutability, and latest movement lives in docs/releases.md.

Out of scope

Desktop releases use the desktop-v* tag and a separate pipeline.
npm package releases belong to release-please. Never create those tags by hand.

1. Preflight

The tag lands on origin/main, and docker-publish.yml runs no CI gate of its own.

Read the commit that the tag will point at.

git fetch origin --tags && git rev-parse origin/main

List the recent CI runs.

gh run list --branch main --workflow CI --limit 5

Find the run for the exact commit from step 1 and confirm the status is success. CI cancels superseded runs, so a rapid series of merges leaves cancelled runs on real commits. If the run failed, was cancelled, or is still running, stop and report it.

Confirm no release is already in flight.

gh run list --workflow "Docker Hub Publish" --limit 3

2. Pick the version

Read the current stable tags.

git tag --list 'v[0-9]*' | sort -V | tail -5

For a patch release, use the helper in step 3. The helper computes the next patch version.
For a minor or major release, take the version from the user.
For a prerelease, use vX.Y.Z-rc.N. A prerelease publishes its own docker tag and never moves latest.

Two constraints decide the number. A published version is immutable, so re-pushing a released version fails and the fix for a bad release is the next version up. latest moves only when the new version is the highest stable version in the registry.

3. Cut the tag

For a patch release:

Print the planned tag and target commit.

scripts/dev/create-patch-release-tag.sh --dry-run

Show that output to the user and wait for an explicit yes.
Create and push the tag, which starts the publish.
```
scripts/dev/create-patch-release-tag.sh
```

For a minor, major, or prerelease version, the helper does not apply, because it bumps the patch version only. Confirm the version with the user, then tag origin/main directly.

git tag -a v1.1.0 origin/main -m "Release v1.1.0" && git push origin refs/tags/v1.1.0

4. Verify the publish

Watch the run to completion.

gh run watch "$(gh run list --workflow "Docker Hub Publish" --limit 1 --json databaseId --jq '.[0].databaseId')"

Confirm the version reached the registry.

curl -fsSL "https://hub.docker.com/v2/repositories/yunfanye/rome/tags?page_size=20" | jq -r '.results[].name'

Report the published version, whether latest moved, and the build SHA. A running instance reports the baked version at /api/build-info.

---name: release-rome-imagedescription: Release a new Rome runtime image by pushing a `vX.Y.Z` tag — pick the version, verify main is releasable, push the tag, and confirm the image published to Docker Hub. Covers the `v*` runtime-image tag only, not the desktop app (`desktop-v*`) and not npm packages (`ui-v*`, `app-runtime-v*`).---# Release a new Rome imageA pushed `vX.Y.Z` tag is the release. `.github/workflows/docker-publish.yml` builds the multi-arch image and publishes it to `yunfanye/rome`, with no approval gate between the push and Docker Hub. Get explicit confirmation before the push. Verify the published image after it.The tagging contract covering the semver gate, tag immutability, and `latest` movement lives in [docs/releases.md](../../../docs/releases.md#tagging-contract).## Out of scope- Desktop releases use the `desktop-v*` tag and a separate pipeline.- npm package releases belong to release-please. Never create those tags by hand.## 1. PreflightThe tag lands on `origin/main`, and `docker-publish.yml` runs no CI gate of its own.1. Read the commit that the tag will point at. ```bash git fetch origin --tags && git rev-parse origin/main ```2. List the recent CI runs. ```bash gh run list --branch main --workflow CI --limit 5 ```3. Find the run for the exact commit from step 1 and confirm the status is `success`. CI cancels superseded runs, so a rapid series of merges leaves `cancelled` runs on real commits. If the run failed, was cancelled, or is still running, stop and report it.4. Confirm no release is already in flight. ```bash gh run list --workflow "Docker Hub Publish" --limit 3 ```## 2. Pick the version1. Read the current stable tags. ```bash git tag --list 'v[0-9]*' | sort -V | tail -5 ```2. For a patch release, use the helper in step 3. The helper computes the next patch version.3. For a minor or major release, take the version from the user.4. For a prerelease, use `vX.Y.Z-rc.N`. A prerelease publishes its own docker tag and never moves `latest`.Two constraints decide the number. A published version is immutable, so re-pushing a released version fails and the fix for a bad release is the next version up. `latest` moves only when the new version is the highest stable version in the registry.## 3. Cut the tagFor a patch release:1. Print the planned tag and target commit. ```bash scripts/dev/create-patch-release-tag.sh --dry-run ```2. Show that output to the user and wait for an explicit yes.3. Create and push the tag, which starts the publish. ```bash scripts/dev/create-patch-release-tag.sh ```For a minor, major, or prerelease version, the helper does not apply, because it bumps the patch version only. Confirm the version with the user, then tag `origin/main` directly.```bashgit tag -a v1.1.0 origin/main -m "Release v1.1.0" && git push origin refs/tags/v1.1.0```## 4. Verify the publish1. Watch the run to completion. ```bash gh run watch "$(gh run list --workflow "Docker Hub Publish" --limit 1 --json databaseId --jq '.[0].databaseId')" ```2. Confirm the version reached the registry. ```bash curl -fsSL "https://hub.docker.com/v2/repositories/yunfanye/rome/tags?page_size=20" | jq -r '.results[].name' ```3. Report the published version, whether `latest` moved, and the build SHA. A running instance reports the baked version at `/api/build-info`.

Frequently asked questions