원클릭으로 Manus에서 모든 스킬 실행

release

스타3

포크1

업데이트2026년 2월 2일 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.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

madeinoz67

madeinoz67/madeinoz-knowledge-system

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

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

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

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

이 저장소의 다른 Skills

이 저장소의 다른 Skills

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