Release Automation · Plugin

We ship 150+ packages through it.
Every time.

One plugin covers the full cycle: checks, build, changelog, npm publish, git tag. No scripts, no Notion runbook, no "I think I forgot to push the tag".

Documentation Install KB Labs

What it looks like

One run. Here's what happens.

kb release run

$ kb release run

  ╭─ Release Plan ───────────────────────────────────────────────╮
  │  12 package(s) · strategy: lockstep                          │
  │                                                              │
  │  ·  @kb-labs/core-types              1.4.1  →  1.4.2         │
  │  ·  @kb-labs/core-platform           1.4.1  →  1.4.2         │
  │  ·  @kb-labs/sdk                     1.4.1  →  1.4.2         │
  │  ·  @kb-labs/release-manager-core   1.4.1  →  1.4.2          │
  │  ·  ... 8 more packages                                      │
  ╰──────────────────────────────────────────────────────────────╯

Proceed with release? [y/N] y

  ~  [4.1s] Running 3 pre-release check(s)...
  ~  [18.2s] Building 12 package(s)...
  ~  [22.4s] Verifying package artifacts...
  ~  [23.0s] Updating package versions...
  ~  [25.1s] Generating changelog...
  ~  [27.3s] Publishing packages...
  ~  [44.8s] Committing and tagging release...
  ✓  Release completed

CHANGELOG.md · corporate-ai

markdown

## [1.4.2] - 2026-05-24

> **@kb-labs/release-manager-core** 1.4.1 → 1.4.2 (patch)

### Fixes
- Atomic build now correctly handles symlinks inside dist/
- Checkpoint detection skips stale entries older than 24h

### Internal
- Pipeline timing reported per-step in `kb release report`

Four built-in templates: corporate-ai, corporate, technical, compact. If the LLM is unavailable — falls back to a plain commit list.

Pipeline

Eight steps. Strict order.

Each step can run standalone. Each fails explicitly — with a clear message.

1Lint

ESLint across all affected packages. Fast — only what changed.

2Type-check

tsc project references in dependency order. Catches cross-package type errors.

3Test

Vitest with coverage. Skips packages with no changed files.

4AI Review

LLM reviews the diff for logic errors, security issues, and style violations.

5QA Gate

Package-level quality checks. Fails if degradation is detected.

6Impact

Dependency graph analysis — which packages and tests are actually affected.

7Build

Topological build with DTS. Only changed packages + dependents rebuild.

8Release

Publish to npm + GitHub Release with changelog. Gated by all prior stages.

Why it works this way

Three decisions that matter.

Workflows as code, not config

Release pipelines live in YAML under version control — reviewed, diffable, and revertable like any other change. No GUI state to export, no vendor format to migrate from.

Every stage is a plugin

Lint, review, QA, deploy — each step is a typed plugin with declared capabilities. Swap any stage without touching the rest of the pipeline.

Fail fast, trace everything

Stages run in order with explicit dependencies. The first failure stops the pipeline. Every run is fully traced: inputs, outputs, timing, and plugin calls.

--flow

Independent releases for different parts of the monorepo.

A flow is a named release profile. It fully replaces three things: which packages to build, the versioning strategy, and the set of checks. Everything else (registry, changelog, git) comes from the global config.

Platform and SDK release independently — one command each. 150+ packages, but never everything at once.

pnpm kb workflow run release

packages@kb-labs/core-platform, @kb-labs/sdkstrategyaffected

Runs lint → type-check → test → AI review → build → publish. Only changed packages.

pnpm kb workflow run release --all

packagesAll 35+ packagesstrategyfull

Force full pipeline regardless of git state. Used for major releases.

A flow fully replaces the global packages config — it doesn't merge. Packages are selected by glob patterns.

checks config

json

"checks": [
  {
    "id": "type-check",
    "command": "pnpm type-check",
    "runIn": "repoRoot"
  },
  {
    "id": "test",
    "command": "pnpm test",
    "runIn": "perPackage",
    "timeoutMs": 60000
  },
  {
    "id": "size-limit",
    "command": "pnpm size-limit --json",
    "parser": "json",
    "runIn": "scopePath",
    "optional": true
  }
]

Custom checks

Not just a list of commands.

Each check is an object with control over where and how it runs. Checks can be overridden at the flow level — platform and SDK have their own sets.

runIn: repoRootrunIn: perPackagerunIn: scopePathparser: jsonoptionaltimeoutMs

Configuration

Everything in one file. No extra config.

Config lives in .kb/kb.config.json alongside other KB Labs settings. No separate release.config.js.

release.workflow — path to the release workflow YAML
release.targets — which packages to include in the pipeline
release.gates — required stages that must pass before publish
release.aiReview — model and prompt config for AI review step
release.npm — registry URL, access level, and publish token