Address PR review feedback:
- clean-gone script now skips the currently checked-out branch (marked
with *) to prevent git branch -D from failing on the active branch
- README skill count corrected to 42 (was 43)
Three new skills replacing the deprecated commit-commands plugin:
- git-commit: Convention-aware commit creation with logical commit
splitting at the file level when changes have distinct concerns
- git-commit-push-pr: Adaptive PR descriptions that scale in depth with
change complexity, conditional test plans, and GitHub-safe formatting
- git-clean-gone-branches: Fetch-first branch cleanup with user
confirmation and worktree handling, using a shell script for reliable
parsing
All three use `command git` to bypass RTK proxies and shell aliases.
The skill generated outdated output — referenced deprecated tools
(TodoWrite, MultiEdit), project-specific integrations, and used
command-style templates that no longer match current skill conventions.
The plugin ecosystem has better skill-authoring tooling elsewhere.
- Replace deprecated Commands section with proper Skills sections
- Move Skills before Agents — skills are the entry points, agents are implementation details
- Add Core Workflow section with all ce:* skills front and center
- Add Git Workflow section for new git-commit/push/pr skills
- Add Workflow Utilities section absorbing former Utility Commands
- Add Beta/Experimental section for lfg and slfg
- Add note that agents are invoked by skills, not directly by users
- Update skill count from 40+ to 43
With skip-labeling: true, release-please couldn't find its own PRs
on subsequent runs (it searches by the autorelease: pending label).
This prevented it from updating the PR body when new commits landed.
With skip-changelog: true, release-please didn't update the PR body
when new commits landed because the tree SHA was unchanged (no
changelog file to diff). Re-enabling changelogs means each new commit
produces different changelog content, forcing release-please to update
both the branch and PR body.
Closing the release PR before release-please runs prevented
release-please from recognizing the PR on merge, so it never created
GitHub Releases or tags. The close-reopen approach is incompatible
with release-please's PR tracking.
Keep cancel-in-progress: true for rapid-succession merges and the
release-merge detection for skipping validate. Accept that the PR
body may be stale -- GitHub Releases get correct changelogs at merge
time regardless.
release-please defaults to walking 500 commits and 400 releases on
every run, making each API call per-commit. With ~20 commits between
releases, this wastes ~2 minutes on unnecessary GitHub API calls.
When a release PR merges, the validate step would fail on version drift
that the release PR itself introduced, blocking release-please from
creating tags and GitHub Releases. Detect release PR merges by commit
message prefix and skip validate + stale-close steps so release-please
runs unimpeded.
- Remove plugin version fields from marketplace.json -- canonical
versions live in each plugin's plugin.json. Duplicating them created
drift that release-please couldn't maintain.
- Remove version sync logic from metadata.ts (description sync kept)
- Fix release-preview test to compute expected versions dynamically
from current manifests instead of hardcoding them
Trevin Chow
github-actions[bot]
Matt Van Horn
Adam Zywicki
Tony Park
PJ Hoberman