Install the "release" agent skill from https://github.com/mahmoud/lithoxyl/tree/master/.omp/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.
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 mahmoud/lithoxyl --skill release -a codex
Project install goes to .agents/skills/; add -g for ~/.codex/skills/.
Install the "release" agent skill from https://github.com/mahmoud/lithoxyl/tree/master/.omp/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 mahmoud/lithoxyl --skill release -a cursor
Project install goes to .agents/skills/; add -g for ~/.cursor/skills/.
Install the "release" agent skill from https://github.com/mahmoud/lithoxyl/tree/master/.omp/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.
--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 mahmoud/lithoxyl --skill release -a gemini-cli
Project install goes to .agents/skills/; add -g for ~/.gemini/skills/.
Install the "release" agent skill from https://github.com/mahmoud/lithoxyl/tree/master/.omp/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 mahmoud/lithoxyl 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 mahmoud/lithoxyl --skill release -a github-copilot
Project install goes to .agents/skills/; add -g for ~/.copilot/skills/.
Install the "release" agent skill from https://github.com/mahmoud/lithoxyl/tree/master/.omp/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 mahmoud/lithoxyl --skill release -a opencode
OpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
Install the "release" agent skill from https://github.com/mahmoud/lithoxyl/tree/master/.omp/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
146
Token cost
~1.3k tokens
SKILL.md length
623 words
Files
1
Skills in repo
1
Repo updated
First seen
Licence
BSD-3-Clause
At a glance
Walks through releasing the lithoxyl Python package to PyPI: CalVer version bump, tagging, pushing and checking the published release.
Works in 8 steps: Determine the release version → Update version for release → Update CHANGELOG.md → …
Cutting a new lithoxyl release and publishing it to PyPI
Lithoxyl uses calendar versioning in the form year, minor, micro, kept as a string in `lithoxyl/__init__.py` with a `dev` suffix during development and read by Flit at build time. Tags are bare version numbers without a leading v, and the publish workflow fires on tags that match that pattern. The skill starts with pre-flight checks: a clean working tree, the master branch, a dev suffix on the version, passing tests through `tox -p auto` or pytest, and a look at what PyPI already has.
PyPI is the source of truth: a version already published cannot be re-released, while a tag with no matching PyPI release signals a failed release to retry. After you confirm the version, the agent drops the dev suffix, adds a CHANGELOG.md section from the commits since the last tag for your approval, commits as `lithoxyl version` plus the number, creates an annotated tag, then pushes and verifies the publish, with recovery steps for failures. If a pre-flight check fails, it stops and reports.
When your agent uses it
Cutting a new lithoxyl release and publishing it to PyPI
Bumping the lithoxyl version after a development cycle
Retrying a lithoxyl release that failed after tagging
Example prompts
“Cut a release of lithoxyl and walk me through the version check.”
“Publish lithoxyl to PyPI and verify the new version is live.”
“The last lithoxyl release failed after tagging; help me recover.”
Requirements
A clean lithoxyl checkout on the master branch
tox or pytest for the test run
Permission to push tags to the repository
Workflow steps
8 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit 07f2fa5. 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
python3
pip
python
pytest
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
Release Lithoxyl loads about 1.3k tokens when it runs. Until then it costs about 56 tokens; SKILL.md has 623 words of instructions outside code blocks.
Always· name and description, kept in context so the agent knows when to use it
~56
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.
Download SKILL.mdSave it as .claude/skills/release/SKILL.md (or your agent's skills folder).
name
release
description
Release lithoxyl to PyPI. Handles version bumping (CalVer YY.MINOR.MICRO), tagging, pushing, and post-publish verification. Use when asked to "release lithoxyl", "cut a release", "publish to PyPI", or "bump version".
Release lithoxyl
lithoxyl uses CalVer: YY.MINOR.MICRO (e.g. 26.0.1). The version lives in
lithoxyl/__init__.py as a __version__ literal string. During development it
carries a dev suffix (e.g. 26.0.1dev). Flit reads this at build time.
Tags are bare CalVer (e.g. 26.0.1, NOT v26.0.1). The publish workflow
triggers on tags matching [0-9]*.[0-9]*.[0-9]*.
Pre-flight checks
Before starting, verify ALL of these:
Working tree is clean (git status shows nothing dirty/staged)
You are on master branch
lithoxyl/__init__.py has a dev suffix on __version__
All tests pass: tox -p auto (or at minimum pytest lithoxyl/tests/ -v)
Check what is actually published on PyPI: https://pypi.org/project/lithoxyl/PyPI is canonical. If the intended version already exists on PyPI, it
cannot be re-released -- bump to the next version instead. If a local/GitHub
tag exists for a version that is NOT on PyPI, the prior release failed and
should be retried (see "Failed release" under Error recovery).
If any check fails, stop and report. Do not proceed with a dirty tree or
failing tests.
Release steps
1. Determine the release version
Read __version__ from lithoxyl/__init__.py. Strip the dev suffix.
Example: 26.0.1dev becomes 26.0.1.
Ask the user to confirm the version. If they want a different version
(e.g. bumping minor instead of micro), use that instead.
2. Update version for release
Edit lithoxyl/__init__.py: remove the dev suffix from __version__.
python
# Before
__version__ = '26.0.1dev'
# After
__version__ = '26.0.1'
3. Update CHANGELOG.md
Add a new section at the top of CHANGELOG.md (below the # lithoxyl Changelog
heading) for the release version. Use this format:
markdown
## 26.0.1
_(Month Day, Year)_
- First change description
- Second change description
To determine what changed, review the commits since the last tag:
Summarize the user-facing changes as concise bullet points. Omit version bump
commits and other release-mechanical commits. Ask the user to confirm or adjust
the changelog entry.
4. Commit the release
bash
git commit -am "lithoxyl version 26.0.1"
Use the exact format lithoxyl version X.Y.Z for the commit message.
5. Tag the release
bash
git tag -a 26.0.1 -m "short summary of key changes in this release"
Tags are bare CalVer. No v prefix. The tag message should be a short,
lowercase, descriptive summary of the release (not just the version number).
Examples:
"migrate to flit, expand test coverage, add CI"
"python 3.10-3.13 support, windows fixes"
"modernize build system, drop python 2"
6. Bump to next dev version
Increment the micro version and add dev suffix:
python
__version__ = '26.0.2dev'
7. Commit the dev bump
bash
git commit -am "bump version to 26.0.2dev"
Show full SKILL.md (257 more words)Show less
8. Push
bash
git push origin master --tags
This triggers two GitHub Actions workflows:
Tests (on the push to master)
Publish to PyPI (on the tag)
The publish workflow validates that __version__ on the tagged commit does
not contain dev and matches the tag. It parses __version__ from the file
with sed rather than importing the module (the build job does not install
dependencies). If either check fails, publishing is blocked.
Post-publish verification
After pushing, wait ~2 minutes for PyPI propagation, then verify in a
temporary virtualenv outside the repo (to avoid the local source tree
shadowing the installed package):
bash
python3 -m venv /tmp/lithoxyl-verify && source /tmp/lithoxyl-verify/bin/activate
pip install lithoxyl==26.0.1 --index-url https://pypi.org/simple/
cd /tmp # MUST leave repo root so local lithoxyl/ does not shadow the install
python -c "import lithoxyl; print(lithoxyl.__version__)"
# Should print: 26.0.1
deactivate && rm -rf /tmp/lithoxyl-verify
If --index-url fails with 404, wait another minute and retry. PyPI CDN
propagation can take 1-5 minutes.
Report the results to the user.
Error recovery
Failed release (tag exists locally/on GitHub but not on PyPI): PyPI is
the source of truth. Delete the stale tag locally and on the remote:bash
git tag -d X.Y.Z
git push origin :refs/tags/X.Y.Z # if it was pushed
Then check __version__ in lithoxyl/__init__.py. If it was already bumped
past the failed release (e.g. X.Y.(Z+1)dev), reset it to X.Y.Zdev so
the release flow strips the suffix to the correct version. Amend or revert
the bump commit as needed, then restart the release from step 1.
Wrong version tagged: git tag -d X.Y.Z && git push origin :refs/tags/X.Y.Z
then fix and re-tag.
Publish workflow failed: Check the GitHub Actions log. Common causes:
version mismatch, dev suffix present, PyPI trusted publisher not configured.
Tests fail after publish: The package is already on PyPI. File an issue,
fix forward with a patch release.
Release Lithoxyl 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.
Publishes a ccLoad Beta or explicit stable release through a version-tag workflow, including commit, push, CI wait, GitHub Release and container image checks.
Walks through releasing the lithoxyl Python package to PyPI: CalVer version bump, tagging, pushing and checking the published release. py` with a `dev` suffix during development and read by Flit at build time. Tags are bare version numbers without a leading v, and the publish workflow fires on tags that match that pattern.
When should I use Release Lithoxyl?
Release Lithoxyl fits situations like: cutting a new lithoxyl release and publishing it to PyPI; bumping the lithoxyl version after a development cycle; retrying a lithoxyl release that failed after tagging.
How do I install Release Lithoxyl in Claude Code?
Run `npx skills add mahmoud/lithoxyl --skill release -a claude-code`. Or copy the skill folder (.omp/skills/release in mahmoud/lithoxyl) into .claude/skills/release in your project. Claude Code loads it when a task matches its description.
How do I install Release Lithoxyl in Codex?
Run `npx skills add mahmoud/lithoxyl --skill release -a codex`. Or copy the skill folder (.omp/skills/release in mahmoud/lithoxyl) into .agents/skills/release in your project. Codex loads it when a task matches its description.
Can I use Release Lithoxyl 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 mahmoud/lithoxyl --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 Release Lithoxyl need to run?
Going by SKILL.md and its folder, Release Lithoxyl needs the command-line tools its instructions call (git, python3, pip, python and pytest). Our summary lists: A clean lithoxyl checkout on the master branch; tox or pytest for the test run; Permission to push tags to the repository.
Does Release Lithoxyl 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 Release Lithoxyl 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 Release Lithoxyl use?
Release Lithoxyl is published under the BSD-3-Clause licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Release Lithoxyl use?
About 1.3k tokens (SKILL.md is roughly 5.4k 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 Release Lithoxyl?
Skills that share tags, products or a category with Release Lithoxyl: Pypi Release (alchemiststudiosDOTai/tunacode, 125 stars), Project Init (athola/claude-night-market, 342 stars), ccLoad Release Publisher (caidaoli/ccLoad, 418 stars) and Sap Btp Business Application Studio (secondsky/sap-skills, 462 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Release Lithoxyl?
mahmoud (a GitHub user) maintains it in mahmoud/lithoxyl, which has 146 GitHub stars. The repository was last updated on July 17, 2026.
Source: mahmoud/lithoxyl on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.
