Release Manager

Release Manager Skill

This skill defines the standard procedure for releasing a new version of LibrAgent. You (the Agent) act as the Release Manager, responsible for understanding the changes, updating both CHANGELOG.md and user documentation (docs/ & website/), and communicating them clearly to users on the project site.

Workflow Overview

1. Analyze: Read git history and diffs to understand what changed.
2. Document & Sync Docs:
   • Intelligently update CHANGELOG.md with a user-facing summary.
   • Update user documentation (docs/user/) and project site pages (website/) so new features, UI changes, and guides stay up-to-date.
   • Run pnpm docs:build to verify VitePress documentation site builds cleanly.
3. Commit Docs & Changelog: Commit changelog and doc updates so release scripts run on a clean git state.
4. Verify & Publish: Use release scripts to run checks, bump versions, tag, and push.

Step-by-Step Instructions

1. Analysis (The "Brain" Work)

First, determine what has changed since the last release.

# Find the last tag
git describe --tags --abbrev=0

# Define baseline tag
LAST_TAG=$(git describe --tags --abbrev=0)

# List commits since that tag (exclude merge noise)
git log ${LAST_TAG}..HEAD --no-merges --pretty=format:"%h %s"

# Inspect impact scope and file diffs
git diff --name-only ${LAST_TAG}..HEAD
git diff --shortstat ${LAST_TAG}..HEAD

Task: Read the commit messages and diffs. Group them into:

• New Features & Capabilities: New tools, assistants, UI features, slash commands.
• User-facing Fixes: Bug fixes, reliability improvements.
• Internal / Refactoring: Code cleanup, dev scripts, testing.

2. Update Changelog & User Documentation

A. Update CHANGELOG.md

• Format: Follow existing style (## [Version] - YYYY-MM-DD).
• Content: Summarize changes concisely with emojis (🚀, 🐛, 🔧).
• Versioning Rule: Prepare patch/minor/major bump section (e.g. ## [0.8.40] - YYYY-MM-DD).

B. Synchronize User Documentation (docs/ & website/)

Critical: Do not let project documentation become outdated during releases!

1. Identify Affected User Guides:
   • Check if new features require updates to existing guides under docs/user/guides/ (e.g. assistants.md, skills.md, custom-mcp.md, sessions.md, automation.md).
   • Check if getting-started pages (docs/user/getting-started/) or FAQ (docs/user/faq/) need new entries.
2. Update Multilingual Docs (if applicable):
   • Synchronize both Korean (docs/user/) and English (docs/user/en/) documentation when features change.
3. Verify VitePress Site Build:

   pnpm docs:build
   

   Ensure VitePress renders pages cleanly without broken links or missing assets.

3. Commit Documentation & Changelog

Commit all documentation and changelog updates so the release script runs on a clean working tree:

git add CHANGELOG.md docs/ website/
git commit -m "docs: update changelog and user documentation for v<NEW_VERSION>"

Critical: Release scripts require a clean working tree before execution. Make sure changelog and doc edits are committed first.

4. Verification & Publishing (The "Grunt" Work)

Finally, use the provided scripts to handle mechanical steps: tests, build checks, version bump, commit, tag, and push.

# Linux/macOS
./scripts/release.sh <patch|minor|major|x.y.z>

# Windows PowerShell
./scripts/release.ps1 <patch|minor|major|x.y.z>

• Checks: Scripts abort on failed checks (pnpm test:run, pnpm rust:test, pnpm build, cargo check).
• Automation: Scripts run scripts/bump-version.cjs, which automatically synchronizes direct download links inside root READMEs (README.md, README.ko.md, etc.), updates version manifests (package.json, Cargo.toml, Cargo.lock, tauri.conf.json), commits, tags (v<NEW_VERSION>), and pushes.

Quick Release Checklist

1. Confirm baseline tag and diff scope.
2. Draft user-facing CHANGELOG.md section.
3. Synchronize user docs under docs/user/ & project site (website/).
4. Run pnpm docs:build to verify VitePress site build.
5. Commit changelog and documentation updates (git commit -m "docs: update changelog and user documentation for v<NEW_VERSION>").
6. Run release script with patch/minor/major or explicit x.y.z.
7. Verify branch push + tag push completed successfully.
8. Confirm GitHub Actions release workflow started.

Merge Policy (Required)

When merging a release PR (dev/0.8.x → main):

• Always use Create a merge commit.
• Never use squash merge — it breaks history alignment with the long-lived dev branch.
• After merge, sync main back into dev/0.8.x (git merge origin/main + push).