Agent skill

EverOS Release Workflow

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

Apache-2.0Auto-check passedDevelopment

Install EverOS Release Workflow

skills CLI

$ npx skills add EverMind-AI/EverOS --skill release -a claude-code

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

GitHub CLI

$ gh skill install EverMind-AI/EverOS release --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/EverMind-AI/EverOS.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/release .claude/skills/release && 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/

Paste into Claude Code

Install the "release" agent skill from https://github.com/EverMind-AI/EverOS/tree/main/.claude/skills/release into .claude/skills/release/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "release", then confirm the skill loads.

Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.

$skill-installer

$skill-installer install https://github.com/EverMind-AI/EverOS/tree/main/.claude/skills/release

Type this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.

skills CLI

$ npx skills add EverMind-AI/EverOS --skill release -a codex

Project install goes to .agents/skills/; add -g for ~/.codex/skills/.

GitHub CLI

$ gh skill install EverMind-AI/EverOS release --agent codex

Project scope by default (.agents/skills/); add --scope user for a personal install.

Manual copy

$ git clone --depth 1 https://github.com/EverMind-AI/EverOS.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.claude/skills/release .agents/skills/release && rm -rf skills-src

Use ~/.agents/skills/ instead of .agents/skills for a personal install.

Codex skills documentation · loads skills from .agents/skills/

Paste into Codex

Install the "release" agent skill from https://github.com/EverMind-AI/EverOS/tree/main/.claude/skills/release into .agents/skills/release/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "release", then confirm the skill loads.

Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.

skills CLI

$ npx skills add EverMind-AI/EverOS --skill release -a cursor

Project install goes to .agents/skills/; add -g for ~/.cursor/skills/.

GitHub CLI

$ gh skill install EverMind-AI/EverOS release --agent cursor

Project scope by default (.agents/skills/); add --scope user for a personal install.

Manual copy

$ git clone --depth 1 https://github.com/EverMind-AI/EverOS.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.claude/skills/release .cursor/skills/release && rm -rf skills-src

Use ~/.cursor/skills/ instead of .cursor/skills for a personal install.

Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/

Paste into Cursor

Install the "release" agent skill from https://github.com/EverMind-AI/EverOS/tree/main/.claude/skills/release into .cursor/skills/release/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "release", then confirm the skill loads.

Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.

gemini skills install

$ gemini skills install https://github.com/EverMind-AI/EverOS.git --path .claude/skills/release

--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.

skills CLI

$ npx skills add EverMind-AI/EverOS --skill release -a gemini-cli

Project install goes to .agents/skills/; add -g for ~/.gemini/skills/.

GitHub CLI

$ gh skill install EverMind-AI/EverOS release --agent gemini-cli

Project scope by default (.agents/skills/); add --scope user for a personal install.

Manual copy

$ git clone --depth 1 https://github.com/EverMind-AI/EverOS.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.claude/skills/release .gemini/skills/release && rm -rf skills-src

Use ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.

Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/

Paste into Gemini CLI

Install the "release" agent skill from https://github.com/EverMind-AI/EverOS/tree/main/.claude/skills/release into .gemini/skills/release/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "release", then confirm the skill loads.

Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.

GitHub CLI

$ gh skill install EverMind-AI/EverOS release

Installs for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).

skills CLI

$ npx skills add EverMind-AI/EverOS --skill release -a github-copilot

Project install goes to .agents/skills/; add -g for ~/.copilot/skills/.

Manual copy

$ git clone --depth 1 https://github.com/EverMind-AI/EverOS.git skills-src && mkdir -p .github/skills && cp -r skills-src/.claude/skills/release .github/skills/release && rm -rf skills-src

Use ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.

GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/

Paste into GitHub Copilot

Install the "release" agent skill from https://github.com/EverMind-AI/EverOS/tree/main/.claude/skills/release into .github/skills/release/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "release", then confirm the skill loads.

GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.

skills CLI

$ npx skills add EverMind-AI/EverOS --skill release -a opencode

OpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.

GitHub CLI

$ gh skill install EverMind-AI/EverOS release --agent opencode

Project scope by default (.agents/skills/); add --scope user for a personal install.

Manual copy

$ git clone --depth 1 https://github.com/EverMind-AI/EverOS.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.claude/skills/release .opencode/skills/release && rm -rf skills-src

Use ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.

OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/

Paste into OpenCode

Install the "release" agent skill from https://github.com/EverMind-AI/EverOS/tree/main/.claude/skills/release into .opencode/skills/release/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "release", then confirm the skill loads.

OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.

Facts

