Run any Skill in Manus with one click

release-claude-code-plugin

Stars0

Forks0

UpdatedJuly 7, 2026 at 10:37

Release a Claude Code plugin distributed via git — bumps the version in its .claude-plugin/plugin.json, keeps any marketplace.json entry in sync, commits, and pushes. Use whenever the user says "release the plugin", "bump the plugin version", "publish the Claude Code plugin", "ship the plugin", "cut a plugin release", or otherwise wants to version a plugin whose plugin.json holds the version. NOT for tag-and-CI release flows where a pushed v* tag builds artifacts — use the `release` skill for those.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

JasperHG90

JasperHG90/skills

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Computer Occupations, All OtherComputer and Mathematical Occupations·SOC 15-1299

File Explorer

2 files

SKILL.md

readonly

More from this repository

same repository

release

JasperHG90/skills

Release a new version of a project. Handles version bumping (alpha / release candidate / stable), tagging, pushing, creating a GitHub release with curated release notes, and monitoring the CI pipeline until success. Use whenever the user says "release", "new version", "tag a release", "bump version", "ship it", "cut a release", "cut an RC", "promote RC", or anything about creating a new project version/tag. NOT for releasing a Claude Code plugin that is versioned in its .claude-plugin/plugin.json and distributed straight over git with no tag-triggered build — use the `release-claude-code-plugin` skill for that.

2026-07-070

rule-creator

JasperHG90/skills

Creates a "rule" — a short, always-on guidance file (Markdown with name/description frontmatter, optionally path-scoped) that is injected into an agent's context to enforce or nudge a standing behavior. Writes it either into this repo's rules/ library or a project's .claude/rules/ directory, walking from intent through a fit check, interactive follow-ups (path scope, enforce-vs-nudge, save location, duplicate check), and a terse draft. Use whenever the user wants to create, write, add, scaffold, or draft a rule / constraint / guardrail / coding convention / standing instruction / always-on guidance / .claude/rules entry, or turn a repeated correction ("stop doing X", "always do Y") into a permanent rule. NOT for: authoring a reusable multi-step procedure (use skill-creator); a delegatable subagent (use agent-creator); editing settings.json, hooks, or permissions (use update-config); or recording project-specific facts like build commands and directory layout (those belong in CLAUDE.md / AGENTS.md, not a rule)

2026-07-060

blueprint

JasperHG90/skills

Scan a repository and produce a comprehensive architectural blueprint document with tech stack, component maps, Mermaid diagrams, data flow, API surfaces, dependency graphs, and design patterns. Spawns parallel analysis agents for speed. Use whenever the user says "blueprint", "architecture overview", "architectural blueprint", "map this repo", "codebase analysis", "system design doc", "repo scan", "how is this repo structured", "document the architecture", or wants to understand, document, or map the architecture of a codebase. Also use when onboarding to a new codebase and wanting a high-level understanding, or when asked to create technical documentation for a project. For standalone C4 diagrams (context, container, component) without a full document, use the c4-diagrams skill instead.

2026-07-030

c4-diagrams

JasperHG90/skills

Create C4 model architecture diagrams (system context, container, component, plus dynamic and deployment views) as Mermaid, for software systems and data platforms. Use when the user says "C4", "C4 model", "context diagram", "container diagram", "component diagram", "system context", "architecture diagram", "diagram this system", "visualize the architecture", "diagram the data platform / pipeline", or wants audience-appropriate views of a system at different zoom levels. Also use to review or fix an existing C4 diagram. For a full written blueprint document of a repository, use the blueprint skill instead.

2026-07-030

agent-creator

JasperHG90/skills

Creates a Claude subagent definition file (a .md agent spawned via the Agent/Task tool) and iteratively improves it — the way skill-creator does for skills, but adapted to the physics of subagents (isolated context, return value is data not chat, tool allowlist as guardrail, name and description as delegation trigger). Walks you from intent through the design dimensions, writing the file, testing it on realistic delegation prompts, and tuning its trigger. Use whenever the user wants to create, design, write, scaffold, draft, or improve a subagent / sub-agent / custom agent / agent definition, build an agent for a skill's agents/ directory, set up a specialized agent to delegate to, or tune an existing agent's description / tools / model. NOT for: creating a skill (use skill-creator); orchestrating a multi-phase multi-agent build or "agent team" (use dev-team); writing a one-off Agent-tool prompt you will not reuse; or authoring a multi-agent Workflow script.

2026-07-020

terminal-gif

JasperHG90/skills

Record polished GIFs (and MP4/WebM/PNG) of terminal programs — CLIs, TUIs, REPLs, dotfiles, your own tools — by scripting them with VHS. Use this whenever the user wants to "make a gif", "record a terminal", "capture a CLI/TUI demo", "show this command running", "create a demo for the README", "animate my tool", "screen-record the terminal", or asks for an asciinema-style recording, a terminal screenshot, or a demo of how a command-line program behaves. Trigger even when the user only describes the behavior they want to capture (e.g. "show what happens when I run `mytool init`") without naming GIF or VHS explicitly.

2026-06-190

name

release-claude-code-plugin

description

Release a Claude Code Plugin

Bumps the version of a Claude Code plugin and publishes it over git.

Claude Code plugins are usually distributed straight from a repository: users add the marketplace and install the plugin from a branch or ref, so there is no build to run and no CI to wait on. The version lives in the plugin's manifest, and "releasing" means bumping that version, committing, and pushing so installs pick it up. This skill is the lightweight, git-only counterpart to the release skill — reach for release instead when pushing a v* tag is what triggers a build and a GitHub release.

How a plugin's version is stored

