Release

---
name: release
description: Execute a release - run all issues in dependency order, then tag and ship
argument: <version> [--dry-run] [--continue] [--no-tag] | status [version]
tools: Bash, Read, Write, Edit, Glob, Grep, Task, Skill
---

# Release Execution

Execute a multi-issue release pipeline. Loads a release definition, calculates issue dependency order, runs `/tiki:yolo` for each issue sequentially, then ships the release with a git tag.

<instructions>
  <step>**Parse arguments** to determine mode:
    - `release v1.2` - Execute release v1.2
    - `release v1.2 --dry-run` - Preview execution order
    - `release v1.2 --continue` - Resume interrupted release
    - `release status` - Show all release statuses
    - `release status v1.2` - Show specific release status
  </step>
  <step>**Load or create release definition** at `.tiki/releases/{version}.json`:
    - **If the file exists:** load it. Extract issue list and metadata. Check for linked milestone.
    - **If it does not exist:** create a minimal scaffold via the `Write` tool. (The framework cannot call `save_tiki_release` — that's a desktop-only Tauri IPC.) Derive the issue list in this order:
      1. From `--issues '147,148,149'` CLI flag if provided.
      2. From a matching GitHub milestone: `gh api repos/{owner}/{repo}/milestones --jq '.[] | select(.title=="{version}")'` — if present, use its issue list.
      3. If no `--issues` flag and no matching milestone, error with `release-not-found` (see <errors>). Releases must be defined either by CLI flag, GitHub milestone, or a pre-existing `.tiki/releases/{version}.json` (which the desktop app's Releases section creates).
    - Scaffold shape:
      ```json
      {
        "version": "{version}",
        "status": "active",
        "issues": [ { "number": 42, "title": "..." } ],
        "createdAt": "{ISO timestamp now}"
      }
      ```
    - Only error with `release-not-found` if all three derivation paths fail.
  </step>
  <step>**Fetch issue details** for dependency analysis:
    - For each issue in the release, fetch its body via `gh issue view`
    - Parse dependencies from issue bodies
  </step>
  <step>**Calculate dependency order** using topological sort:
    - Parse "depends on #N" patterns from issue bodies
    - Build dependency graph
    - Sort issues so dependencies execute first
    - Detect and report circular dependencies
  </step>
  <step>**Initialize state** in `.tiki/state.json`:
    - Create `release:{version}` work entry
    - Set status to `executing`
    - Initialize `currentIssue` and `completedIssues`
  </step>
  <step>**Execute issues by wave** (parallel dispatch via worktree sub-agents):
    - For each wave from the independence analysis:
      1. Update `release.currentIssues` in state (array of issue numbers in this wave).
      2. For each issue in the wave, spawn an Agent in parallel with:
         - description: `Run /tiki:yolo {N}`
         - subagent_type: `general-purpose`
         - isolation: `worktree`
         - prompt: `Run the /tiki:yolo {N} skill in this worktree. Report back the branch name, head SHA, and PR URL on completion. Pause and report any failure.`
      3. Wait for ALL Agents in the wave to return (block until all done).
      4. For each completed Agent, append the issue number to `release.completedIssues` and the worktree branch name to `release.completedBranches`.
      5. After the wave, in deterministic order (sort by issue number ascending), merge each completed branch into the main release branch via `git merge --no-ff origin/{branch-name}`. Abort the wave merge on the first conflict and surface the conflict to the user with both branches' names.
      6. Move to the next wave.

    **If any single Agent in a wave fails:**
    - Mark its issue as failed in state.
    - Wait for the OTHER Agents in the wave to finish (don't kill them — they may have produced useful work).
    - After the wave drains, pause the cascade and report which issue failed and where (worktree path, branch). Do not auto-continue.

    **Worktree merge order rule:** merge in ascending issue-number order within each wave. Deterministic across runs. If issues touch genuinely independent files (which they should — they're in the same wave because the analysis said no conflicts), order is just for reproducibility.

    **Failure modes:**
    1. **Agent reports phase failure** — that issue's worktree is left intact; user can `cd` into it to investigate. Wave continues until all Agents return; cascade then pauses.
    2. **Merge conflict during wave merge** — analysis missed a soft conflict. Abort the wave merge at the first conflict, leave the conflicting branches unmerged. Report the conflict path to the user and pause.
    3. **Worktree creation failure** (e.g. branch already exists from a prior run) — try `git worktree add -B {branch}` to force-recreate. If still failing, fall back to serial execution for that wave with a warning.

    Conservative default: when in doubt about independence, serialize.
  </step>
  <step>**Generate changelog** after all issues complete:
    - Read the release file from `.tiki/releases/{version}.json` to get issue list
    - For each issue, read `.tiki/plans/issue-{N}.json` to extract phase summaries
    - Run `git log --oneline` filtering for commits mentioning each issue number
    - Categorize changes by conventional commit prefix (feat/fix/refactor/docs/perf/chore)
    - Generate structured markdown changelog with issue references and links
    - Write to `.tiki/releases/{version}-changelog.md`
    - Write changelog to `.tiki/releases/{version}-changelog.md`. Continue directly to shipping — the file is committed to the repo (not just used for the GitHub Release body), so the user can amend it post-ship via a follow-up commit if needed.
    (See `<changelog-generation>` section for detailed format)
  </step>
  <step>**Ship the release** after changelog is approved:
    - Create and push git tag
    - Creat