Skill name: release
GitHub stars: 13k
Token cost: ~1.3k tokens
SKILL.md length: 509 words
Files: 1
Skills in repo: 5
Repo updated: Oct 6, 2026
First seen: Oct 7, 2026
Licence: Apache-2.0

At a glance

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

Works in 2 steps: PyPI trusted publisher — PyPI → project… → GitHub environment — repo Settings →…
Publishing a new everos version to PyPI
SKILL.md covers Preconditions, Steps, The release page and Pre-releases, plus 1 more section
Calls git, gh and pip; reaches pypi.org

What it does

This skill covers publishing a new version of the everos Python package to PyPI. Pushing a version tag starts a GitHub workflow that builds the package, smoke-tests it and uploads it through PyPI Trusted Publishing, with a manual approval gate on the release environment before anything goes out.

Before starting, the agent confirms you are on an up-to-date main branch with passing CI and picks the version number by SemVer rules. The tag has to match the version in pyproject.toml, and a stable tag needs a matching CHANGELOG.md section, otherwise the workflow refuses to publish. The text of the release page is written in CHANGELOG.md during the release PR; the workflow turns it into a draft GitHub Release that someone still has to read through and publish by hand.

When your agent uses it

Publishing a new everos version to PyPI
Preparing the CHANGELOG.md section that becomes the GitHub Release page
Checking that a version tag matches pyproject.toml before pushing it

Example prompts

“Cut a patch release of everos with the fixes merged since the last tag.”
“Move the Unreleased changelog entries into a new version section and prepare the release PR.”
“The release workflow rejected my tag. Check whether it matches the pyproject.toml version.”

Requirements

A checkout of the everos repository on an up-to-date main branch
Permission to push version tags and approve the release environment

Workflow steps

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

PyPI trusted publisher — PyPI → project everos → Settings →
GitHub environment — repo Settings → Environments → create release

What it can do on your machine

Read from SKILL.md and the folder at commit d2aa949. 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
- pip
From the folder's file list and the shell code blocks in SKILL.md.
Network
Hosts in commands or code, which the agent is likely to contact:
- pypi.org
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

EverOS Release Workflow loads about 1.3k tokens when it runs. Until then it costs about 22 tokens; SKILL.md has 509 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it: ~22
When it runs · the whole SKILL.md, loaded when a task matches: ~1.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 EverMind-AI/EverOS at commit d2aa949, republished under its Apache-2.0 licence (© EverMind-AI). 509 words, ~1,279 tokens.

