Repository navigation
Conversation
basecamp-cli, hey and fizzy installed from their default branch, while their CLIs install from releases. A skill on main can then call a flag no released CLI has: basecamp-cli's connect skill runs `basecamp auth agent connect --json`, which only unreleased main supports (basecamp/basecamp-cli#852), so the released 0.13.2 CLI refuses it. release-pins.json names each plugin's CLI repo. bin/pin-releases moves each entry's sha to its latest release's commit, never backwards, and an hourly workflow opens a pull request when one moved. bin/check-marketplace fails when a pinned plugin has no sha.
There was a problem hiding this comment.
🟡 Changes recommended
The workflow hides pinning failures and can stop retrying failed PR creation.
2 open issues
What changed in this PR
Pins CLI-backed marketplace plugins to released commits so their instructions match released CLI behavior.
Changes:
- Adds release mappings and initial pins for Basecamp, HEY, and Fizzy.
- Adds forward-only pin updates, validation, and hourly PR automation.
- Documents pinning and existing-install update limitations.
[!TIP]
If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or rungh pr ready --undo.
Click "Ready for review" or rungh pr readyto reengage.
| File | Description |
|---|---|
| release-pins.json | Maps pinned plugins to CLI repositories. |
| README.md | Explains release pins and update limitations. |
| bin/pin-releases | Advances pins to latest release commits. |
| bin/check-marketplace | Validates pinned entries and full commit hashes. |
| .github/workflows/pin-releases.yml | Schedules pin updates and creates PRs. |
| .claude-plugin/marketplace.json | Sets initial release commit pins. |
Review effort: Balanced
| - name: Pin each plugin to its CLI's latest release | ||
| env: | ||
| GH_TOKEN: ${{ github.token }} | ||
| run: bin/pin-releases | tee "$RUNNER_TEMP/pins.txt" |
| if git fetch --quiet origin "$branch" 2>/dev/null && | ||
| git diff --quiet FETCH_HEAD -- .claude-plugin/marketplace.json; then |
|
Holding this as a draft. Pinning matches the plugin's skill to the latest CLI release. It doesn't help someone on an older CLI, who would get a skill that's newer than their binary. Only the CLI knows its own version, so the direction we're exploring instead is to have the plugin's skills come from the binary ( I'm spiking that with the |
|
Closing in favour of #13. Rather than pinning commit shas here and moving them with an hourly workflow, basecamp-cli's release workflow will move a |
Why
basecamp-cli,heyandfizzyinstall from their default branch, but their CLIs install from releases. A freshclaude plugin install basecamp-cli@37signalstoday gets08ee7ff7, the tip of basecamp-cli's main, labelled0.13.2. That skill runsbasecamp auth agent connect --json, which only unreleased main supports (basecamp/basecamp-cli#852). The released 0.13.2 CLI refuses it, and users see the agent work around our own instructions while connecting.What
release-pins.jsonnames each pinned plugin's CLI repo.bin/pin-releasessets each entry'sshato its CLI's latest release commit. It never moves a pin backwards, and a second run changes nothing.bin/check-marketplaceadds rule 3: every pinned plugin carries a full commit sha..github/workflows/pin-releases.ymlruns the script hourly and opens or updates apin-releasesPR when a pin moved. A PR opened with the workflow's token starts no other workflow, so the job runsbin/check-marketplaceitself before pushing.d742884a), hey at v1.9.0 (76ea03f5), fizzy at v4.0.1 (3834efe7).The house-skills plugins and the hosted plugin aren't pinned. They don't drive a separately released CLI.
Verified locally
d742884a, hey at76ea03f5and fizzy at3834efe7. That covers bothurlandgithubsources.basecamp-connect/SKILL.mdis byte-identical to v0.13.2's.behindmain.actionlintandzizmorreport nothing on the workflow, andbin/check-marketplacepasses.workflow_dispatchrun should report every plugin unchanged.Needs a person
plugin updatecomparesplugin.jsonversions, not commits. I checked this: a pin to a same-version commit left an install on main, and a pin to a 0.13.3 commit moved it. So:1.9.0, so installs move at its next release.plugin.jsonsays0.1.0on main and on v4.0.1. Existing Fizzy installs never update today, pinned or not, until fizzy-cli stamps its version at release.