mcpField
C
cli-release

cli-release

github.com/composiohqCloud & DevOps30.8k125 installsUpdated today
Repository

About cli-release

A skill for managing releases of the standalone `composio` binary and installer. It guides maintainers through beta builds, stable promotions, and recovery, with checks that continue through installation tests.

Key features

  1. 01Classifies release requests
  2. 02Checks candidate tags and workflow state
  3. 03Dispatches and monitors release workflows
  4. 04Verifies assets and installation tests

Use cases

  1. 01Preparing a beta build after changes to CLI paths
  2. 02Promoting a tested beta to a stable release
  3. 03Recovering or verifying a release

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/composiohq/composio --skill cli-release

After installing, type/cli-releasein Claude Code to confirm it loaded.

Bundled filesreferences/release-workflow.md

Details

From the project README

CLI Release

Use this skill for the GitHub Release that powers the standalone composio binary and installer.

Read references/release-workflow.md before selecting a candidate or dispatching a workflow.

Release Contract

  • Never add a Changeset for @composio/cli; the package is ignored by Changesets and such files wedge ts.release.yml.
  • Treat a merge to next that touches CLI paths as a beta build. Promote a tested beta with the promote-stable workflow action for the normal stable-release path.
  • Never bump the private CLI package.json to select a binary version. For an intentional minor or major, build an explicitly versioned beta and promote that tested beta through the same stable path.
  • Resolve beta tags and workflow state from GitHub immediately before acting. Never invent or reuse a stale candidate from memory.
  • A stable promotion is a production write. If the user did not name the exact beta tag, present the resolved candidate and obtain explicit confirmation before dispatching it.
  • Follow the release through asset verification and installation tests. Do not stop after the dispatch succeeds.

Execution

  1. Classify the request as automatic beta, manual beta, stable promotion, or recovery.
  2. Run the playbook's read-only preflight and identify the exact source commit and release tag.
  3. Dispatch only the requested workflow action and watch the resulting run to completion.
  4. Verify the published release and downstream checks named in the playbook.
  5. Report the released tag, source beta or commit, workflow URL, asset state, install-test result, and any remaining follow-up.

Comments

Markdown supported