Execute qualquer Skill no Manus
com um clique

Execute qualquer Skill no Manus com um clique

release

Estrelas3

Forks1

Atualizado2 de fevereiro de 2026 às 07:00

Release automation skill for version bumping and tagging. Use when creating a new release, bumping version, tagging release, pushing release tag, or synchronizing version numbers across files. Handles package.json, README.md, SKILL.md, Dockerfile, and docker-compose files.

Instalação

Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.

Executar no Manus

Fonte

madeinoz67

madeinoz67/madeinoz-knowledge-system

Abrir repositório GitHub Ver repositórios do creator

Download

Executar no Manus

Ocupações relacionadasSOC

Baseado na classificação ocupacional SOC

Desenvolvedores de softwareInformática e Matemática·SOC 15-1252

SKILL.md

readonly

name	release
description	Release automation skill for version bumping and tagging. Use when creating a new release, bumping version, tagging release, pushing release tag, or synchronizing version numbers across files. Handles package.json, README.md, SKILL.md, Dockerfile, and docker-compose files.

Release Automation Skill

Purpose

Automate the release process for the Madeinoz Knowledge System, including version synchronization across all files, git tagging, and triggering the CI workflow.

When to Use

Use this skill when:

Creating a new release (major, minor, or patch version)
Bumping the version number
Tagging a release commit
Pushing a release to trigger CI workflow
Synchronizing version numbers across multiple files

Version Sync Locations

The following files MUST be updated with the new version:

Primary Version Files

package.json (line 3)
```
"version": "X.Y.Z"
```
docker/Dockerfile (line 8)
```
LABEL version="X.Y.Z"
```

README.md (line 6)

pack-id: madeinoz67-madeinoz-knowledge-system-core-vX.Y.Z

src/skills/SKILL.md (line 3)
```
version: X.Y.Z
```

Production Docker Compose (Manual Update)

src/skills/server/docker-compose-production.yml (line 85)

image: ghcr.io/madeinoz67/madeinoz-knowledge-system:X.Y.Z

Note: All other docker-compose files use :latest tag and do NOT need updates.

Do NOT Edit

CHANGELOG.md - Auto-generated by git-cliff workflow
Modifying this file will conflict with automated changelog generation

Pre-Release Checklist

Before creating a release, verify:

# 1. Check you're on main branch
git branch --show-current  # Should output: main

# 2. Pull latest changes
git pull origin main

# 3. Verify working tree is clean (no uncommitted changes)
git status  # Should show: "nothing to commit, working tree clean"

# 4. Verify latest CI passed
gh run list --limit 1  # Check status is "completed success"

Release Workflow

Step 1: Update Version Numbers

Manually edit the version files listed above. For example, bumping from 1.8.0 to 1.9.0:

# Edit package.json
# Edit docker/Dockerfile
# Edit README.md
# Edit src/skills/SKILL.md
# Edit src/skills/server/docker-compose-production.yml

Step 2: Commit Version Changes

git add package.json docker/Dockerfile README.md src/skills/SKILL.md src/skills/server/docker-compose-production.yml
git commit -m "chore: bump version to X.Y.Z"

Step 3: Create Annotated Tag

# Single-line description
git tag -a vX.Y.Z -m "Release vX.Y.Z"

# OR multi-line description (opens editor)
git tag -a vX.Y.Z

In the editor, use this format:

Release X.Y.Z

Summary of what's in this release:
- Feature one
- Bug fix two
- Improvement three

Step 4: Push Tag to Trigger CI

git push origin vX.Y.Z

This triggers the CI workflow which:

Generates changelog from git-cliff
Updates CHANGELOG.md on main branch
Builds and pushes multi-arch Docker image to GHCR
Creates GitHub Release with formatted release notes
Deploys documentation to GitHub Pages

Verification

After pushing the tag:

# Watch workflow run
gh run watch

# Confirm release created
gh release view vX.Y.Z

# Verify Docker image on GHCR
# https://github.com/madeinoz67/madeinoz-knowledge-system/pkgs/container/madeinoz-knowledge-system

Common Pitfalls

