Skip to content
Back to skills

Make Release

ASecurity

Ship Holix through GitHub: open a PR, wait until Actions are green (fix code if needed), merge to main, then cut the next numbered GitHub release. Use when the user says «сделай релиз», «сделать релиз», «make a release», «create release», «cut a release», or runs /make-release.

  • 16 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 3, 2026
ai-agentspythonbashnodegit

Works with

  • cli

Security analysis

A100/100

Scanned September 3, 2026

npx -y skills add javded-itres/Holix --skill make-release --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Make Release?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Make Release
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/javded-itres-make-release/badge)](https://www.skillsdirectory.com/skills/javded-itres-make-release)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: make-release
description: >
  Ship Holix through GitHub: open a PR, wait until Actions are green (fix
  code if needed), merge to main, then cut the next numbered GitHub release.
  Use when the user says «сделай релиз», «сделать релиз», «make a release»,
  «create release», «cut a release», or runs /make-release.
---

# Holix release («сделай релиз»)

When the user says **сделай релиз** (or equivalent), execute this pipeline
end-to-end. Do not stop after the PR. Do not skip CI. Do not tag before merge.

Canonical package rules: `RULES.md` §8. This skill is the operational loop.

## Preconditions

- Repo: `javded-itres/Holix`. Default branch: `main`.
- Auth: `gh auth status` must be logged in.
- Fetch first: `git fetch origin --tags`.
- Next version = latest GitHub release + **patch** (`1.0.7` → `1.0.8`), unless
  the user asked for minor/major.
- Confirm versions agree before tagging:
  - `pyproject.toml` `[project].version`
  - `cli/__init__.py` `__version__`
  - latest `gh release list` / `git tag`
- Do **not** rsync/scp/hotfix production. Tag on `main` is enough: GHA
  `GitHub Release` + `Publish to PyPI` run from `vX.Y.Z`.
- Run `./scripts/lint.sh` (or `--fix`) before every push.

## 1) PR with the changes

Include **code + version bump + changelog** in the same PR so there is one
merge, then a tag.

1. If an open PR already covers this work, reuse it and add the bump there
   if missing.
2. Otherwise branch from up-to-date `origin/main`:
   `release/X.Y.Z` (example: `release/1.0.8`).
3. Commit the user's uncommitted/unmerged work (no secrets, no
   `node_modules/`, no local `.env`).
4. Bump version with `scripts/versioning.py` (or edit both files):
   - `pyproject.toml`
   - `cli/__init__.py`
5. Update `docs/CHANGELOG.md`:
   - Move `## Unreleased` notes into `## X.Y.Z — YYYY-MM-DD`
   - Leave a fresh empty `## Unreleased`
   - Write Added/Fixed/Tests from the actual diff
6. Push and open PR → `main`:

```bash
gh pr create --base main --title "Holix X.Y.Z" --body "$(cat <<'EOF'
## Summary
Release Holix X.Y.Z.

## Checklist
- [ ] Version matches in pyproject.toml and cli/__init__.py
- [ ] docs/CHANGELOG.md has section X.Y.Z
- [ ] CI green (ruff + pytest matrix)

After merge: tag `vX.Y.Z` (creates GitHub Release + PyPI).
EOF
)"
```

## 2) GitHub tests until green

Watch **GitHub Actions on the PR**, not only local pytest.

```bash
gh pr checks <n> --watch
# or
gh run watch <run-id>
```

On failure:

1. `gh run view <id> --log-failed` (or job logs).
2. Fix the code / tests / ruff.
3. Local: `./scripts/lint.sh` then targeted pytest.
4. Commit, push, re-watch.

Repeat until **every** required check is green. Do not merge red CI.
If a failure needs a product decision, stop and ask — do not paper over it.

## 3) Merge into `main`

User already authorized merge as part of this command.

```bash
gh pr merge <n> --merge --delete-branch
```

Use `--squash` only if the user asked. Wait until the PR is `MERGED`.
Then `git checkout main && git pull origin main`.

Verify `main` now has version `X.Y.Z`.

## 4) Next numbered GitHub release

Tag **must** match `pyproject.toml`. Do not create a GitHub release by hand
if the tag workflow can do it.

```bash
git checkout main
git pull origin main
python -c "import tomllib; print(tomllib.load(open('pyproject.toml','rb'))['project']['version'])"
git tag vX.Y.Z
git push origin vX.Y.Z
```

Watch:

- `GitHub Release` → https://github.com/javded-itres/Holix/releases/tag/vX.Y.Z
- `Publish to PyPI`

```bash
gh run list --branch vX.Y.Z --limit 5
gh release view vX.Y.Z
```

If the tag workflow fails because CHANGELOG has no `## X.Y.Z` section, fix
on a follow-up PR, delete/re-push the tag only with `--force-with-lease`
after saying so. Prefer a new patch over rewriting a published tag.

## Report back

When done, reply with:

- PR URL and merge SHA
- Version `X.Y.Z` / tag `vX.Y.Z`
- Release URL
- CI + PyPI workflow status

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.