|
| 1 | +--- |
| 2 | +name: release |
| 3 | +description: Automate a full seedit release by analyzing commits, updating the release body, bumping the version, regenerating the changelog, and finalizing the git tag. Use when the user says "release", "new version", "cut a release", "prepare release", or provides a version number to ship. |
| 4 | +--- |
| 5 | + |
| 6 | +# Release |
| 7 | + |
| 8 | +End-to-end release automation for seedit. |
| 9 | + |
| 10 | +## Usage |
| 11 | + |
| 12 | +The user provides a version bump (`patch`, `minor`, `major`, or explicit `x.y.z`). |
| 13 | +If omitted, ask which bump level they want. |
| 14 | + |
| 15 | +## Workflow |
| 16 | + |
| 17 | +Copy this checklist and track progress: |
| 18 | + |
| 19 | +```text |
| 20 | +Release Progress: |
| 21 | +- [ ] Step 1: Analyze commits |
| 22 | +- [ ] Step 2: Write release body one-liner |
| 23 | +- [ ] Step 3: Bump version in package.json |
| 24 | +- [ ] Step 4: Generate changelog |
| 25 | +- [ ] Step 5: Commit, tag, push |
| 26 | +``` |
| 27 | + |
| 28 | +### Step 1 — Analyze commits |
| 29 | + |
| 30 | +```bash |
| 31 | +git tag --sort=-creatordate | head -1 |
| 32 | +``` |
| 33 | + |
| 34 | +Then list commits since that tag: |
| 35 | + |
| 36 | +```bash |
| 37 | +git log --oneline <tag>..HEAD |
| 38 | +``` |
| 39 | + |
| 40 | +If there are no new commits, stop. |
| 41 | + |
| 42 | +### Step 2 — Write the release body one-liner |
| 43 | + |
| 44 | +Edit `oneLinerDescription` in `scripts/release-body.js`. |
| 45 | + |
| 46 | +Rules: |
| 47 | +- Start with "This version..." or "This release..." |
| 48 | +- One sentence, no bullets |
| 49 | +- Lead with the biggest features or fixes |
| 50 | +- Keep it user-facing |
| 51 | +- End with a period |
| 52 | + |
| 53 | +### Step 3 — Bump version |
| 54 | + |
| 55 | +Read `package.json`, compute the new version from the bump level, and update the `"version"` field. |
| 56 | + |
| 57 | +| Bump | Effect | |
| 58 | +|------|--------| |
| 59 | +| `patch` | `0.6.7` → `0.6.8` | |
| 60 | +| `minor` | `0.6.7` → `0.7.0` | |
| 61 | +| `major` | `0.6.7` → `1.0.0` | |
| 62 | +| `x.y.z` | Set exactly | |
| 63 | + |
| 64 | +### Step 4 — Generate changelog |
| 65 | + |
| 66 | +```bash |
| 67 | +yarn changelog |
| 68 | +``` |
| 69 | + |
| 70 | +This regenerates `CHANGELOG.md` from conventional commits. |
| 71 | + |
| 72 | +### Step 5 — Commit, tag, push |
| 73 | + |
| 74 | +```bash |
| 75 | +git add -A |
| 76 | +git commit -m "chore(release): v<version>" |
| 77 | +git push |
| 78 | +git tag v<version> |
| 79 | +git push --tags |
| 80 | +``` |
| 81 | + |
| 82 | +If CI is configured to publish release artifacts on tags, pushing the tag will trigger it. |
| 83 | + |
| 84 | +## Dry-run mode |
| 85 | + |
| 86 | +If the user says "dry run" or "preview", execute Steps 1–4 but skip the git operations in Step 5. Print a summary of what would be committed so the user can review it first. |
0 commit comments