tigerkit-release

TigerKit Release

In this repository, only when the user explicitly invokes /tigerkit-release. The default bump is patch.

Contract

The release baseline is not local guesswork but the remote mainconfirmed after fetch, the semantic version tag, and the GitHub Release. If the current request explicitly approves commit, push, tag, and release, do not ask again about the same scope. If the target version, included diff, or remote state is unclear, stop with Blockedbefore remote changes and get the user's decision.

If the user requests dry-run, a hypothetical scenario, or no command execution, use the provided state as evaluation input. Do not query or modify the actual repository or remote, and do not mix the current working tree's incidental state into the scenario. Report only the version to execute, the order, the stop conditions, and the expected receipt.

Follow this order.

1. git status, branch, upstream, remote, recent commits and tags, and GitHub Release.
2. git fetch After that, check the difference between the current branch and origin/main. Do not discard user changes or synchronize with force, hard reset, or clean.
3. Calculate the requested bump from the latest stable semantic version and check that the same tag and GitHub Release do not exist.
4. Read all changes to be included and check that unrelated files, secrets, credentials, .tigerkit/ runtime scratch are not tracked or staged.
5. Following the existing format, update CHANGELOG.mdand the necessary version notations. Do not bulk-replace versions in past release records.
6. Run the full verification, regression tests, and git diff --checkfrom the repository guidelines. Do not bypass failures or skip hooks.
7. Stage only specific files, recheck the staged diff, and then create a new commit. Do not amend existing commits.
8. Push the commit to the remote branch.
9. After the remote commit is confirmed, create a tag in the existing repository format and push it.
10. After confirming the tag exists on the remote, create a GitHub Release with gh release createand check the resulting URL.

If verification fails, the remote branch has advanced, an existing tag/release conflicts, or authentication fails, do not execute the next remote step. If partially successful, do not delete or overwrite already-created commits, tags, or releases; report the exact state and resume point.

Prohibited

• force push, reset --hard, clean, hook bypass
• Moving, deleting, or reusing existing tags
• Treating failed verification as success
• .tigerkit/, including credentials, tokens, and browser profiles
• Creating a tag before commit or a GitHub Release before tag confirmation

Completion gate and receipt

ReleasedUse only when commit push, remote tag, GitHub Release URL, and full verification evidence are all present. Report the following.

• Version: previous version and new version
• Included changes: main behavior and staged files
• Verification: executed commands and results
• Git: commit SHA, branch push, tag
• Release: URL
• Incomplete: steps that failed or could not be executed
• Status: Released | Blocked | Failed | Partial