chore: add release train workflow

skills/release-changelog/SKILL.md

@@ -106,6 +106,25 @@ Guidelines:
 - keep highlights short and concrete
 - spell out upgrade actions for breaking changes
 
+### Inline PR and contributor attribution
+
+When a bullet item clearly maps to a merged pull request, add inline attribution at the
+end of the entry in this format:
+
+```
+- **Feature name** — Description. ([#123](https://github.com/paperclipai/paperclip/pull/123), @contributor1, @contributor2)
+```
+
+Rules:
+
+- Only add a PR link when you can confidently trace the bullet to a specific merged PR.
+  Use merge commit messages (`Merge pull request #N from user/branch`) to map PRs.
+- List the contributor(s) who authored the PR. Use GitHub usernames, not real names or emails.
+- If multiple PRs contributed to a single bullet, list them all: `([#10](url), [#12](url), @user1, @user2)`.
+- If you cannot determine the PR number or contributor with confidence, omit the attribution
+  parenthetical — do not guess.
+- Core maintainer commits that don't have an external PR can omit the parenthetical.
+
 ## Step 5 — Write the File
 
 Template:
@@ -124,10 +143,29 @@ Template:
 ## Fixes
 
 ## Upgrade Guide
+
+## Contributors
+
+Thank you to everyone who contributed to this release!
+
+@username1, @username2, @username3
 ```
 
 Omit empty sections except `Highlights`, `Improvements`, and `Fixes`, which should usually exist.
 
+The `Contributors` section should always be included. List every person who authored
+commits in the release range, @-mentioning them by their **GitHub username** (not their
+real name or email). To find GitHub usernames:
+
+1. Extract usernames from merge commit messages: `git log v{last}..HEAD --oneline --merges` — the branch prefix (e.g. `from username/branch`) gives the GitHub username.
+2. For noreply emails like `user@users.noreply.github.com`, the username is the part before `@`.
+3. For contributors whose username is ambiguous, check `gh api users/{guess}` or the PR page.
+
+**Never expose contributor email addresses.** Use `@username` only.
+
+Exclude bot accounts (e.g. `lockfile-bot`, `dependabot`) from the list. List contributors
+in alphabetical order by GitHub username (case-insensitive).
+
 ## Step 6 — Review Before Release
 
 Before handing it off:

skills/release/SKILL.md

@@ -13,10 +13,11 @@ Run the full Paperclip release as a maintainer workflow, not just an npm publish
 This skill coordinates:
 
 - stable changelog drafting via `release-changelog`
+- release-train setup via `scripts/release-start.sh`
 - prerelease canary publishing via `scripts/release.sh --canary`
 - Docker smoke testing via `scripts/docker-onboard-smoke.sh`
 - stable publishing via `scripts/release.sh`
-- pushing the release commit and tag
+- pushing the stable branch commit and tag
 - GitHub Release creation via `scripts/create-github-release.sh`
 - website / announcement follow-up tasks
 
@@ -36,7 +37,7 @@ Before proceeding, verify all of the following:
 2. The repo working tree is clean, including untracked files.
 3. There are commits since the last stable tag.
 4. The release SHA has passed the verification gate or is about to.
-5. If package manifests changed, the CI-owned `pnpm-lock.yaml` refresh is already merged on `master`.
+5. If package manifests changed, the CI-owned `pnpm-lock.yaml` refresh is already merged on `master` before the release branch is cut.
 6. npm publish rights are available locally, or the GitHub release workflow is being used with trusted publishing.
 7. If running through Paperclip, you have issue context for status updates and follow-up task creation.
 
@@ -55,13 +56,15 @@ Collect these inputs up front:
 
 Paperclip now uses this release model:
 
-1. Draft the **stable** changelog as `releases/vX.Y.Z.md`
-2. Publish one or more **prerelease canaries** such as `X.Y.Z-canary.0`
-3. Smoke test the canary via Docker
-4. Publish the stable version `X.Y.Z`
-5. Push the release commit and tag
-6. Create the GitHub Release
-7. Complete website and announcement surfaces
+1. Start or resume `release/X.Y.Z`
+2. Draft the **stable** changelog as `releases/vX.Y.Z.md`
+3. Publish one or more **prerelease canaries** such as `X.Y.Z-canary.0`
+4. Smoke test the canary via Docker
+5. Publish the stable version `X.Y.Z`
+6. Push the stable branch commit and tag
+7. Create the GitHub Release
+8. Merge `release/X.Y.Z` back to `master` without squash or rebase
+9. Complete website and announcement surfaces
 
 Critical consequence:
 
@@ -70,7 +73,13 @@ Critical consequence:
 
 ## Step 1 — Decide the Stable Version
 
-Run release preflight first:
+Start the release train first:
+
+```bash
+./scripts/release-start.sh {patch|minor|major}
+```
+
+Then run release preflight:
 
 ```bash
 ./scripts/release-preflight.sh canary {patch|minor|major}
@@ -125,7 +134,7 @@ The GitHub Actions release workflow installs with `pnpm install --frozen-lockfil
 
 ## Step 4 — Publish a Canary
 
-Run:
+Run from the `release/X.Y.Z` branch:
 
 ```bash
 ./scripts/release.sh {patch|minor|major} --canary --dry-run
@@ -203,12 +212,14 @@ Stable publish does **not** push the release for you.
 After stable publish succeeds:
 
 ```bash
-git push public-gh HEAD:master --follow-tags
+git push public-gh HEAD --follow-tags
 ./scripts/create-github-release.sh X.Y.Z
 ```
 
 Use the stable changelog file as the GitHub Release notes source.
 
+Then open the PR from `release/X.Y.Z` back to `master` and merge without squash or rebase.
+
 ## Step 8 — Finish the Other Surfaces
 
 Create or verify follow-up work for: