releaselisted

# Git Release Skill Prepare release text and publish it with the forge's own CLI — `gh` for GitHub, `glab` for GitLab. Use only when the user asks for a release, a draft, or release notes. ## Workflow 1. **Read the strategy** — find the `<!-- skrrt:branching -->` block in `CLAUDE.md`, `AGENTS.md`, `.claude/CLAUDE.md`, or `.github/AGENTS.md` (first match). No block found → tell the user to run `/setup` and stop. 2. **Detect the forge:** ```bash bash "${CLAUDE_SKILL_DIR}/scripts/detect-forge-cli.sh" ``` Continue only when `FORGE` and `MATCHED_CLI` agree (`github`/`gh`, `gitlab`/`glab`); otherwise stop and report the mismatch. 3. **Validate the release context.** GitHub Flow / Trunk-Based: tag a commit on `main` — switch to `main` and pull first. Gitflow: the `release/*` (or `hotfix/*`) branch must already be merged to `main`; if not, stop and tell the user to open that PR with `/pr`. After tagging, remind them of the sync-back PR to `develop`. 4. `git fetch origin --tags`, then inspect tags and history for the release range (`git describe --tags --abbrev=0`, `git log --oneline <range>`). That command fails on a repo with no tags — treat that as the initial release: run the range from the root commit (`git log --oneline $(git rev-list --max-parents=0 HEAD)..HEAD`), say in the notes that no previous release tag was found, and omit the compare link. 5. Draft the notes, update an existing `CHANGELOG.md` if the repo has one, then pub