Download SKILL.mdSave it as .claude/skills/release/SKILL.md (or your agent's skills folder).

name: release
description: Cut a versioned release and publish everos to PyPI via the tag-triggered workflow

/release

Publish a new version of everos to PyPI. Publishing is automated: pushing a vX.Y.Z tag triggers .github/workflows/release.yml, which builds, smoke-tests, and uploads via PyPI Trusted Publishing (OIDC — no stored token) behind the release environment's manual-approval gate, then drafts the GitHub Release page from the CHANGELOG.

A release is not finished when PyPI accepts the upload: the GitHub Release page is drafted, never auto-published, and someone has to write its lead summary and click Publish.

Preconditions

On main, up to date, with green CI (the tag builds from main's tree).
Decide the version per SemVer: patch = fixes, minor = back-compatible features, major = breaking changes.

Steps

1. Bump the version    → pyproject.toml [project] version = "X.Y.Z"
   (single source; everos.__version__ reads installed package metadata)
2. Update CHANGELOG.md → move the Unreleased entries under a new
   ## [X.Y.Z] - <date> heading, and write the release page's prose here
   (lead paragraph + `### Upgrade` group — see "The release page")
3. Commit              → git commit -m "chore(release): vX.Y.Z"
4. Open a PR, merge to main after green CI
5. Tag main + push     → git tag -a vX.Y.Z -m "vX.Y.Z" && git push origin vX.Y.Z
6. Approve             → the release.yml run pauses on the `release`
   environment; a reviewer approves in the Actions run
7. Verify              → https://pypi.org/project/everos/X.Y.Z/
8. Publish the page    → the run leaves a DRAFT GitHub Release, already
   complete if step 2 was done properly. Read it once, click Publish.

The tag must equal the pyproject.toml version — the workflow refuses to publish on a mismatch. A stable tag with no matching ## [X.Y.Z] CHANGELOG section fails the release job for the same reason.

The release page

The whole page is written in CHANGELOG.md, during the release PR. Nothing is meant to be composed at publish time — by then the changes are weeks old and the text gets no review. Write the version section like this:

markdown

## [X.Y.Z] - 2026-09-01

**What this release is for.** One paragraph, prose, no bullets — it becomes the
lead of the release page. Say what changed for a user, not what was refactored.

### Added
### Changed
### Fixed

### Upgrade

What a reader must know before upgrading: what happens on first startup, which
command recovers a bad state, which pins moved. Omit the group entirely when a
plain `pip install --upgrade` is all there is — 1.1.4 and 1.2.0 have nothing
here. Do not write filler.

CI turns that into the page: everything above ### Upgrade is lifted verbatim with the group headings demoted to ##, and the Upgrade prose is wrapped in the boilerplate — pip line above it, compare link below — which is the shape every release since 1.1.3 has. See 1.2.1.

So publishing is a read-through and a click. If the draft looks wrong, the fix belongs in CHANGELOG.md on main, not only in the draft — otherwise the two drift apart and the next release inherits the habit.

While it is a draft, GitHub serves the release at releases/tag/untagged-<hash>, and that URL keeps serving a stale page after publication with no redirect. Never share it — a reader who opens it later concludes the release never went out. Link releases/tag/vX.Y.Z instead; the job prints both URLs in its step summary.

Show full SKILL.md (198 more words)Show less

Publish with the Publish release button in the web UI. Publishing through the API by flipping draft alone drops the tag: GitHub rebinds the release to the untagged-<hash> placeholder and creates a git tag by that name against the default branch (observed on 1.2.2). Pass tag_name if you must do it from the CLI:

bash

gh api -X PATCH "repos/EverMind-AI/EverOS/releases/<id>" \
  -F draft=false -f tag_name=vX.Y.Z -f make_latest=true

Re-running the release job replaces its own draft and leaves an already-published release untouched, so a re-run is always safe.

Pre-releases

PEP 440 pre-release tags publish too (PyPI accepts them; pip install everos ignores them unless --pre): vX.Y.ZrcN, vX.Y.ZaN, vX.Y.ZbN. Set the same suffix in pyproject.toml version before tagging.

Their release page is drafted as a pre-release and never becomes /releases/latest. A pre-release does not need its own CHANGELOG section — the draft falls back to a one-line placeholder body when there is none.

One-time setup (project owner, not doable from CI)

PyPI trusted publisher — PyPI → project everos → Settings → Publishing → add: owner EverMind-AI, repo EverOS, workflow release.yml, environment release.
GitHub environment — repo Settings → Environments → create release with required reviewers, so every publish needs a manual approval.

No PyPI API token is ever stored; the workflow mints a short-lived OIDC token at publish time.

Files

Just SKILL.md in .claude/skills/release of EverMind-AI/EverOS.

Open the folder on GitHubat commit d2aa949

Compare with similar skills

EverOS Release Workflow 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.

EverOS Release Workflow compared with similar skills
Skill	Stars	Used in	Tokens	Auto-check	Licence	Repo updated
EverOS Release Workflow this skillEverMind-AI/EverOS	13k	—	~1.3k	Automated safety check: Pass	Apache-2.0	yesterday
Cline CLI Release Publishercline/cline	70k	—	~3.4k	Automated safety check: Warn	Apache-2.0	today
Universal Project Release WorkflowJimLiu/baoyu-skills	26k	—	~4.9k	Automated safety check: Pass	MIT	27 days ago
LobeHub Version Releaselobehub/lobehub	83k	—	~1.2k	Automated safety check: Pass	Custom licence	today
ClickUp CLI Release Processkrodak/clickup-cli	121	—	~906	Automated safety check: Warn	MIT	yesterday
OpenWork Release Processdifferent-ai/openwork	24k	—	~2.3k	Automated safety check: Pass	Custom licence	today

Similar skills

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
Universal Project Release Workflow
JimLiu/baoyu-skills
Detects a project's version file and changelog format, then runs a release: bumping the version, writing release notes and creating GitHub releases, including backfill.
26k GitHub stars~4.9k tokensUpdated 27 days ago
DevelopmentAuto-check passed
LobeHub Version Release
lobehub/lobehub
Guides the release PR flow, the CI rules that tag a release and the writing of GitHub Release notes for a repo that develops on a canary branch.
83k GitHub stars~1.2k tokensUpdated today
DevelopmentAuto-check passed
ClickUp CLI Release Process
krodak/clickup-cli
Walks through releasing a new version of clickup-cli: pre-release checks, version bump, tagging, CI watch, release notes and the Homebrew update.
121 GitHub stars~906 tokensUpdated yesterday
DevOps & CloudAuto-check: warnings
OpenWork Release Process
different-ai/openwork
Cuts an OpenWork desktop release through a tag-driven GitHub Actions workflow that makes no commits, with pre-tag checks on open fix PRs and verification afterward.
24k GitHub stars~2.3k tokensUpdated today
DevOps & CloudAuto-check passed
Mole CLI Release Flow
tw93/Mole
Runbook for assessing and executing a Mole CLI release: distribution channels, pre-flight checks, capital-V tags, build artifacts and the handoff to curated release notes.
70k GitHub stars~2.5k tokensUpdated today
DevelopmentAuto-check passed

Questions about EverOS Release Workflow

What does EverOS Release Workflow do?

Walks through cutting a versioned everos release: bump the version, update the changelog, tag it, and review the drafted GitHub Release page before publishing. This skill covers publishing a new version of the everos Python package to PyPI. Pushing a version tag starts a GitHub workflow that builds the package, smoke-tests it and uploads it through PyPI Trusted Publishing, with a manual approval gate on the release environment before anything goes out.

When should I use EverOS Release Workflow?

EverOS Release Workflow fits situations like: publishing a new everos version to PyPI; preparing the CHANGELOG.md section that becomes the GitHub Release page; checking that a version tag matches pyproject.toml before pushing it.

How do I install EverOS Release Workflow in Claude Code?

Run `npx skills add EverMind-AI/EverOS --skill release -a claude-code`. Or copy the skill folder (.claude/skills/release in EverMind-AI/EverOS) into .claude/skills/release in your project. Claude Code loads it when a task matches its description.

How do I install EverOS Release Workflow in Codex?

Run `npx skills add EverMind-AI/EverOS --skill release -a codex`. Or copy the skill folder (.claude/skills/release in EverMind-AI/EverOS) into .agents/skills/release in your project. Codex loads it when a task matches its description.

Can I use EverOS Release Workflow 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 EverMind-AI/EverOS --skill release -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/release, .gemini/skills/release, .github/skills/release and .opencode/skills/release in your project.

What does EverOS Release Workflow need to run?

Going by SKILL.md and its folder, EverOS Release Workflow needs the command-line tools its instructions call (git, gh and pip). Our summary lists: A checkout of the everos repository on an up-to-date main branch; Permission to push version tags and approve the release environment.

Does EverOS Release Workflow access the network?

SKILL.md names 1 domain. In commands or code: pypi.org; the agent is likely to contact it when it follows the instructions. This is read from the text; nothing was executed.

Is EverOS Release Workflow 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 EverOS Release Workflow use?

EverOS Release Workflow is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does EverOS Release Workflow use?

About 1.3k tokens (SKILL.md is roughly 5.1k 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 EverOS Release Workflow?

Skills that share tags, products or a category with EverOS Release Workflow: Cline CLI Release Publisher (cline/cline, 70k stars), Universal Project Release Workflow (JimLiu/baoyu-skills, 26k stars), LobeHub Version Release (lobehub/lobehub, 83k stars) and ClickUp CLI Release Process (krodak/clickup-cli, 121 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains EverOS Release Workflow?

EverMind-AI (a GitHub organization) maintains it in EverMind-AI/EverOS, which has 13,360 GitHub stars. The repository holds 5 skills in this directory. The repository was last updated on October 6, 2026.

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

EverOS Release Workflow

Install EverOS Release Workflow

Facts

At a glance

What it does

When your agent uses it

Example prompts

Requirements

Workflow steps

What it can do on your machine

Tool permissions

Runs code

Network

Credentials

Context cost

Safety

SKILL.md

/release

Preconditions

Steps

The release page

Pre-releases

One-time setup (project owner, not doable from CI)

Files

Compare with similar skills

Similar skills

Cline CLI Release Publisher

Universal Project Release Workflow

LobeHub Version Release

ClickUp CLI Release Process

OpenWork Release Process

Mole CLI Release Flow

More from EverMind-AI/EverOS

Add Memory Kind

Conventional Commit Writer

New Branch from Main

Pull Request with Project Template

Questions about EverOS Release Workflow

Install EverOS Release Workflow

Facts

At a glance

What it does

When your agent uses it

Example prompts

Requirements

Workflow steps

What it can do on your machine

Tool permissions

Runs code

Network

Credentials

Context cost

Safety

SKILL.md

/release

Preconditions

Steps

The release page

Pre-releases

One-time setup (project owner, not doable from CI)

Files

Compare with similar skills

Similar skills

More from EverMind-AI/EverOS

Related

Questions about EverOS Release Workflow