|
| 1 | +--- |
| 2 | +name: release |
| 3 | +description: > |
| 4 | + Automates cutting a Clawdapus release: determines the next semver version, |
| 5 | + backfills any missing changelog entries from GitHub releases, writes the new |
| 6 | + version entry in the site changelog, updates the nav dropdown and Latest badge, |
| 7 | + commits, tags, and pushes (which triggers goreleaser + site deploy). |
| 8 | + Use this skill whenever the user says "release", "cut a release", "new version", |
| 9 | + "update the changelog and tag", "prepare a release", or anything about shipping |
| 10 | + a new version of the claw CLI. |
| 11 | +--- |
| 12 | + |
| 13 | +# Release |
| 14 | + |
| 15 | +This skill automates the full release pipeline for Clawdapus. The release |
| 16 | +workflow is tag-driven: pushing a semver tag triggers `.github/workflows/release.yml` |
| 17 | +(goreleaser builds binaries and creates the GitHub release) and |
| 18 | +`.github/workflows/deploy-site.yml` deploys the updated site to clawdapus.dev. |
| 19 | + |
| 20 | +Your job is to prepare everything locally, confirm with the user, then push. |
| 21 | + |
| 22 | +## Step 1: Determine the release version |
| 23 | + |
| 24 | +Run these commands to understand the current state: |
| 25 | + |
| 26 | +```bash |
| 27 | +# Latest tag |
| 28 | +git tag --sort=-v:refname | head -1 |
| 29 | + |
| 30 | +# Latest GitHub release |
| 31 | +gh release list --limit 1 |
| 32 | + |
| 33 | +# Commits since last tag |
| 34 | +git log <latest-tag>..HEAD --oneline |
| 35 | +``` |
| 36 | + |
| 37 | +Analyze the commits and propose a version bump: |
| 38 | +- **patch** (0.x.Y) — bug fixes, doc updates, dependency bumps |
| 39 | +- **minor** (0.X.0) — new features, new commands, new drivers, capability additions |
| 40 | +- **major** (X.0.0) — breaking changes (not yet applicable pre-1.0) |
| 41 | + |
| 42 | +Present the proposed version to the user and wait for confirmation. If the user |
| 43 | +already specified a version (e.g. "cut v0.5.0"), use that. |
| 44 | + |
| 45 | +## Step 2: Backfill missing changelog entries |
| 46 | + |
| 47 | +The site changelog (`site/changelog.md`) may be behind GitHub releases. Check: |
| 48 | + |
| 49 | +```bash |
| 50 | +# Extract version headers already in the changelog |
| 51 | +grep '^## v' site/changelog.md |
| 52 | +``` |
| 53 | + |
| 54 | +Compare against actual GitHub releases: |
| 55 | + |
| 56 | +```bash |
| 57 | +gh release list --limit 20 |
| 58 | +``` |
| 59 | + |
| 60 | +For each release that exists on GitHub but not in the changelog, fetch its notes: |
| 61 | + |
| 62 | +```bash |
| 63 | +gh release view <tag> --json tagName,body,publishedAt |
| 64 | +``` |
| 65 | + |
| 66 | +Write human-readable changelog entries for each missing version. Insert them in |
| 67 | +descending order between the "Unreleased" section (or the new version heading) |
| 68 | +and the most recent existing entry. Use the same style as existing entries: |
| 69 | + |
| 70 | +```markdown |
| 71 | +## v0.X.Y {#v0-X-Y} |
| 72 | + |
| 73 | +*YYYY-MM-DD* |
| 74 | + |
| 75 | +- **Feature name** — concise description of what changed and why it matters. |
| 76 | +- Fix: brief description of bug fix. |
| 77 | +``` |
| 78 | + |
| 79 | +Don't just dump commit hashes — synthesize the release notes into user-facing |
| 80 | +changelog prose grouped by theme. |
| 81 | + |
| 82 | +## Step 3: Write the new version entry |
| 83 | + |
| 84 | +Convert the `## Unreleased` section (if present) into the new version heading. |
| 85 | +If there's no Unreleased section, write one from the commits since the last tag. |
| 86 | + |
| 87 | +The new version gets the `<Badge>` and anchor: |
| 88 | + |
| 89 | +```markdown |
| 90 | +## v0.X.Y <Badge type="tip" text="Latest" /> {#v0-X-Y} |
| 91 | + |
| 92 | +*YYYY-MM-DD* |
| 93 | + |
| 94 | +- **Feature** — description. |
| 95 | +``` |
| 96 | + |
| 97 | +Remove the `<Badge type="tip" text="Latest" />` from whichever older version |
| 98 | +currently has it. Only one version should have the Latest badge. |
| 99 | + |
| 100 | +Add a fresh empty `## Unreleased` section at the top (above the new version) |
| 101 | +so there's always a place for future notes: |
| 102 | + |
| 103 | +```markdown |
| 104 | +## Unreleased |
| 105 | + |
| 106 | +<!-- Nothing yet --> |
| 107 | +``` |
| 108 | + |
| 109 | +## Step 4: Update the nav dropdown version |
| 110 | + |
| 111 | +In `site/.vitepress/config.mts`, find the version string in the nav array: |
| 112 | + |
| 113 | +```ts |
| 114 | +{ |
| 115 | + text: 'v0.X.Y', // ← update this |
| 116 | + items: [ |
| 117 | +``` |
| 118 | +
|
| 119 | +Replace it with the new version. |
| 120 | +
|
| 121 | +## Step 5: Commit, tag, and push |
| 122 | +
|
| 123 | +Stage only the changed files: |
| 124 | +
|
| 125 | +```bash |
| 126 | +git add site/changelog.md site/.vitepress/config.mts |
| 127 | +``` |
| 128 | +
|
| 129 | +Commit with a message like: |
| 130 | +
|
| 131 | +``` |
| 132 | +site: release v0.X.Y |
| 133 | + |
| 134 | +Backfill v0.A.B–v0.C.D changelog entries. Add v0.X.Y with [brief summary]. |
| 135 | +Update nav dropdown to v0.X.Y. |
| 136 | +``` |
| 137 | +
|
| 138 | +Tag: |
| 139 | +
|
| 140 | +```bash |
| 141 | +git tag v0.X.Y |
| 142 | +``` |
| 143 | +
|
| 144 | +Before pushing, confirm with the user: "Ready to push commit + tag. This will |
| 145 | +trigger goreleaser (binary release) and site deploy. Go?" |
| 146 | +
|
| 147 | +Then push: |
| 148 | +
|
| 149 | +```bash |
| 150 | +git push origin master --tags |
| 151 | +``` |
| 152 | +
|
| 153 | +If the push is rejected because the remote is ahead, pull with rebase, re-tag |
| 154 | +(delete old local tag first), and push again: |
| 155 | +
|
| 156 | +```bash |
| 157 | +git pull --rebase origin master |
| 158 | +git tag -d v0.X.Y |
| 159 | +git tag v0.X.Y |
| 160 | +git push origin master |
| 161 | +git push origin v0.X.Y --force |
| 162 | +``` |
| 163 | +
|
| 164 | +## Step 6: Verify |
| 165 | +
|
| 166 | +After pushing, confirm the workflows started: |
| 167 | +
|
| 168 | +```bash |
| 169 | +gh run list --limit 5 |
| 170 | +``` |
| 171 | +
|
| 172 | +Report the status to the user and link to the release page: |
| 173 | +`https://github.com/mostlydev/clawdapus/releases/tag/v0.X.Y` |
| 174 | + |
| 175 | +## Edge cases |
| 176 | + |
| 177 | +- **No commits since last tag**: Tell the user there's nothing to release. |
| 178 | +- **Unreleased section is empty**: Write it from `git log` commits. |
| 179 | +- **Multiple missing GitHub releases**: Backfill all of them, oldest first. |
| 180 | +- **Dirty working tree**: Warn the user about uncommitted changes before starting. Don't mix unrelated changes into the release commit. |
| 181 | +- **User wants to skip backfill**: That's fine — ask, don't force it. |
| 182 | +- **Rebase moved the tagged commit**: If you had to rebase after tagging, the tag |
| 183 | + points at the old (pre-rebase) commit. Delete the local tag, re-create it, and |
| 184 | + force-push just the tag. If goreleaser already created a partial release from |
| 185 | + the stale tag, delete it with `gh release delete <tag> --yes`, then delete and |
| 186 | + re-push the remote tag to retrigger: |
| 187 | + ```bash |
| 188 | + gh release delete v0.X.Y --yes |
| 189 | + git push origin :refs/tags/v0.X.Y |
| 190 | + git push origin v0.X.Y |
| 191 | + ``` |
0 commit comments