New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Deploy

by jazzyalex in jazzyalex/agent-sessions

A skill your agent uses when shipping a release of Agent Sessions — bumping version, updating CHANGELOG, building, signing, notarizing, publishing appcast, and creating a GitHub release.

MITAuto-check passedDevelopment

Install Deploy

skills CLI
$ npx skills add jazzyalex/agent-sessions --skill deploy -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install jazzyalex/agent-sessions deploy --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/jazzyalex/agent-sessions.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/deploy .claude/skills/deploy && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
deploy
GitHub stars
892
Token cost
~3.3k tokens
SKILL.md length
1,784 words
Files
1
Skills in repo
8
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses when shipping a release of Agent Sessions — bumping version, updating CHANGELOG, building, signing, notarizing, publishing appcast, and creating a GitHub release.

  • Works in 6 steps: Scope — git log --oneline --decorate -n… → Build — xcodebuild -project… → Full test suite —… → …
  • Shipping a release of Agent Sessions — bumping version
  • SKILL.md covers Canonical Sources (Single…, Workspace Policy (Hard Rule), QA Gate (Mandatory — Run… and Before Starting (Ask the User), plus 7 more sections
  • Calls git, gh and xcodebuild

What it does

Deploy is an agent skill from jazzyalex/agent-sessions. Use when shipping a release of Agent Sessions — bumping version, updating CHANGELOG, building, signing, notarizing, publishing appcast, and creating a GitHub release.

Its SKILL.md is about 3.3k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Deployment and Changelog and release notes. It works with GitHub. The repository describes itself as: Local-first macOS app to browse, search, analyze, and resume supported AI coding-agent session history across Codex, Claude Code, OpenCode, Cursor Agent, Antigravity, Hermes… The licence is MIT.

When your agent uses it

  • Shipping a release of Agent Sessions — bumping version
  • Updating CHANGELOG
  • Publishing appcast
  • Creating a GitHub release

Example prompts

  • “/deploy”

Requirements

  • Python 3

Workflow steps

6 steps, taken from the first numbered list in SKILL.md.

  1. Scope — git log --oneline --decorate -n 30 and git diff --name-only ..HEAD; identify high-risk areas.
  2. Build — xcodebuild -project AgentSessions.xcodeproj -scheme AgentSessions -configuration Debug build
  3. Full test suite — ./scripts/xcode_test_stable.sh
  4. Targeted tests — run suites for touched high-risk areas (session parsing, usage tracking, onboarding, etc.)
  5. Warnings sweep — flag any new actionable warnings in build output.
  6. Manual smoke reminder — list the manual steps from docs/release/pre-release-qa.md §3–4 and ask the user to confirm GO/NO-GO after…

What it can do on your machine

Read from SKILL.md and the folder at commit 6fa9a73. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git
    • gh
    • xcodebuild
    • python3

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git and gh, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Deploy loads about 3.3k tokens when it runs. Until then it costs about 43 tokens; SKILL.md has 1,784 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~43
When it runs · the whole SKILL.md, loaded when a task matches
~3.3k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from jazzyalex/agent-sessions at commit 6fa9a73, republished under its MIT licence (© jazzyalex). 1,784 words, ~3,260 tokens.

Download SKILL.mdSave it as .claude/skills/deploy/SKILL.md (or your agent's skills folder).
name
deploy
description
Use when shipping a release of Agent Sessions — bumping version, updating CHANGELOG, building, signing, notarizing, publishing appcast, and creating a GitHub release.

Deployment Skill (Agent Sessions)

This skill is an agent-facing entrypoint that avoids duplicating the deployment runbook.

Canonical Sources (Single Source of Truth)

  • Runbook: docs/deployment.md
  • Unified tool: tools/release/deploy (see tools/release/deploy --help)
  • Recommended pre-release QA checklist: docs/release/pre-release-qa.md

If anything here disagrees with the runbook, follow docs/deployment.md.

Workspace Policy (Hard Rule)

  • Always run deployment from the user's current local repository checkout.
  • Do not clone to temporary directories and do not switch to alternate worktrees as a deployment workaround.
  • If the local worktree is dirty, stop and tell the user to clean the tree first (commit, stash, or discard), then continue in the same local repo.

QA Gate (Mandatory — Run Automatically Before Deploy)

  • Always run QA automatically before any bump/release/verify step, unless the user explicitly says to skip it (e.g. "skip QA", "no QA").
  • Do not ask whether to run QA — just run it.
  • QA execution order:
    1. Scope — git log --oneline --decorate -n 30 and git diff --name-only <LAST_TAG>..HEAD; identify high-risk areas.
    2. Build — xcodebuild -project AgentSessions.xcodeproj -scheme AgentSessions -configuration Debug build
    3. Full test suite — ./scripts/xcode_test_stable.sh
    4. Targeted tests — run suites for touched high-risk areas (session parsing, usage tracking, onboarding, etc.)
    5. Warnings sweep — flag any new actionable warnings in build output.
    6. Manual smoke reminder — list the manual steps from docs/release/pre-release-qa.md §3–4 and ask the user to confirm GO/NO-GO after completing them.
  • If automated gates fail → stop, report failure, do not proceed to bump/release.
  • If user says "skip QA" or "no QA" → proceed without running, note it was skipped.

Test count. QA reads the authoritative pass count from the .xcresult bundle (stdout reports per-bundle totals and this scheme has two — it under-reports) and compares it to tools/release/test-count-baseline.txt. A drop warns and continues, deliberately: it does not block a release. So the warning has to actually be read — a deleted suite still exits 0 from xcodebuild, and this line is the only thing that says so. When the count changes for a real reason, update the baseline file in the same release.

Before Starting (Ask the User)

  1. Target version (X.Y for major/minor releases, X.Y.Z only for patch releases; never ship X.Y.0)
  2. Any headline changes (new agents, major features) that must be reflected in docs/CHANGELOG.md
  3. Whether this is a major release that requires onboarding updates
  4. Public copy updates needed for README/GitHub Pages (major changes to highlight, renamed features, or outdated wording to fix)

Do NOT ask about QA status — QA always runs automatically as part of pre-deploy (see QA Gate above).

Public Copy Update (Required for All Releases)

Always update (every release)
  • README.md download link: v{VERSION}/AgentSessions-{VERSION}.dmg and label Download Agent Sessions {VERSION} (DMG)
  • README.md Option A download link (second occurrence under Install section)
  • docs/index.html download button URL and label
  • docs/index.html version meta-line (Version {VERSION} · Free & open source · No telemetry)
Do NOT version-pin the site meta descriptions

docs/index.html's description, og:description and twitter:description are deliberately version-agnostic as of the 2026-08-29 SEO work. This checklist used to demand "mention current version + key change" there, which is how the homepage description reached 541 chars reading "Version 5.0 makes every agent a plug-in adapter…" — past the ~155-char SERP budget, and stale the day after every release.

Leave them alone. If the product's positioning genuinely changes, rewrite them on their own merits and keep the budget: title ≤60, description ≤155. Adding a version string is the one edit that is always wrong. See the reference-docs-site-seo-conventions memory.

Update for minor/major or user-visible feature releases
  • README.md "What's New in X.Y" section: update heading to new version, rewrite TL;DR and Highlights to reflect this release's key changes (do not keep old version's copy)
  • docs/index.html hero/feature copy if features were renamed or new agents added
Never add
  • Versioned "What's New in X.Y" section to docs/index.html
  • Detailed release notes to README or website (those live in docs/CHANGELOG.md)

Never Announce a Bug the User Never Had (Hard Rule)

A fix to a feature that ships in this same release is not a Bug Fix. It is development.

When a feature is new in X.Y, every defect found and fixed in it before X.Y shipped was never in anyone's hands. Listing those under "Bug Fixes" invents a history of breakage users never experienced, and buries the actual feature under a list of things that sound broken. Ship the feature; the fixes are part of it.

Before writing any Bug Fix entry, ask: which released version had this bug? If the answer is "none — the code is new in this release", the entry does not exist. Fold anything user-visible into the feature's own Highlight instead.

Worked example (4.8, Grok CLI's first release):

  • ❌ "A Grok session shows the title its own sidecar records" — Grok shipped in 4.8; no user ever saw the wrong title.
  • ❌ "Grok transcripts open with content in them" — same.
  • ❌ "A Grok session's message count matches its transcript" — same.
  • ✅ "Grok CLI is the eleventh current agent source…" — the Highlight, which already says transcripts, images, Analytics and resume work.

Mixed entries need splitting, not deleting: a fix spanning shipped and new sources is real for the shipped ones. Describe it in terms of those, and drop the new source from the list. In 4.8 the CLI PATH-masking fix covered Cursor, Kimi and Pi (all shipped) plus Grok (new) — it stayed, naming only the three.

This applies identically to docs/CHANGELOG.md, the Sparkle notes, the GitHub release body, and the README "What's New". The changelog is the source all of them derive from, so fix it there first.

After pushing
  • Verify GitHub Pages reflects updated docs/index.html (check the download button and version meta-line; the meta descriptions should read the same as before the release)

Pre-Deploy Checklist (Run Before Bump)

  • docs/CHANGELOG.md [Unreleased] section has full, accurate content for this release (this is the only changelog — root CHANGELOG.md is a pointer to it, not a copy to sync)
  • Every Bug Fix entry names a defect that existed in a released version — no fixes to features shipping in this same release (see "Never Announce a Bug the User Never Had")
  • In-app What's New has an entry for this version in AgentSessions/Onboarding/Models/WhatsNewCatalog.swift — both a teasers line and a bundled array. hasContent goes true on the auto-generated new-provider row alone, so a forgotten release still shows the card, just with one generic line and no teaser. Do not author a row for a new source by hand: providerHighlights(for:) generates it from versionIntroduced, and authoring it again shows it twice.
  • README.md download links updated to new version (both occurrences)
  • README.md "What's New" section updated to new version heading + rewritten highlights
  • docs/index.html download button URL, label, and version meta-line updated
  • docs/index.html meta descriptions left unchanged — they are version-agnostic on purpose (see "Do NOT version-pin the site meta descriptions")
  • All above files committed before running deploy bump (or bump will overwrite)
Show full SKILL.md (682 more words)Show less

Sparkle Notes Are Short and Fun (Hard Rule)

Sparkle notes appear in a small update window. Nobody reads prose there. The 5.0 notes shipped as full changelog paragraphs and had to be republished after the fact — don't repeat that.

  • Highlight: 2–4 sentences, hard max. Lead with the change, keep one concrete number if there is one, cut everything a curious reader can find in the changelog.
  • Feature / Bug Fix bullets: 1–2 sentences. One for what changed, at most one for why it was wrong before. A good bug-fix line can be a single sentence ("Five agents used to skip it silently.").
  • Whole notes: aim under ~250 words. If the preview scrolls, it's too long.
  • Tone: dry fun is welcome — "takes no for an answer", "Bring the agent you use". Personality yes, marketing-speak no, emoji never.
  • The full detail lives in docs/CHANGELOG.md; the notes may compress it freely. If an entry can't be compressed without losing the point, the changelog entry is overweight — tighten it there first (changelog entries also don't need to be essays).
  • Links in changelog entries that feed the notes must be absolute URLs — relative links break in the appcast and the GitHub release body.
  • To republish notes after a release: edit docs/CHANGELOG.md, then python3 tools/release/sparkle_release_notes.py --version <V> --changelog docs/CHANGELOG.md --appcast docs/appcast.xml --github-url <release-url> --lint --out-text /tmp/notes.txt, then gh release edit v<V> --notes-file /tmp/notes.txt, commit and push the appcast.

Sparkle Release Notes (Approval Gate)

  • The release pipeline generates structured Sparkle notes from docs/CHANGELOG.md:
    • Highlights or grouped current-release changes
    • Other changes (summary)
    • Reminder from the baseline release (for patch releases: A.B)
  • During tools/release/deploy release <VERSION>, the deploy script prints a Sparkle release notes preview after build/sign/notarization and appcast validation.
  • Treat the preview as user-facing product copy, not raw commit history:
    • Lead with the headline change the user should care about.
    • Do not include internal cleanup, validation fixes, or pre-release stabilization as “Bug Fixes” if users never received that broken behavior.
    • If the preview is misleading, stop and edit docs/CHANGELOG.md before publishing.
  • If SKIP_CONFIRM is not 1, it will pause and ask for approval before publishing (pushing appcast, updating Homebrew, updating the GitHub release).
  • SKIP_CONFIRM=1 requires RELEASE_NOTES_REVIEWED=1 at the appcast publish gate; set it only after manually inspecting the Sparkle preview or for a rerun whose notes were already reviewed.
  • The notes generator fails before publishing if notes contain obvious internal/process wording or put Bug Fixes ahead of a headline section.
  • GitHub Release notes must use the same curated/linted notes as Sparkle, not raw commit history or raw changelog extraction.
  • If the current release has no structured bullets, the generator adds a fallback highlight: Small bug fixes and stability improvements.

Standard Workflow (Use the Unified Tool)

bash
tools/release/deploy changelog [FROM_TAG]
tools/release/deploy bump [patch|minor|major]
git push origin main
tools/release/deploy release <VERSION> [--dry-run]
tools/release/deploy verify <VERSION>

Failure Handling

  • First stop: docs/deployment.md → Troubleshooting, logs, and rollback guidance.
  • Rollback only after reviewing logs: tools/release/rollback-release.sh <VERSION>.
Read the real exit code, and check what actually published

Two traps, both hit during 5.1.1:

  • Do not wrap the release in ; echo "EXIT: $?". The wrapper's own status is what the caller sees, so a pipeline that correctly exited 4 was reported as 0 and briefly looked like a tooling bug. Run tools/release/deploy release <V> on its own and read its status.

  • A completed run is not a published release. Confirm against the world, not the log:

    bash
    gh release view v<VERSION> --json tagName,isDraft,assets
git ls-remote --tags origin v<VERSION>
grep -n "sparkle:shortVersionString" docs/appcast.xml

    Then tools/release/deploy verify <VERSION> for the full check. A failure before the publish steps leaves nothing public — no release, no tag, appcast unchanged — which is the state to expect after an aborted build.

Watching a long run

The release log embeds the entire QA test output, so a bare keyword grep matches test names, not events — "Aborted", "Homebrew" and "rollback" all produced false alarms during 5.1.1. Anchor on the script's own line markers (^==> , ^✅ , ^ERROR: ) and run the pattern against the live log before trusting it. Note also that ERROR: Release QA stamp is not valid is expected and self-heals whenever HEAD moved after deploy qa — it re-runs QA rather than failing. When matching newest-file-by-glob (/tmp/notarization-<V>-*.log), guard on mtime or you will read the previous run's artifacts.

© jazzyalex, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .claude/skills/deploy of jazzyalex/agent-sessions.

Open the folder on GitHubat commit 6fa9a73

Compare with similar skills

Deploy next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Deploy compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Deploy this skilljazzyalex/agent-sessions892—~3.3kAutomated safety check: PassMIT
EverOS Release WorkflowEverMind-AI/EverOS13k—~1.3kAutomated safety check: PassApache-2.0
Remotion Bits Releaseav/remotion-bits486—~1.2kAutomated safety check: PassNone
Cline CLI Release Publishercline/cline70k—~3.4kAutomated safety check: WarnApache-2.0
ClawRouter Release ChecklistBlockRunAI/ClawRouter6.6k—~1.4kAutomated safety check: PassMIT
AnyDrag Release RoutineXueshiQiao/AnyDrag227—~2.6kAutomated safety check: PassGPL-3.0

Similar skills

  • EverOS Release Workflow

    EverMind-AI/EverOS

    Walks through cutting a versioned everos release: bump the version, update the changelog, tag it, and review the drafted GitHub Release page before publishing.

    13k GitHub stars~1.3k tokensUpdated yesterday
    DevelopmentAuto-check passed

  • Remotion Bits Release

    av/remotion-bits

    Runs the full release of the remotion-bits package: version bump, changelog, registry build, release commit, GitHub release, docs deploy and npm publish.

    486 GitHub stars~1.2k tokensUpdated 22 days ago
    DevelopmentAuto-check passed

  • Cline CLI Release Publisher

    cline/cline

    Walks through releasing the Cline CLI package to npm: release notes, version bump, matching git tag, and either the GitHub workflow or a local publish.

    70k GitHub stars~3.4k tokensUpdated today
    DevelopmentAuto-check: warnings

  • ClawRouter Release Checklist

    BlockRunAI/ClawRouter

    Walks the agent through every ClawRouter release step in order, from the version bump and changelog entry to build, tests, npm publish, git tag and GitHub release.

    6.6k GitHub stars~1.4k tokensUpdated 2 days ago
    DevelopmentAuto-check passed

  • AnyDrag Release Routine

    XueshiQiao/AnyDrag

    Runs the full AnyDrag release process end to end, from cumulative bilingual release notes through version bumping to watching CI and the Homebrew cask update.

    227 GitHub stars~2.6k tokensUpdated 3 days ago
    DevelopmentAuto-check passed

  • Release Process

    GoogleCloudPlatform/genai-factory

    Guide for cutting a new release of the GenAI Factory repository.

    174 GitHub stars~1.3k tokensUpdated 2 days ago
    DevelopmentAuto-check passed

More from jazzyalex/agent-sessions

All 8 skills in this repo

  • Sc Skill

    jazzyalex/agent-sessions

    Capture deterministic macOS screenshots for testing, docs, release notes, and marketing assets.

    892 GitHub stars~884 tokensUpdated yesterday
    Auto-check passed

  • Add Agent Support

    jazzyalex/agent-sessions

    Create and ship AgentSessions support for a new or changed local AI agent/provider.

    892 GitHub stars~2.5k tokensUpdated yesterday
    Auto-check passed

  • Deploy Agent Sessions

    jazzyalex/agent-sessions

    Release/deploy workflow for Agent Sessions (Sparkle appcast + GitHub release).

    892 GitHub stars~817 tokensUpdated yesterday
    Auto-check passed

  • Release Notes

    jazzyalex/agent-sessions

    A skill your agent uses when writing or curating the user-facing release copy for an Agent Sessions release — README "What's New", GitHub release notes, Sparkle release notes, or website/launch copy.

    892 GitHub stars~2.6k tokensUpdated yesterday
    Auto-check passed

  • Agent Support Matrix

    jazzyalex/agent-sessions

    Maintain Agent Sessions agent support matrix and JSON/JSONL parsing compatibility.

    892 GitHub stars~587 tokensUpdated yesterday
    Auto-check passed

  • Agent Session Format Check

    jazzyalex/agent-sessions

    Verify agent session format compatibility for Agent Sessions.

    892 GitHub stars~13k tokensUpdated yesterday
    Auto-check passed

Works with

Categories

Questions about Deploy

What does Deploy do?

A skill your agent uses when shipping a release of Agent Sessions — bumping version, updating CHANGELOG, building, signing, notarizing, publishing appcast, and creating a GitHub release. Deploy is an agent skill from jazzyalex/agent-sessions. Use when shipping a release of Agent Sessions — bumping version, updating CHANGELOG, building, signing, notarizing, publishing appcast, and creating a GitHub release.

When should I use Deploy?

Deploy fits situations like: shipping a release of Agent Sessions — bumping version; updating CHANGELOG; publishing appcast; creating a GitHub release.

How do I install Deploy in Claude Code?

Run `npx skills add jazzyalex/agent-sessions --skill deploy -a claude-code`. Or copy the skill folder (.claude/skills/deploy in jazzyalex/agent-sessions) into .claude/skills/deploy in your project. Claude Code loads it when a task matches its description.

How do I install Deploy in Codex?

Run `npx skills add jazzyalex/agent-sessions --skill deploy -a codex`. Or copy the skill folder (.claude/skills/deploy in jazzyalex/agent-sessions) into .agents/skills/deploy in your project. Codex loads it when a task matches its description.

Can I use Deploy in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add jazzyalex/agent-sessions --skill deploy -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/deploy, .gemini/skills/deploy, .github/skills/deploy and .opencode/skills/deploy in your project.

What does Deploy need to run?

Going by SKILL.md and its folder, Deploy needs the command-line tools its instructions call (git, gh, xcodebuild and python3). Our summary lists: Python 3.

Does Deploy access the network?

SKILL.md contains no URLs. Its commands use git and gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Deploy safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Deploy use?

Deploy is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Deploy use?

About 3.3k tokens (SKILL.md is roughly 13k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Deploy?

Skills that share tags, products or a category with Deploy: EverOS Release Workflow (EverMind-AI/EverOS, 13k stars), Remotion Bits Release (av/remotion-bits, 486 stars), Cline CLI Release Publisher (cline/cline, 70k stars) and ClawRouter Release Checklist (BlockRunAI/ClawRouter, 6.6k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Deploy?

jazzyalex (a GitHub user) maintains it in jazzyalex/agent-sessions, which has 892 GitHub stars. The repository holds 8 skills in this directory. The repository was last updated on October 6, 2026.

Source: jazzyalex/agent-sessions on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.