A plugin's version can live in up to two places that must agree:

plugin.json — every plugin has one at <plugin-dir>/.claude-plugin/plugin.json, with a "version" field. This is the source of truth.
marketplace.json — a marketplace repo has one at its root, .claude-plugin/marketplace.json, listing plugins under "plugins". Each entry has a "name" and a "source" (relative path to the plugin dir), and often duplicates "version". When it does, that copy has to be bumped in lockstep or installs read a stale number.

A repo may be a single plugin, a marketplace of several plugins in one repo (each under its own source path), or a plugin with no marketplace at all. Discover which before bumping.

Step 1 — Locate the plugin(s) and read the current version

Run from the repo root. Find the real manifests, excluding vendored or installed copies (.claude/plugins/ holds installed plugins, worktrees and .temp/node_modules/.venv hold duplicates — none of those are the source you edit):

find . \( -path '*/.claude/plugins/*' -o -path '*/.venv/*' -o -path '*/node_modules/*' \
  -o -path '*/.temp/*' -o -path '*/worktrees/*' \) -prune -o \
  -name plugin.json -path '*/.claude-plugin/*' -print -o \
  -name marketplace.json -path '*/.claude-plugin/*' -print

Read the "version" from each plugin.json. If more than one plugin turns up, ask the user which to release (or whether to bump several). If a marketplace.json exists, read its plugins[] and note, for the plugin being bumped, whether an entry carries a "version". Match the entry to the plugin by "name" first, falling back to comparing the "source" path against the plugin's directory — normalize both before comparing (strip a leading ./ and any trailing /, or just compare basenames), since source is written various ways (./packages/foo, packages/foo/). Flag it now if the manifest and marketplace versions already disagree, since that changes what "in sync" should become.

Step 2 — Determine the new version

Read the current version and follow the scheme it already uses rather than imposing one. Two conventions show up in practice:

SemVer (1.4.2), optionally with a pre-release (1.5.0-rc1, 1.5.0-rc.2, 1.5.0-beta.1 — dotted or undotted; match whatever's there).
A trailing pre-GA letter (0.3.0b) — some plugins append a bare letter to mark every release as not-yet-stable. Preserve that suffix verbatim on numeric bumps; only drop it when the user explicitly stabilizes.

Default to a patch bump that preserves whatever suffix is present, unless the user asks for something else:

Current	Action	New
`1.4.2`	patch (default)	`1.4.3`
`1.4.2`	minor	`1.5.0`
`1.4.2`	major	`2.0.0`
`1.5.0-rc1`	advance the pre-release series	`1.5.0-rc2`
`1.5.0-rc2`	promote to stable	`1.5.0`
`0.3.0b`	patch, keep suffix (default)	`0.3.1b`
`0.3.1b`	stabilize (drop the suffix)	`0.3.1`

Two things are easy to get wrong, so hold them straight:

Promotion never re-bumps the numbers. Dropping a -rcN or a trailing letter ships the same MAJOR.MINOR.PATCH (1.5.0-rc2 → 1.5.0; 0.3.1b → 0.3.1). If the user wants both a stable release and a higher number, that's two decisions — confirm which they mean.
To iterate within a pre-release, advance the counter rather than the version core (1.5.0-rc1 → 1.5.0-rc2), not 1.5.1-rc1.

To inform the bump type, look at what changed since the last version bump:

git log --oneline -- <plugin-dir>

Confirm the target version with the user before editing anything.

Step 3 — Bump the manifest(s)

Edit the "version" field in <plugin-dir>/.claude-plugin/plugin.json.

If the marketplace entry for this plugin also carries a "version" (from Step 1), update it to the same value so the two never drift. If it does not carry one, leave marketplace.json alone — don't add a field the maintainer chose not to track.

Change only the version field(s). Leave surrounding formatting untouched so the diff is a clean one- or two-line change.

Step 4 — Commit

Commit only the manifest files you changed, by pathspec, so nothing the user happened to already stage gets swept into the release commit:

git commit -- <plugin-dir>/.claude-plugin/plugin.json [<root>/.claude-plugin/marketplace.json]

(A bare git commit records the whole index; the pathspec form commits exactly those files regardless of what else is staged.) Glance at git status first — if the version files show up as already staged alongside unrelated changes, sort that out before committing.

Use a message that names the plugin and the new version. Match the repo's existing convention for the scope — check git log --oneline for prior bump commits, since some repos scope by the package/directory name rather than the plugin's name:

chore(<plugin-or-package-name>): bump version to <version>

Step 5 — Push

A push is what publishes the release: most marketplaces install a plugin from a branch (commonly the default), so once the bumped commit lands on that branch, installs pick it up — no tag required.

That only holds if you push the branch installs actually read. Resolve the current branch and its upstream rather than assuming origin:

git rev-parse --abbrev-ref HEAD          # current branch
git rev-parse --abbrev-ref @{u}          # its configured upstream (remote/branch), if any

If the current branch isn't the one the marketplace installs from (usually the default branch), say so and confirm — pushing a feature branch commits the bump but publishes nothing. With the user's go-ahead, push to the resolved upstream (or git push -u <remote> <branch> if none is set yet). If the push is rejected as non-fast-forward, the remote moved: integrate it (git pull --rebase) and retry — don't force-push a shared release branch.

If this repo instead marks plugin releases with git tags or a CI pipeline, that's the release skill's territory; hand off rather than half-doing both.

Step 6 — Confirm

Print a short summary:

Plugin: <plugin-name>
Previous version → new version
Files bumped: plugin.json (and marketplace.json if synced)
Commit: short SHA
Pushed to: <remote>/<branch>