DO NOT Use `gh release create` Directly

❌ Wrong: gh release create vX.Y.Z --notes "Release notes"

This creates the tag via GitHub API without triggering the CI workflow. The release job will never run, leaving a broken release (no Docker image pushed, no docs deployed).

✅ Correct: git push origin vX.Y.Z

This triggers the push event for the tag, which runs the CI workflow.

DO NOT Edit CHANGELOG.md

❌ Wrong: Manually editing CHANGELOG.md

This file is auto-generated by git-cliff during the CI workflow. Manual edits will be overwritten.

✅ Correct: Use conventional commit messages. The changelog is generated from commit history.

Version Inconsistency

Ensure all version files use the exact same version string:

package.json: "version": "1.9.0"
Dockerfile: LABEL version="1.9.0"
README.md: pack-id: madeinoz67-madeinoz-knowledge-system-core-v1.9.0"
SKILL.md: version: 1.9.0

Production Compose Version

The docker-compose-production.yml file pins specific versions. Remember to update this file when releasing, as it's used for production deployments.

Release Types

Type	Example	When
Major	1.8.0 → 2.0.0	Breaking changes
Minor	1.8.0 → 1.9.0	New features, backward compatible
Patch	1.8.0 → 1.8.1	Bug fixes, small improvements

Quick Reference

# Full release workflow (replace X.Y.Z with actual version)
# 1. Edit version files
vim package.json docker/Dockerfile README.md src/skills/SKILL.md src/skills/server/docker-compose-production.yml

# 2. Commit changes
git add package.json docker/Dockerfile README.md src/skills/SKILL.md src/skills/server/docker-compose-production.yml
git commit -m "chore: bump version to X.Y.Z"

# 3. Create annotated tag
git tag -a vX.Y.Z -m "Release vX.Y.Z"

# 4. Push tag to trigger CI
git push origin vX.Y.Z

# 5. Verify
gh run watch
gh release view vX.Y.Z

Release Automation Skill

Purpose

Automate the release process for the Madeinoz Knowledge System, including version synchronization across all files, git tagging, and triggering the CI workflow.

When to Use

Use this skill when:

Creating a new release (major, minor, or patch version)
Bumping the version number
Tagging a release commit
Pushing a release to trigger CI workflow
Synchronizing version numbers across multiple files

Version Sync Locations

The following files MUST be updated with the new version:

Primary Version Files

package.json (line 3)
```
"version": "X.Y.Z"
```
docker/Dockerfile (line 8)
```
LABEL version="X.Y.Z"
```

README.md (line 6)

pack-id: madeinoz67-madeinoz-knowledge-system-core-vX.Y.Z

src/skills/SKILL.md (line 3)
```
version: X.Y.Z
```

Production Docker Compose (Manual Update)

src/skills/server/docker-compose-production.yml (line 85)

image: ghcr.io/madeinoz67/madeinoz-knowledge-system:X.Y.Z

Note: All other docker-compose files use :latest tag and do NOT need updates.

Do NOT Edit

CHANGELOG.md - Auto-generated by git-cliff workflow
Modifying this file will conflict with automated changelog generation

Pre-Release Checklist

Before creating a release, verify:

# 1. Check you're on main branch
git branch --show-current  # Should output: main

# 2. Pull latest changes
git pull origin main

# 3. Verify working tree is clean (no uncommitted changes)
git status  # Should show: "nothing to commit, working tree clean"

# 4. Verify latest CI passed
gh run list --limit 1  # Check status is "completed success"

Release Workflow

Step 1: Update Version Numbers

Manually edit the version files listed above. For example, bumping from 1.8.0 to 1.9.0:

# Edit package.json
# Edit docker/Dockerfile
# Edit README.md
# Edit src/skills/SKILL.md
# Edit src/skills/server/docker-compose-production.yml

Step 2: Commit Version Changes

git add package.json docker/Dockerfile README.md src/skills/SKILL.md src/skills/server/docker-compose-production.yml
git commit -m "chore: bump version to X.Y.Z"

Step 3: Create Annotated Tag

