forge-releaselisted

# Forge Release The final step in the issue pipeline: `released → closed`. Lands the issue's own changes onto the production branch and triggers deployment. This is a lightweight skill — no codebase exploration, no review. Just land the diff, deploy, clean up. The ISS-* branch holds this issue's changes. Release = get **this issue's own changes — and only those** — onto `productionBranch`, then deploy and close. The one non-obvious trap is called out in Step 6. **State-never-lies (`VISION: state-never-lies`):** `merged_at` and the "Released" comment are promises other issues rely on — an issue held by a `blocks` edge dispatches the moment `merged_at` is stamped, trusting the base branch now has this code. Never let branch-name equality or a push exit code stand in for verified git ancestry (see Step 4 and Step 8) — a wrongly-skipped merge or a silently-failed push must halt the release, not complete it. ## Usage ``` /forge-release <documentId> ``` ## Tools - **forge_issues** — get issue data, update status - **forge_comments** — post release comment - **forge_config** — get baseBranch, productionBranch, Coolify config - **forge_coolify_deploy** — trigger production deploy (if configured) - **Bash** — git merge, push, branch cleanup ## Terminal-exit invariant This stage may end in exactly one of these states. There is no other legal exit: | Exit | Requires | |---|---| | `closed` | the verify-land gate returned LANDED, and the release comment is posted | | `reopen` |