Ejecuta cualquier Skill en Manus
con un clic

Ejecuta cualquier Skill en Manus con un clic

Comenzar

push-tag

Estrellas289

Forks53

Actualizado26 de marzo de 2026, 09:00

Push a version tag and optionally create a GitHub release

Instalación

Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.

Ejecutar en Manus

Fuente

spiriMirror

spiriMirror/libuipc

Abrir repositorio de GitHub Ver repositorios del creador

Descarga

Ejecutar en Manus

Ocupaciones relacionadasSOC

Basado en la clasificación ocupacional SOC

Desarrolladores de softwareOcupaciones informáticas y matemáticas·SOC 15-1252

SKILL.md

readonly

name	push-tag
description	Push a version tag and optionally create a GitHub release
disable-model-invocation	true

Push Tag

Overview

Push a new tag to the upstream repository. Optionally create a GitHub release.

Steps

Verify branch
```
git branch --show-current
```
- Must be on main branch. If not, switch: git checkout main
Determine tag version
```
git tag --list
```
- If user provides a tag: validate it doesn't exist and is greater than latest
- If no tag provided: auto-increment patch version (e.g., v1.2.3 → v1.2.4)

Create and push tag

git tag <TAG>
git push origin refs/tags/<TAG>

Create release (if requested)
- Generate structured release notes (do not use --generate-notes):
  1. Get commits between previous tag and <TAG>:
```
git log <PREV_TAG>..<TAG> --pretty=format:'%s' --no-merges
```
  2. Summarize and structure the changes into clear sections, e.g.:
    - Features – new functionality
    - Fixes – bug fixes
    - Documentation – docs, examples, guides
    - Refactor / Chore – internal changes, deps, tooling
  3. Write an overall summary at the top of the release notes: a short paragraph describing the key themes, goals, or highlights of this release compared to the previous one. This gives readers a quick understanding of what changed and why.
  4. Use concise, user-facing language. Group related changes. Avoid raw commit hashes or jargon unless helpful.
  5. Write notes to a temp file (e.g. release_notes.md) and create the release:
```
gh release create <TAG> --repo spiriMirror/libuipc --notes-file release_notes.md
rm release_notes.md
```

Note: Always use --repo spiriMirror/libuipc to reference the upstream repository.

Más de este repositorio

mismo repositorio

xmake-workflow

spiriMirror/libuipc

Build and test the libuipc project using XMake. Use when building with xmake, running xmake f / xmake build / xmake run commands, selecting release/releasedbg/debug modes, or running Catch2 tests produced by xmake.

2026-04-22289

cmake-workflow

spiriMirror/libuipc

Build and test the libuipc project using CMake. Use when building the project, running cmake configure/build commands, compiling with RelWithDebInfo, running Catch2 tests, or when the user asks how to build or test libuipc.

2026-04-21289

simulation-dev

spiriMirror/libuipc

General simulation development best practices for correctness, stability, and debuggability. Use when implementing or modifying simulation systems, solvers, constraints, or GPU kernels, especially for index safety, NaN/Inf issues, and diagnostics.

2026-04-21289

review-pr

spiriMirror/libuipc

Review a libuipc pull request end-to-end: checkout the PR, summarize changes, list files for the human reviewer, and perform a domain-aware AI review covering physics correctness, backend architecture, C++ style, GPU code, and Python bindings. Optionally post review comments via `gh`. Use when the user provides a PR number, asks to review a PR, or wants to inspect a libuipc GitHub PR.

2026-04-21289

commit-convention

spiriMirror/libuipc

Conventional commit message format and rules for this project

2026-03-06289

commit

spiriMirror/libuipc

Create a well-formatted conventional commit

2026-03-06289

name	push-tag
description	Push a version tag and optionally create a GitHub release
disable-model-invocation	true

Push Tag

Overview

Push a new tag to the upstream repository. Optionally create a GitHub release.

Steps

Verify branch
```
git branch --show-current
```
- Must be on main branch. If not, switch: git checkout main
Determine tag version
```
git tag --list
```
- If user provides a tag: validate it doesn't exist and is greater than latest
- If no tag provided: auto-increment patch version (e.g., v1.2.3 → v1.2.4)

Create and push tag

git tag <TAG>
git push origin refs/tags/<TAG>

Create release (if requested)
- Generate structured release notes (do not use --generate-notes):
  1. Get commits between previous tag and <TAG>:
```
git log <PREV_TAG>..<TAG> --pretty=format:'%s' --no-merges
```
  2. Summarize and structure the changes into clear sections, e.g.:
    - Features – new functionality
    - Fixes – bug fixes
    - Documentation – docs, examples, guides
    - Refactor / Chore – internal changes, deps, tooling
  3. Write an overall summary at the top of the release notes: a short paragraph describing the key themes, goals, or highlights of this release compared to the previous one. This gives readers a quick understanding of what changed and why.
  4. Use concise, user-facing language. Group related changes. Avoid raw commit hashes or jargon unless helpful.
  5. Write notes to a temp file (e.g. release_notes.md) and create the release:
```
gh release create <TAG> --repo spiriMirror/libuipc --notes-file release_notes.md
rm release_notes.md
```

Note: Always use --repo spiriMirror/libuipc to reference the upstream repository.