# Single-line description
git tag -a vX.Y.Z -m "Release vX.Y.Z"

# OR multi-line description (opens editor)
git tag -a vX.Y.Z

In the editor, use this format:

Release X.Y.Z

Summary of what's in this release:
- Feature one
- Bug fix two
- Improvement three

Step 4: Push Tag to Trigger CI

git push origin vX.Y.Z

This triggers the CI workflow which:

Generates changelog from git-cliff
Updates CHANGELOG.md on main branch
Builds and pushes multi-arch Docker image to GHCR
Creates GitHub Release with formatted release notes
Deploys documentation to GitHub Pages

Verification

After pushing the tag:

# Watch workflow run
gh run watch

# Confirm release created
gh release view vX.Y.Z

# Verify Docker image on GHCR
# https://github.com/madeinoz67/madeinoz-knowledge-system/pkgs/container/madeinoz-knowledge-system

Common Pitfalls

DO NOT Use `gh release create` Directly

❌ Wrong: gh release create vX.Y.Z --notes "Release notes"

This creates the tag via GitHub API without triggering the CI workflow. The release job will never run, leaving a broken release (no Docker image pushed, no docs deployed).

✅ Correct: git push origin vX.Y.Z

This triggers the push event for the tag, which runs the CI workflow.

DO NOT Edit CHANGELOG.md

❌ Wrong: Manually editing CHANGELOG.md

This file is auto-generated by git-cliff during the CI workflow. Manual edits will be overwritten.

✅ Correct: Use conventional commit messages. The changelog is generated from commit history.

Version Inconsistency

Ensure all version files use the exact same version string:

package.json: "version": "1.9.0"
Dockerfile: LABEL version="1.9.0"
README.md: pack-id: madeinoz67-madeinoz-knowledge-system-core-v1.9.0"
SKILL.md: version: 1.9.0

Production Compose Version

The docker-compose-production.yml file pins specific versions. Remember to update this file when releasing, as it's used for production deployments.

Release Types

Type	Example	When
Major	1.8.0 → 2.0.0	Breaking changes
Minor	1.8.0 → 1.9.0	New features, backward compatible
Patch	1.8.0 → 1.8.1	Bug fixes, small improvements

Quick Reference

# Full release workflow (replace X.Y.Z with actual version)
# 1. Edit version files
vim package.json docker/Dockerfile README.md src/skills/SKILL.md src/skills/server/docker-compose-production.yml

# 2. Commit changes
git add package.json docker/Dockerfile README.md src/skills/SKILL.md src/skills/server/docker-compose-production.yml
git commit -m "chore: bump version to X.Y.Z"

# 3. Create annotated tag
git tag -a vX.Y.Z -m "Release vX.Y.Z"

# 4. Push tag to trigger CI
git push origin vX.Y.Z

# 5. Verify
gh run watch
gh release view vX.Y.Z

release

Release Automation Skill

Purpose

When to Use

Version Sync Locations

Primary Version Files

Production Docker Compose (Manual Update)

Do NOT Edit

Pre-Release Checklist

Release Workflow

Step 1: Update Version Numbers

Step 2: Commit Version Changes

Step 3: Create Annotated Tag

Step 4: Push Tag to Trigger CI

Verification

Common Pitfalls

DO NOT Use gh release create Directly

DO NOT Edit CHANGELOG.md

Version Inconsistency

Production Compose Version

Release Types

Quick Reference

Related Documentation

Mais deste repositório

Mais deste repositório

Release Automation Skill

Purpose

When to Use

Version Sync Locations

Primary Version Files

Production Docker Compose (Manual Update)

Do NOT Edit

Pre-Release Checklist

Release Workflow

Step 1: Update Version Numbers

Step 2: Commit Version Changes

Step 3: Create Annotated Tag

Step 4: Push Tag to Trigger CI

Verification

Common Pitfalls

DO NOT Use gh release create Directly

DO NOT Edit CHANGELOG.md

Version Inconsistency

Production Compose Version

Release Types

Quick Reference

Related Documentation

DO NOT Use `gh release create` Directly

DO NOT Use `gh release create` Directly