release-management

スター10

フォーク3

更新日2026年4月19日 11:35

Execute clean Atulya releases with preflight validation, version bumping, SDK regeneration, docs deployment verification, and recovery from failed release/doc workflows. Use when shipping patch/minor releases, tagging versions, or debugging why release/docs did not publish.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

ソース

eight-atulya

eight-atulya/atulya

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Release Management

Use this skill for end-to-end Atulya releases (0.x.y) with high reliability and low token usage.

Default Mode

Prefer deterministic scripts over ad-hoc edits.
Run validations before tag/push.
Treat release and docs as separate delivery checks.
For patch releases (x.y.z, z > 0), update existing docs version line (for example 0.8.z updates version-0.8 docs).

Fast Decision Tree

Need new release tag?
- Yes -> run full preflight + version bump + regenerate + commit + tag + push.
Release succeeded but docs site stale?
- Check docs workflow trigger path match and run state.
- If no run, push a tiny docs-only commit or trigger workflow_dispatch.
Tag already exists and failed previously?
- Do not reuse old tag.
- Cut next patch (0.8.3 after failed 0.8.2).

Clean Release Procedure

Run from repo root.

0) Pre-checks

git fetch origin
git pull --ff-only origin main
git status -sb
git branch --show-current
git tag -l "v<version>"

Requirements:

On main
Clean working tree
No existing v<version> tag

1) Validate release lane first

./scripts/release-preflight-v0800.sh <version>

If it fails:

Fix root cause first (do not tag).
Re-run until green.

2) Update versions + docs + generated artifacts

Preferred scripted path (fast path):

./scripts/release.sh <version>

Note:

release.sh is convenient, but it commits with --no-verify.
For strict governance, use manual lane + explicit lint/build checks before commit/tag.

If you are doing controlled/manual release prep instead:

./scripts/update-docs-version.sh <version>
./scripts/generate-openapi.sh
./scripts/generate-clients.sh

Then verify:

./scripts/hooks/lint.sh
cd atulya-cli && cargo check && cd ..
npm run build --workspace=atulya-docs
npm run build --workspace=atulya-control-plane

3) Commit release payload

git add -A
git commit -m "Release v<version>"

4) Tag and push

git tag -a v<version> -m "Release v<version>"
git push origin main
git push origin v<version>

5) Verify GitHub workflows

Check:

Release workflow for tag (.github/workflows/release.yml)
Docs workflow (.github/workflows/deploy-docs.yml)
GitHub Release page for v<version> assets

Release should be green before announcing.

Failure Playbook (Common)

A) Release run fails on Rust CLI build

Symptoms:

release-rust-cli job fails in release workflow.

Actions:

Reproduce locally:
```
cd atulya-cli && cargo check
```

Regenerate clients and re-check:

cd /path/to/repo
./scripts/generate-clients.sh
cd atulya-cli && cargo check

Commit fix on main.
Cut next patch tag (never mutate existing failed tag).

B) Release succeeded, docs did not update

Symptoms:

Release run green, docs site still old.
No new docs workflow run.

Likely cause:

Push event did not trigger docs workflow path filter.
Very large release commit may miss expected path-trigger behavior.

Actions:

