agent-skill-deploy
Original:🇺🇸 English
Translated
3 scripts
Deploys agent skill collections from any GitHub repository with a /skills folder to one or more distribution surfaces: GitHub releases, Claude Code marketplace, VS Code plugin marketplace, and Copilot CLI plugin marketplace. Handles pre-flight validation, conventional commit analysis, version bumping across surface configs, and surface-specific publishing with dry-run support. Use when releasing, publishing, or deploying a skills collection to any supported marketplace or creating a GitHub release for a skills repository. Don't use for deploying non-skill packages, npm modules, Docker images, or Azure resources.
3installs
Sourcewebmaxru/ai-native-dev
Added on
NPX Install
npx skill4agent add webmaxru/ai-native-dev agent-skill-deployTags
Translated version includes tags in frontmatterSKILL.md Content
View Translation Comparison →Agent Skill Collection Deploy
Purpose
Automate multi-surface deployment of agent skill collections:
- Pre-flight validation of git state, skills inventory, and surface readiness
- Conventional commit analysis with version bump recommendation
- Version bumping across all detected surface configuration files
- Surface-specific deployment with dry-run capability
- User approval gates before irreversible operations
When to Use This Skill
Use this skill when the user:
- Asks to "release", "deploy", "publish", or "ship" a skills collection
- Wants to bump versions and push to one or more marketplaces
- Needs to create a GitHub release for a skills repository
- Wants to publish skills to Claude Code, VS Code, or Copilot CLI marketplaces
- Asks to check deployment readiness or run a dry-run release
Do not use for npm packages, Docker deployments, Azure resource provisioning, or repositories without a directory.
/skillsSupported Surfaces
| Surface | Config Files | Deploy Action | Tool Required |
|---|---|---|---|
| github | Git remote URL | Create tag + GitHub release | |
| claude-code | | Bump plugin version, commit, push | |
| vscode | | Bump version, commit, push | |
| copilot-cli | | Bump plugin version, commit, push | |
Bundled Scripts
This skill includes three Node.js helper scripts in for cross-platform operation (Windows and macOS):
scripts/- deploy-preflight.mjs — Validates git state, discovers surfaces, checks tool availability, verifies version consistency (including git tag version)
- deploy-analyze.mjs — Inventories skills, analyzes commits since last tag, recommends version bump
- deploy-execute.mjs — Bumps versions in all detected config files (regardless of selected surfaces), commits, tags, and deploys to selected surfaces
Run scripts from the skill directory:
bash
node scripts/deploy-preflight.mjs
node scripts/deploy-analyze.mjs
node scripts/deploy-execute.mjs 1.2.0 --surfaces github,claude-code --dry-runVersion Handling Rules
Marketplace.json files contain two distinct version fields with different semantics:
- (plugin version) — Tracks the version of each listed plugin. Bumped during releases for local plugins (where
plugins[].versionissource)."." - (marketplace version) — Tracks the version of the marketplace collection itself. Never bumped during skill/plugin releases. Managed independently.
metadata.version
Cross-file sync rules:
- All plugin versions must stay consistent: ,
plugin.json,package.jsonin marketplace files, and the git tag.plugins[].version - All values across marketplace.json files (
metadata.versionand.claude-plugin/marketplace.json) must stay in sync with each other..github/plugin/marketplace.json
Deploy Workflow
Follow these steps in order. Stop immediately if any step fails.
Step 1: Pre-flight Checks
Run the preflight script to validate readiness:
bash
node scripts/deploy-preflight.mjsThis checks:
- Current directory is a git repository
- Current branch is or
mastermain - Working tree is clean (no uncommitted changes)
- directory exists and contains at least one skill
/skills - Detects which surfaces are configured based on existing config files
- Verifies required tools are available for each surface
- Checks that both and
.claude-plugin/plugin.jsonexist; warns if either is missing (auto-created during deploy).github/plugin/plugin.json - Reports version consistency across all surface configs, including git tag version
If checks fail, report the problem and suggest a fix. Do not proceed.
Step 2: Analyze Changes
Run the analysis script to understand what changed:
bash
node scripts/deploy-analyze.mjsThis will:
- Inventory all skills in with their names
/skills - Find the last release tag (or handle first release)
- List all commits since that tag
- Count commits by conventional type using anchored regex
- Detect breaking changes (suffix or
type!:in body)BREAKING CHANGE - Show file change statistics
- Print a version bump recommendation
Version bump criteria:
| Bump | When |
|---|---|
| Major | Breaking changes — |
| Minor | New features — any |
| Patch | Everything else — |
Step 2b: Build Per-Skill Changelog
When the github surface is selected, build a concise, human-readable changelog grouped by skill. This replaces GitHub's auto-generated notes.
Procedure:
- Identify the previous release tag from output (the
deploy-analyze.mjsline). If this is the first release, compare against the root commit.Last release tag - For each skill listed in the output, run:
Skills Changedbashgit diff v{{PREVIOUS}}..HEAD -- skills/{{SKILL_NAME}}/ - Analyze each diff and produce a concise bullet list summarizing user-visible changes per skill. Guidelines:
- Write each bullet as a short, action-oriented statement (e.g., "Added X", "Fixed Y", "Removed Z").
- Group by skill as a level-2 heading ().
## skill-name - Omit internal-only changes (whitespace, line-ending normalization) unless they are the only change.
- Mention version bumps within skill metadata only if no other substantive changes exist for that skill.
- Cap at roughly 5–7 bullets per skill; combine minor items if needed.
- Store the assembled Markdown changelog text for use in Step 9.
Example output format:
markdown
## agent-package-manager
- Added subdirectory path and pinned tag dependency examples to template
- Expanded manifest reference with Azure DevOps and GitLab guidance
- Added "APM not installed" troubleshooting section
## agent-skill-deploy
- Made marketplace.json optional for Claude Code surface detection
- Simplified version bump recommendation logic
## github-agentic-workflows
- Added install.md URL reference for agent-assisted setupIf only a single skill changed, omit the heading and use a flat bullet list.
Step 3: Confirm Version and Surfaces with User
Present the analysis summary and ask the user to choose a version and target surfaces.
Use the AskUserQuestion tool for version:
AskUserQuestion:
question: "Recommended: {{RECOMMENDATION}}. Which version bump for v{{CURRENT}} → v{{NEXT}}?"
header: "Version"
options:
- label: "Major (v{{MAJOR}})"
description: "Breaking changes — skill removals, renames, config restructuring"
- label: "Minor (v{{MINOR}})"
description: "New features — new skills, significant enhancements"
- label: "Patch (v{{PATCH}})"
description: "Fixes, docs, refactoring, chore, CI, tests"
- label: "Cancel"
description: "Abort the deployment"Replace with current version, compute , , by incrementing the relevant segment (reset lower segments to 0).
{{CURRENT}}{{MAJOR}}{{MINOR}}{{PATCH}}If user selects Cancel, stop the workflow.
Use the AskUserQuestion tool for surfaces:
AskUserQuestion:
question: "Detected surfaces: {{DETECTED_SURFACES}}. Which surfaces to deploy to?"
header: "Surfaces"
options:
- label: "All detected ({{DETECTED_SURFACES}})"
description: "Deploy to every surface that has config files"
- label: "GitHub release only"
description: "Create tag and GitHub release"
- label: "Marketplaces only"
description: "Update marketplace configs without GitHub release"
- label: "Custom selection"
description: "Specify exact surfaces"
- label: "Cancel"
description: "Abort the deployment"Step 4: Dry Run (Recommended)
Before making changes, perform a dry run to verify what will happen:
bash
node scripts/deploy-execute.mjs {{VERSION}} --surfaces {{SURFACES}} --dry-runPresent the dry-run output to the user. The dry run shows:
- Which files will be modified and how
- Which git operations will be performed
- Which surface-specific deploy commands will run
- No files are changed, no git operations are executed
If the dry run reveals issues, address them before proceeding.
Step 5: Bump Versions
Execute the version bump across all detected surface configs:
bash
node scripts/deploy-execute.mjs {{VERSION}} --surfaces {{SURFACES}} --bump-onlyIMPORTANT — version sync invariant: The script always bumps every detected config file (plugin.json, marketplace.json, package.json) regardless of which surfaces were selected via . This prevents version drift between surfaces. The flag only controls which deployment actions run in mode.
--surfaces--surfaces--pushAuto-creation of missing plugin.json: Before bumping, the script checks that both (claude-code surface) and (copilot-cli surface) exist. If either file is missing, it is automatically created from the sibling plugin.json (preferred) or from metadata (name, description, version, author, repository, license, keywords) as a fallback. The copilot-cli variant also gets .
.claude-plugin/plugin.json.github/plugin/plugin.jsonpackage.json"skills": "skills/"This updates version fields in:
- →
.claude-plugin/plugin.json(claude-code surface).version - →
.claude-plugin/marketplace.json(claude-code surface, only if the file exists).plugins[0].version - →
package.json(vscode and copilot-cli surfaces).version - →
.github/plugin/plugin.json(copilot-cli surface, only if the file exists).version - →
.github/plugin/marketplace.jsonand.plugins[0].version(copilot-cli surface, only if the file exists).metadata.version
If is absent, the plugin is assumed to be listed by a marketplace defined in another repository. Only is bumped.
marketplace.jsonplugin.jsonVerify all files were updated correctly by reading them back.
Step 6: Commit Version Bump
Stage and commit all modified config files:
bash
git add -A
git commit -m "Release v{{VERSION}}"Step 7: Create Git Tag
Tag the release commit:
bash
git tag v{{VERSION}}Step 8: User Approval Before Push
CRITICAL: Always pause here for user approval.
Present a summary and ask for confirmation.
Use the AskUserQuestion tool:
AskUserQuestion:
question: "Ready to push v{{VERSION}} and deploy to {{SURFACES}}?"
header: "Deploy"
options:
- label: "Yes — push and deploy"
description: "Push commits, tags, and run surface-specific deployments"
- label: "Push only — skip surface deploys"
description: "Push commits and tags but skip marketplace-specific actions"
- label: "No — keep local"
description: "Keep local commit and tag, do not push"If user selects No, inform them:
- The commit and tag remain local
- To undo:
git reset --hard HEAD~1 && git tag -d v{{VERSION}}
Step 9: Push and Deploy
Only after user approves:
- Save the per-skill changelog from Step 2b to a temporary file:
bash
echo '{{CHANGELOG}}' > /tmp/release-notes.md - Run the push and deploy:
bash
node scripts/deploy-execute.mjs {{VERSION}} --surfaces {{SURFACES}} --push --notes-file /tmp/release-notes.md
This performs:
- for all surfaces
git push && git push --tags - For github surface: create the release using the per-skill changelog from Step 2b:
Ifbash
gh release create v{{VERSION}} --title "v{{VERSION}}" --notes-file /tmp/release-notes.mdis not provided, the script falls back to--notes-file. Always prefer providing the per-skill changelog.--generate-notes
After pushing, print the remote URL and relevant marketplace links.
Error Handling
- No directory: Report that the repository does not follow the expected skill collection layout and stop.
/skills - Missing tools: Report which tools are missing for which surfaces. Suggest installation commands. Allow deployment to surfaces whose tools are available.
- Version mismatch across surfaces: Report the mismatch and suggest running the bump step to synchronize all config files.
- Tag already exists: Report the conflict and suggest either choosing a different version or deleting the existing tag with user confirmation.
- Push failure: Report the error. Do not retry automatically. Suggest checking remote access and authentication.
- Surface deploy failure: If one surface fails, report it but continue with remaining surfaces. Provide per-surface status summary at the end.
- Dry-run divergence: If the actual execution differs from the dry run, pause and report the divergence to the user.