What makes GitHub Release Workflow notable?

1K downloads. Trust evidence available

How should GitHub Release Workflow be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

GitHub Release Workflow

Professional GitHub release workflow. Use when: (1) releasing a new version, (2) managing versions and tags, (3) following conventional commits, (4) updating... Skill: GitHub Release Workflow Owner: weapon3k Summary: Professional GitHub release workflow. Use when: (1) releasing a new version, (2) managing versions and tags, (3) following conventional commits, (4) updating... Tags: git:1.0.0, github:1.0.0, latest:1.1.0, release:1.0.0, workflow:1.0.0 Version history: v1.1.0 | 2026-02-22T07:14:46.155Z | user Add README update requirement for releases v1.0.0 | 2026-02-21T17:02:5

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.0k

Updated

Oct 11, 2026

Version

1.1.0

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1K downloads reported by the source. Last updated 10/11/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 11, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 11, 2026
Adoption signal: 1K downloadsadoption · observed Oct 11, 2026
Latest release: 1.1.0release · observed Feb 22, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: medium.

clawhub skill install s17271j5cae09sx67cb1fya3vh885sfv:github-release-workflow

Python environment detected. Create a strict virtual environment (`python -m venv .venv`) before installing dependencies to prevent system-level package conflicts.
Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.
Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-weapon3k-github-release-workflow/snapshot"

Run-check

$0.02 USD

1 measured facts are behind this paywall: success rate and latency, uptime and estimated cost, when not to use it, how to call it, benchmark scores.

Agents pay $0.02 in USDC. A card payment is $0.50, the smallest a card allows.

Documentation

CLAWHUB

20,426 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: github-release-workflow
description: "Professional GitHub release workflow. Use when: (1) releasing a new version, (2) managing versions and tags, (3) following conventional commits, (4) updating README and docs, (5) setting up CI/CD for releases."
metadata:
  {
    openclaw: { emoji: "🚀" },
  }
---

# GitHub Release Workflow Skill

A standardized workflow for professional GitHub releases.

**IMPORTANT: Always update README.md and documentation before releasing!**

## Prerequisites

- Git installed
- GitHub CLI (`gh`) authenticated
- Git repository initialized

## Quick Commands

### Full Release Flow

```bash
# 1. Ensure clean working tree
git status

# 2. Run tests and format
pip install -e ".[dev]"
pytest
black lib/ tests/

# 3. Update version in pyproject.toml
# Edit: version = "2.1.0"

# 4. Update CHANGELOG.md
# Add new section with today's date

# 5. Update README.md (IMPORTANT!)
# - Update version badge
# - Update features list
# - Update project structure if changed
# - Update roadmap table

# 6. Update other docs as needed
# - docs/*.md
# - API documentation
# - Examples

# 7. Stage and commit
git add .
git commit -m "release: v2.1.0 - Description"

# 8. Create tag
git tag -a v2.1.0 -m "Version 2.1.0"

# 9. Push
git push
git push origin v2.1.0
```

### README Update Checklist

When releasing a new version, always update README.md:

| Item | Description |
|------|-------------|
| Version badge | Update `version-x.x.x-blue` |
| Features list | Add new features, remove deprecated |
| Project structure | Reflect new files/directories |
| Installation | Update if deps changed |
| Usage | Add new examples if needed |
| Roadmap | Move current version to done, add next |
| API docs | Update if API changed |

### Conventional Commits Format

```
<type>(<scope>): <description>

Types: feat, fix, docs, style, refactor, test, chore, release
```

Examples:
- `feat(memory): add SQLite support`
- `fix(vitality): correct energy calculation`
- `docs: update README`

### Version Format

```
MAJOR.MINOR.PATCH
- MAJOR: Breaking changes
- MINOR: New features (backward compatible)
- PATCH: Bug fixes
```

## Branch Strategy

```
main (stable)
  ↑
develop (integration)
  ↑
feature/* (new features)
```

## GitHub Release (Optional)

```bash
gh release create v2.1.0 \
  --title "Version 2.1.0" \
  --notes "Release notes"
```

## See Also

- Full specification: `github-release-workflow/SPEC.md`
- Keep a Changelog: https://keepachangelog.com/
- Semantic Versioning: https://semver.org/
- Conventional Commits: https://www.conventionalcommits.org/

README.md

# GitHub Release Workflow

<p align="center">
  <img src="https://img.shields.io/badge/version-1.0.0-blue" alt="Version">
  <img src="https://img.shields.io/badge/python-3.10+-green" alt="Python">
  <img src="https://img.shields.io/badge/license-MIT-orange" alt="License">
</p>

> A standardized workflow for professional GitHub releases.

## Overview

This project provides a complete specification and CLI tool for professional GitHub releases, following industry best practices:

- **Conventional Commits** — Clear commit message format
- **Semantic Versioning** — Standard version numbers
- **Keep a Changelog** — Structured changelog
- **GitHub Releases** — Tagged releases with notes

## Installation

```bash
git clone https://github.com/weapon3k/github-release-workflow.git
cd github-release-workflow
pip install -e .
```

## Quick Start

```bash
# Initialize git (first time)
gh-release init

# Create a release
gh-release release v1.0.0

# Check status
gh-release status

# View log
gh-release log -n 10
```

## Workflow

### 1. Prepare

```bash
# Ensure clean working tree
git status
pytest
black .
```

### 2. Update

- Update version in `pyproject.toml`
- Add entry to `CHANGELOG.md`

### 3. Release

```bash
git add .
git commit -m "release: v1.0.0"
git tag -a v1.0.0 -m "Version 1.0.0"
git push
git push origin v1.0.0
```

## Commit Format

```
<type>(<scope>): <description>

Types: feat, fix, docs, style, refactor, test, chore, release
```

## Version Format

```
MAJOR.MINOR.PATCH
```

- **MAJOR**: Breaking changes
- **MINOR**: New features (backward compatible)
- **PATCH**: Bug fixes

## Files

- `SPEC.md` — Full specification
- `SKILL.md` — OpenClaw skill definition
- `release.py` — CLI tool

## See Also

- [Conventional Commits](https://www.conventionalcommits.org/)
- [Semantic Versioning](https://semver.org/)
- [Keep a Changelog](https://keepachangelog.com/)

---

**License**: MIT

_meta.json

{
  "ownerId": "kn71685jv7z3r8kfqpg450k4dd81kkd8",
  "slug": "github-release-workflow",
  "version": "1.1.0",
  "publishedAt": 1771744486155
}

SPEC.md

# GitHub Release Workflow Specification

> A standardized workflow for professional GitHub releases.

## Overview

This specification defines a professional release workflow for Python projects, inspired by industry best practices.

## Prerequisites

- Git installed
- GitHub CLI (`gh`) authenticated
- Python 3.10+
- Git repository initialized

## Release Workflow

### 1. Pre-Release Checklist

```bash
# Ensure clean working tree
git status

# Update dependencies
pip install -e ".[dev]"

# Run tests
pytest

# Format code
black lib/ tests/

# Type checking (optional)
mypy lib/
```

### 2. Update Version

Update version in:
- `pyproject.toml` → `version`
- `CHANGELOG.md` → Add new version header

```bash
# Example: bump to 2.1.0
# Edit pyproject.toml: version = "2.1.0"
```

### 3. Update Changelog

Add new section in `CHANGELOG.md`:

```markdown
## [2.1.0] - YYYY-MM-DD

### Added
- New feature 1
- New feature 2

### Changed
- Improvement 1

### Fixed
- Bug fix 1

### Removed
- Deprecated feature 1
```

### 4. Stage Changes

```bash
git add .
git status
```

### 5. Commit

Follow [Conventional Commits](https://www.conventionalcommits.org/):

```bash
git commit -m "release: v2.1.0 - Added new features and improvements"
```

### 6. Create Tag

```bash
git tag -a v2.1.0 -m "Version 2.1.0: Release description"
```

### 7. Push

```bash
git push
git push origin v2.1.0
```

### 8. Create GitHub Release (Optional)

```bash
gh release create v2.1.0 \
  --title "Version 2.1.0" \
  --notes "Release notes from CHANGELOG.md"
```

## Branch Strategy

```
main (stable)
  ↑
develop (integration)
  ↑
feature/* (new features)
  ↑
hotfix/* (urgent fixes)
```

### Branch Types

| Branch | Purpose | Base | Merge To |
|--------|---------|------|----------|
| `main` | Stable releases | - | - |
| `develop` | Integration | main | main |
| `feature/*` | New features | develop | develop |
| `hotfix/*` | Urgent fixes | main | main, develop |
| `release/*` | Release prep | develop | main, develop |

## Versioning

Follow [Semantic Versioning](https://semver.org/):

```
MAJOR.MINOR.PATCH
  │    │    │
  │    │    └── Bug fixes
  │    └─────── New features (backward compatible)
  └─────────── Breaking changes
```

### Version Format

- **Release**: `v2.1.0` (annotated tag)
- **Pre-release**: `v2.1.0-alpha.1`, `v2.1.0-beta.1`
- **Build**: `v2.1.0+build.123`

## Commit Message Format

### Conventional Commits

```
<type>(<scope>): <description>

[optional body]

[optional footer(s)]
```

### Types

| Type | Description |
|------|-------------|
| `feat` | New feature |
| `fix` | Bug fix |
| `docs` | Documentation |
| `style` | Formatting |
| `refactor` | Code restructuring |
| `test` | Tests |
| `chore` | Maintenance |
| `release` | Version release |

### Examples

```bash
git commit -m "feat(memory): add SQLite storage support"
git commit -m "fix(vitality): correct energy decay calculation"
git commit -m "docs: update README with examples"
git commit -m "release: v2.1.0"
```

## CI

pyproject.toml

[build-system]
requires = ["setuptools>=61.0"]
build-backend = "setuptools.build_meta"

[project]
name = "github-release-workflow"
version = "1.1.0"
description = "Professional GitHub release workflow specification"
readme = "README.md"
license = {text = "MIT"}
authors = [
    {name = "Steven", email = "[email protected]"}
]
keywords = ["git", "github", "release", "workflow", "cicd", "conventional-commits"]
classifiers = [
    "Development Status :: 4 - Beta",
    "Intended Audience :: Developers",
    "License :: OSI Approved :: MIT License",
    "Programming Language :: Python :: 3",
    "Programming Language :: Python :: 3.10",
    "Programming Language :: Python :: 3.11",
    "Programming Language :: Python :: 3.12",
]

dependencies = []

[project.scripts]
gh-release = "release:main"

[tool.setuptools.packages.find]
where = ["."]

Github ReposUpdated 2d agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.