Confirm docs workflow trigger:
- push on main
- paths include atulya-docs/**
Push tiny docs-only commit (preferred) OR run workflow_dispatch.
Re-verify docs deployment run success.

C) Tag exists but run failed

Do not re-use tag.

Use next patch:

failed v0.8.2 -> ship v0.8.3

D) Generated SDK drift after version bump

Actions:

Re-run generation in order:

./scripts/generate-openapi.sh
./scripts/generate-clients.sh

Re-run lint/build checks.
Commit regenerated outputs together.

Required Release Invariants

release-preflight-v0800.sh passes.
./scripts/hooks/lint.sh passes.
cargo check passes for atulya-cli.
Docs build passes.
Control plane build passes.
Tag is new and points to validated commit.

Output Template For Agents

After release operations, report:

Version/tag shipped
Commit SHA
Release workflow URL + status
Docs workflow URL + status
Any follow-up action required

Deep Reference

For full command matrix, troubleshooting, and recovery workflows, read:

release-runbook.md

このリポジトリの他の Skills

同じリポジトリ

atulya-dev-flow

eight-atulya/atulya

Disciplined development workflow for AI coding agents working in the Atulya monorepo — covers context gathering, branch hygiene, edit/lint/test cycle, API surface changes that require client regen, parallel vs sequential tool use, and the report-back template. Use at the start of any non-trivial Atulya coding task, or when the user asks how to "implement X", "port Y", "change the API", or "ship a feature" in this repo.

2026-07-2310

atulya-system-testing

eight-atulya/atulya

Run the Atulya repo through end-to-end system testing — toolchain check, lint, Python pytest, Rust cargo check, TypeScript build, control-plane typecheck, OpenAPI + client regen as a contract test, cross-client field smoke test, and legacy-leak audit. Use when validating a change before commit/PR, after pulling main, before a release, or when the user asks to "run all tests", "verify everything", "system sanity check", or "end-to-end test".

2026-07-2310

git-commit

eight-atulya/atulya

Design a meaningful git commit for the Atulya repo end-to-end — what commands to run to inspect the change, how to decide if it's one commit or several, how to write a message in this repo's `[type] ~ subject` convention with a structured body grouped by surface, and the exact `git add` / heredoc `git commit` invocations to use. Use whenever the user says "commit this", "git commit", "draft a commit message", "what should the commit be", or you've just finished a feature/fix and want to propose a commit before they ask.

2026-07-2310

atulya-docs

eight-atulya/atulya

Complete Atulya documentation for AI agents. Use this to learn about Atulya architecture, APIs, configuration, and best practices.

2026-07-2110

atulya-cortex

eight-atulya/atulya

Atulya Cortex (TUI/WhatsApp), Hand tools, internet stack (SearXNG/Firecrawl), config, and what-if troubleshooting. Use for cortex wiring, web_search/web_extract, deliberation limits, or docker internet-search compose.

2026-05-0510

code-review

eight-atulya/atulya

Review changed code against project standards. Checks for missing tests, dead code, type safety, lint issues, and coding conventions. Run after completing any implementation work.

2026-04-1910

name	release-management
description	Execute clean Atulya releases with preflight validation, version bumping, SDK regeneration, docs deployment verification, and recovery from failed release/doc workflows. Use when shipping patch/minor releases, tagging versions, or debugging why release/docs did not publish.

Release Management

Use this skill for end-to-end Atulya releases (0.x.y) with high reliability and low token usage.

Default Mode

Prefer deterministic scripts over ad-hoc edits.
Run validations before tag/push.
Treat release and docs as separate delivery checks.
For patch releases (x.y.z, z > 0), update existing docs version line (for example 0.8.z updates version-0.8 docs).

Fast Decision Tree

Need new release tag?
- Yes -> run full preflight + version bump + regenerate + commit + tag + push.
Release succeeded but docs site stale?
- Check docs workflow trigger path match and run state.
- If no run, push a tiny docs-only commit or trigger workflow_dispatch.
Tag already exists and failed previously?
- Do not reuse old tag.
- Cut next patch (0.8.3 after failed 0.8.2).

Clean Release Procedure

Run from repo root.

0) Pre-checks

git fetch origin
git pull --ff-only origin main
git status -sb
git branch --show-current
git tag -l "v<version>"

Requirements:

On main
Clean working tree
No existing v<version> tag

1) Validate release lane first

./scripts/release-preflight-v0800.sh <version>

If it fails:

Fix root cause first (do not tag).
Re-run until green.

2) Update versions + docs + generated artifacts

Preferred scripted path (fast path):

./scripts/release.sh <version>

Note:

release.sh is convenient, but it commits with --no-verify.
For strict governance, use manual lane + explicit lint/build checks before commit/tag.

If you are doing controlled/manual release prep instead:

./scripts/update-docs-version.sh <version>
./scripts/generate-openapi.sh
./scripts/generate-clients.sh

Then verify:

./scripts/hooks/lint.sh
cd atulya-cli && cargo check && cd ..
npm run build --workspace=atulya-docs
npm run build --workspace=atulya-control-plane

3) Commit release payload

git add -A
git commit -m "Release v<version>"

4) Tag and push

git tag -a v<version> -m "Release v<version>"
git push origin main
git push origin v<version>

5) Verify GitHub workflows

Check:

Release workflow for tag (.github/workflows/release.yml)
Docs workflow (.github/workflows/deploy-docs.yml)
GitHub Release page for v<version> assets

Release should be green before announcing.

Failure Playbook (Common)

A) Release run fails on Rust CLI build

Symptoms:

release-rust-cli job fails in release workflow.

Actions:

Reproduce locally:
```
cd atulya-cli && cargo check
```

Regenerate clients and re-check:

cd /path/to/repo
./scripts/generate-clients.sh
cd atulya-cli && cargo check

Commit fix on main.
Cut next patch tag (never mutate existing failed tag).

B) Release succeeded, docs did not update

Symptoms:

Release run green, docs site still old.
No new docs workflow run.

Likely cause:

Push event did not trigger docs workflow path filter.
Very large release commit may miss expected path-trigger behavior.

Actions:

Confirm docs workflow trigger:
- push on main
- paths include atulya-docs/**
Push tiny docs-only commit (preferred) OR run workflow_dispatch.
Re-verify docs deployment run success.

C) Tag exists but run failed

Do not re-use tag.

Use next patch:

failed v0.8.2 -> ship v0.8.3

D) Generated SDK drift after version bump

Actions:

Re-run generation in order:

./scripts/generate-openapi.sh
./scripts/generate-clients.sh

Re-run lint/build checks.
Commit regenerated outputs together.

Required Release Invariants

release-preflight-v0800.sh passes.
./scripts/hooks/lint.sh passes.
cargo check passes for atulya-cli.
Docs build passes.
Control plane build passes.
Tag is new and points to validated commit.

Output Template For Agents

After release operations, report:

Version/tag shipped
Commit SHA
Release workflow URL + status
Docs workflow URL + status
Any follow-up action required

Deep Reference

For full command matrix, troubleshooting, and recovery workflows, read:

release-runbook.md