|
| 1 | +--- |
| 2 | +name: release-prep |
| 3 | +description: >- |
| 4 | + Prepare a release for durabletask and durabletask.azuremanaged. Use when the |
| 5 | + user asks for release prep, version bumping, changelog updates, or release |
| 6 | + body drafting. Trigger phrases include: release prep, prepare vX.Y.Z, |
| 7 | + changelog for release, and draft GitHub release notes. |
| 8 | +--- |
| 9 | + |
| 10 | +# Release Prep |
| 11 | + |
| 12 | +This skill prepares a coordinated release for both packages in this repository: |
| 13 | + |
| 14 | +- `durabletask` |
| 15 | +- `durabletask.azuremanaged` |
| 16 | + |
| 17 | +The skill accepts a target version (for example `1.4.0`) and performs the |
| 18 | +required changes consistently. |
| 19 | + |
| 20 | +## Inputs |
| 21 | + |
| 22 | +- `version`: Target semantic version (for example `1.4.0`) |
| 23 | +- Optional: `baseTag` overrides for comparison if tags are non-standard |
| 24 | + |
| 25 | +If `version` is not provided, ask the user before continuing. |
| 26 | + |
| 27 | +## Steps |
| 28 | + |
| 29 | +### 1. Determine source range and collect commits |
| 30 | + |
| 31 | +- Root package range: `v<previousVersion>..HEAD` |
| 32 | +- Azure managed package range: `azuremanaged-v<previousVersion>..HEAD` |
| 33 | +- Use commit subjects and touched files to classify each change as: |
| 34 | + - `durabletask` only |
| 35 | + - `durabletask.azuremanaged` only |
| 36 | + - shared/infra/docs changes |
| 37 | + |
| 38 | +### 2. Update package versions |
| 39 | + |
| 40 | +Update both project versions: |
| 41 | + |
| 42 | +- `pyproject.toml` -> `version = "<version>"` |
| 43 | +- `durabletask-azuremanaged/pyproject.toml` -> `version = "<version>"` |
| 44 | + |
| 45 | +Update azuremanaged dependency floors: |
| 46 | + |
| 47 | +- `durabletask>=<version>` |
| 48 | +- `durabletask[azure-blob-payloads]>=<version>` |
| 49 | + |
| 50 | +### 3. Update changelogs |
| 51 | + |
| 52 | +- Add a new `## v<version>` section directly under `## Unreleased` in: |
| 53 | + - `CHANGELOG.md` |
| 54 | + - `durabletask-azuremanaged/CHANGELOG.md` |
| 55 | +- Ensure user-facing changes since the previous release tags are represented. |
| 56 | +- Keep entries concise and grouped by type (`ADDED`, `CHANGED`, `FIXED`, `REMOVED`) where |
| 57 | + applicable. |
| 58 | +- Exclude internal-only changes from changelogs (for example CI/workflow-only |
| 59 | + updates, test-only changes, and implementation refactors with no public |
| 60 | + behavior or API impact). |
| 61 | + |
| 62 | +### 4. Validate |
| 63 | + |
| 64 | +- Run diagnostics on changed markdown and TOML files. |
| 65 | +- Fix formatting or heading issues introduced by release prep changes. |
| 66 | +- Verify the final diff only contains release-prep updates. |
| 67 | + |
| 68 | +### 5. Wait for merge and tags before release drafting |
| 69 | + |
| 70 | +Before creating draft releases in GitHub UI, require explicit user |
| 71 | +confirmation of both conditions: |
| 72 | + |
| 73 | +- The version-bump/release-prep PR is merged |
| 74 | +- Tags `v<version>` and `azuremanaged-v<version>` already exist in the target |
| 75 | + repository |
| 76 | + |
| 77 | +If either condition is not met, stop after preparing release body text and ask |
| 78 | +the user to confirm once merge and tags are complete. |
| 79 | + |
| 80 | +### 6. Draft GitHub release bodies |
| 81 | + |
| 82 | +Draft two release body texts for the GitHub Releases UI (do not add files to |
| 83 | +the repository): |
| 84 | + |
| 85 | +- Tag: `v<version>` |
| 86 | +- Tag: `azuremanaged-v<version>` |
| 87 | + |
| 88 | +Match existing release structure: |
| 89 | + |
| 90 | +- Title (`# v<version>` or `# azuremanaged-v<version>`) |
| 91 | +- `## What's Changed` |
| 92 | +- `## External Links` |
| 93 | +- `### Contributors` |
| 94 | + |
| 95 | +Include: |
| 96 | + |
| 97 | +- PyPI link for the exact release version |
| 98 | +- Full changelog compare link |
| 99 | +- Contributor handles from the commit range |
| 100 | +- Keep drafts in the assistant response (or PR comment) so they can be pasted |
| 101 | + directly into the Releases section |
| 102 | +- Keep the release body focused on user-facing changes and avoid internal-only |
| 103 | + details (CI/test updates or implementation-only notes) |
| 104 | + |
| 105 | + |
| 106 | +## Output |
| 107 | + |
| 108 | +Return a short summary with: |
| 109 | + |
| 110 | +- Updated files |
| 111 | +- Commit coverage confirmation |
| 112 | +- Any manual follow-ups (for example, tag creation or publishing) |
0 commit comments