feat(plugins): replace prepare-release with workhub's own release-app skill - #93
Merged
Conversation
…'s own
`prepare-release` prescribed a release-branch-and-PR flow and explicitly
refused to push tags or trigger the pipeline. workhub releases the opposite
way: `.claude/rules/release-process.md` commits the version bump straight to
main and *pushes the tag* to publish. An agent that reached for the generic
skill inside this repository was led away from the real procedure, and most of
what it said otherwise ("find every version-bearing file", "prefer the
repository's conventions") is what the agent does by default.
A release procedure is repository-specific, so it belongs to the repository:
the contract in `.claude/rules/`, and the sequence that drives it in a
repository-specific skill.
Add `workhub:release-app` for this app. It reads the release contract as its
first step rather than restating it, so the asset names and invariants keep a
single source of truth, then walks the sequence: clean and current main, green
CI, decide the version (handling the case where a bump landed but the tag never
did), draft the changelog, stop for approval, tag and push, and verify the
published release carries every required asset.
Drop `prepare-release` and update the two places that referenced it.
Plugin versions: workhub 0.18.0, engineering 0.24.0, productivity 0.22.1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
prepare-release(engineering plugin) prescribed a release-branch-and-PR flowand explicitly refused to push tags or trigger the pipeline. workhub's actual
release procedure (
.claude/rules/release-process.md) is the opposite: bumpthe version, commit straight to
main, and push the tag — that push iswhat triggers the build-and-publish workflow. An agent reaching for the
generic skill inside this repo would be led away from the real procedure, and
most of what the skill said otherwise ("find every version-bearing file",
"prefer the repository's conventions") is behavior an agent already has by
default.
A release procedure is repository-specific, so it should live with the
repository: the contract in
.claude/rules/, and the sequence that drives itin a repository-specific skill.
What changed
plugins/workhub/skills/release-app/SKILL.md. It reads.claude/rules/release-process.mdas its first step rather than restatingthe contract, so asset names and invariants keep one source of truth. Then:
clean + current
main→ green CI → decide the version (handles the casewhere a bump landed but the tag never did) → draft the changelog → stop for
explicit approval → commit + tag + push → verify the published release
carries every required asset.
plugins/engineering/skills/prepare-release/.plugins/engineering/README.md,plugins/productivity/skills/create-release-notes/SKILL.md) anddocs/plugins.md's catalog entries forworkhubandengineering..claude/rules/plugin-authoring.md:workhub0.17.0 → 0.18.0,
engineering0.23.0 → 0.24.0,productivity0.22.0 →0.22.1 (wording only), in both
plugin.jsonandmarketplace.json.Test plan
npm test— 124/124 passed(verified with a script, all 9 plugins)
release-append to end on a real workhub release🤖 Generated with Claude Code