github-release

Category: Tools & Productivity | Uploader: tksohishi | Downloads: 0 | Version: v1.0（Latest）

Release version $ARGUMENTS

Changelog: Source: GitHub https://github.com/tksohishi/dotfiles

Directory Structure

Current level: dotcodex/skills/.dotfiles/github-release/

📄 SKILL.md 2.6 KB

SKILL.md

---
name: "github-release"
description: "Release version $ARGUMENTS"
---

Use this skill when the user asks to run `/github-release`.


Release a new version of the current project. If a project-local `/github-release` command exists (`.claude/commands/github-release.md`), defer to it instead.

## Step 1: Determine version

If `$ARGUMENTS` specifies a version (e.g. `1.2.0`, `v1.2.0`), use that. Strip the leading `v` for the version number; use `v`-prefixed form for tags.

If no version argument is provided:

1. Find the latest tag: `git describe --tags --abbrev=0`
2. List commits since that tag: `git log $(git describe --tags --abbrev=0)..HEAD --oneline`
3. Assess what kind of bump is appropriate based on the commits:
   - **Major**: breaking changes (for pre-1.0 projects, breaking changes bump minor instead)
   - **Minor**: new features
   - **Patch**: bug fixes, docs, refactors
4. Present 2-3 version options to the user using AskUserQuestion, with reasoning for each

If there are no existing tags, suggest `0.1.0` or `1.0.0` and ask the user.

## Step 2: Detect project type and bump version

Check for manifest files in the project root and update the version accordingly:

**Swift** (`Package.swift` exists):
- Find and update `Info.plist` using `/usr/libexec/PlistBuddy -c "Set :CFBundleShortVersionString <version>" <path>/Info.plist`

**Python** (`pyproject.toml` exists):
- Update the `version` field in `pyproject.toml`
- Run `uv sync` if `uv.lock` exists

**Node** (`package.json` exists):
- Update the `version` field in `package.json`
- Do NOT run `npm version` or `pnpm version` (they auto-commit/tag)

**Go** (`go.mod` exists):
- Tag only; Go derives version from git tags

**Other** (Makefile, or version derived from git tags):
- No file updates needed; tag only

If none of the above match, ask the user whether any files need a version update.

## Step 3: Commit version changes

If any files were modified in Step 2:

```
git add <changed files>
git commit -m "Bump version to <version>"
```

Skip this step if no files were changed (tag-only projects).

## Step 4: Tag and push

```
git tag v<version>
git push --follow-tags
```

## Step 5: Verify the release

A GitHub Actions workflow automatically creates the release when a version tag is pushed. Verify it succeeded:

```
gh run list --limit 1
gh release view v<version>
```

If the workflow failed, check the logs with `gh run view <run-id> --log-failed` and inform the user.

## Constraints

- Follow semver; for pre-1.0 projects, minor = breaking
- Never add AI agent as commit author or co-author
- Use plain quoted strings for commit messages

Comments 0

Latest | Hot

Please login before commenting.

No comments yet. Be the first one!

github-release

Directory Structure

SKILL.md

Report

Notice