Run any Skill in Manus with one click

release-management

Stars128

Forks5

UpdatedApril 15, 2026 at 07:42

Release checklist, version strategy, and publishing workflow for JSR/npm. Use when bumping versions, creating releases, or managing the release pipeline.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

eser

eser/stack

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

2 files

SKILL.md

readonly

name	release-management
description	Release checklist, version strategy, and publishing workflow for JSR/npm. Use when bumping versions, creating releases, or managing the release pipeline.

Release Management

Unified release process for 29+ synchronized packages.

Quick Start

deno task validate — verify clean state
deno task cli codebase versions <patch|minor|major> — bump all packages
Update CHANGELOG.md — move Unreleased to new version section
PR to main → merge triggers JSR + npm publish

Key Principles

All packages share one version — no independent releases
JSR primary (OIDC auth), npm secondary (only @eserstack/cli as eser)
patch: bug fixes, docs, deps. minor: new features. major: breaking changes
Always update CHANGELOG before releasing
Tag format: vx.y.z (triggers release-notes-sync workflow)

Anti-Patterns

"I'll just edit one package's version" No. Use the version-bump script. Manual edits break synchronization.

"Skip the changelog, it's a small fix" No. Every release needs a changelog entry for traceability.

References

See rules.md for full release checklist and hotfix process.

More from this repository

same repository

javascript-practices

eser/stack

JavaScript/TypeScript conventions: ES modules, Deno runtime, React patterns, async/await, and type handling. Use when writing .ts, .tsx, or .js files, configuring imports, or building React components.

2026-04-15128

tooling-standards

eser/stack

Development tooling: Deno runtime, JSR package registry, deno.json and package.json configuration, and editor settings. Use when setting up projects, choosing packages, or configuring build tools.

2026-04-15128

agent-guidelines

eser/stack

Agent roles, safety rules, file ownership, and cross-package change protocol. Use when AI agents work on this codebase, plan multi-package changes, or need boundary guidance.

2026-04-15128

security-practices

eser/stack

Security practices: secrets in env vars, input validation, SSRF prevention, error sanitization, and production hardening. Use when handling authentication, secrets, user input, or preparing production deployments.

2026-04-15128

architecture-guidelines

eser/stack

System architecture: ES modules, hexagonal architecture, project structure, ADRs, and testing strategy. Use when designing systems, planning directory layout, writing ADRs, or reviewing architecture.

2026-04-15128

ci-cd-practices

eser/stack

CI/CD operations: GitHub Actions, Kubernetes, ArgoCD, and CI timeout configuration. Use when configuring pipelines, debugging deployments, or working with GitHub Actions. Do NOT use for general development workflow.

2026-04-15128

name	release-management
description	Release checklist, version strategy, and publishing workflow for JSR/npm. Use when bumping versions, creating releases, or managing the release pipeline.

Release Management

Unified release process for 29+ synchronized packages.

Quick Start

deno task validate — verify clean state
deno task cli codebase versions <patch|minor|major> — bump all packages
Update CHANGELOG.md — move Unreleased to new version section
PR to main → merge triggers JSR + npm publish

Key Principles

All packages share one version — no independent releases
JSR primary (OIDC auth), npm secondary (only @eserstack/cli as eser)
patch: bug fixes, docs, deps. minor: new features. major: breaking changes
Always update CHANGELOG before releasing
Tag format: vx.y.z (triggers release-notes-sync workflow)

Anti-Patterns

"I'll just edit one package's version" No. Use the version-bump script. Manual edits break synchronization.

"Skip the changelog, it's a small fix" No. Every release needs a changelog entry for traceability.

References

See rules.md for full release checklist and hotfix process.