gcontext/templates/release-ops/index.md at main

mirror of https://github.com/bleak-ai/gcontext.git synced 2026-08-11 13:19:23 +02:00

Files

T

bernatsamperaandClaude Opus 4.6 87d8575829 Fix template example runs: use per-step folders instead of flat files

The workflow spec requires one folder per step inside runs/example/
(e.g. 1-intake/results.md), not flat files. Fixed browser-recipes,
seo-pipeline, and support-ops. release-ops was already correct.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

2026-08-09 18:16:25 +02:00

2.3 KiB

Raw Permalink Blame History

id, name, description, parameters, connections, tags

name

description

parameters

connections

tags

release-ops

Release Ops

A release workflow that collects changes, drafts a changelog, bumps the version, publishes, and optionally announces. Each release is a searchable run; the workflow learns your changelog style and known blockers over time.

name	description	required
version	Target version (e.g. "0.5.0") or omit for agent proposal based on changes	false

name	description	required
scope	Limit to a specific package in a monorepo (e.g. "@acme/core")	false

kind	description
source-control	The git host where the repository lives (GitHub, GitLab, or similar)

kind	description
package-registry	The registry to publish to (PyPI, npm, crates.io, or similar). Optional; skip if the project has no published package.

kind	description
notification-sink	Where to post release announcements (Slack, Discord, email, or similar). Optional; skip if not needed.

release

ops

devtools

Ship a release with a repeatable six-step procedure. Each run takes one release from preflight to announcement, logs the result, and feeds learnings back into future runs.

The version parameter accepts an explicit semver string (e.g. "1.2.0") or can be omitted. When omitted, the agent proposes major/minor/patch based on the changes collected in step 1. The agent always asks for confirmation before applying a version bump.

The scope parameter is for monorepos. When set, the workflow limits change collection, version bumping, and publishing to the named package. When omitted, the workflow operates on the entire repository.

Run folders are named by version: v{version} (e.g. v0.5.0). If a second release happens the same day with the same version prefix, append -b (e.g. v0.5.0-b).

How it learns

The workflow accumulates knowledge in two ways:

Release history (releases/log.md): a table of every release with version, date, summary, and notes. The agent consults it to understand release cadence and past decisions.
Insights (releases/insights.md): created after the first run. Records the repo's changelog style (tone, grouping, detail level), known-flaky checks, common blockers, and workarounds. The agent consults this during preflight and changelog drafting.

2.3 KiB Raw Permalink Blame History

How it learns

2.3 KiB

Raw Permalink Blame History