releaselisted

# Release Kiroshi This skill calls `scripts/release.ts`. It never edits that script or `.github/workflows/`. ## 1. Preflight One call: ```bash ANCHOR=$(git log -1 --format=%H --grep='^chore(app): release v' HEAD) echo "branch: $(git rev-parse --abbrev-ref HEAD)" echo "dirty: $(git status --porcelain | wc -l)" echo "notes: $(grep -c -- '--notes' scripts/release.ts)" git log ${ANCHOR:+$ANCHOR..}HEAD --no-merges --format='%s' ``` The anchor is the last release **commit** reachable from HEAD, not the last tag: releases land on `main` squash-merged, so `v*` tags are usually unreachable and `git describe` fails. The grep matches the commit message `scripts/release.ts` writes, so the two stay in step. No anchor means no release yet — the range is the whole history. Stop, and publish nothing, when: - The commit list is empty — say nothing has landed since the last release. - `notes:` is `0` — `scripts/release.ts` does not carry `--notes` yet, so the notes would be silently dropped. Say so and stop. - `dirty:` is non-zero — the script refuses a dirty tree. Ask what to do; never commit or stash on your own. ## 2. Version Use `$ARGUMENTS` when it is `patch`, `minor`, or `major`. Otherwise ask with `AskUserQuestion`, recommending what the commits justify: a new capability → `minor`, fixes and polish only → `patch`. While the version is `0.x`, a breaking change is also `minor` — never propose `major` without being asked for it. ```bash bun run release <type> --dry-run ``` It