agentleFS
mattmirelesmattmireles/gemma-tuner-multimodal/.claude/skills/deploy/SKILL.md

deploy

Skill1.5k starsChanged 4 days agoMITView on GitHub

Prepare and ship a **gemma-macos-tuner** release (PyPI) or verify release readiness. Before any publish, run the same blocking gates as CI (Ruff, fast tests, pre-commit when applicable); fix failures before tagging. Use when the user asks to publish to PyPI, cut a release, verify a version tag against pyproject.toml, or confirm release automation. Do not use for ad-hoc training runs or local-only work unless release hygiene is explicitly the goal.

  • Installs packages

We split this skill into the rules it gives an agent

5 rules. 0 are common, 3 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 137 edited versions we read keep these.

  • 3

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do not tag or advise a release until every applicable step succeeds (exit 0):

    line 20
  2. Distinctive:

    On failure: stop, fix root cause, re-run from step 2.

    line 28
  3. Very specific:

    Read README.md and .github/workflows/publish-pypi.yml for tag ↔ version rules and secrets.

    line 32
  4. Distinctive:

    Run Pre-publish gate (blocking).

    line 33
  5. Very specific:

    After a successful publish (or dry-run build), note the artifact paths under dist/ if relevant.

    line 36

“Common” is measured: kept by at least 6 in 10 of the 137 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Deploy / release (gemma-tuner-multimodal)

This skill targets this repository: Python package gemma-macos-tuner (pyproject.toml), macOS-first CI (.github/workflows/ci.yml), and PyPI publish on version tags (.github/workflows/publish-pypi.yml). There is no Cloudflare Worker or wrangler surface in this repo.

What gets shipped

SurfaceHow it ships
PyPI packageTag v<version> where <version> matches project.version in pyproject.toml; workflow builds sdist/wheel and runs twine upload (needs PYPI_TOKEN in repo secrets).

Canonical version truth: pyproject.toml project.version.

Pre-publish gate (blocking)

Do not tag or advise a release until every applicable step succeeds (exit 0):

  1. Install dev deps: pip install -e '.[dev]' (and CPU torch for tests if needed, matching CI—see .github/workflows/ci.yml).
  2. ruff check .
  3. ruff format --check .
  4. pre-commit run --all-files (when verifying full CI parity locally; optional if Ruff alone was requested).
  5. Fast tests: pytest -q -m "not slow" (or the subset CI runs—see workflow for explicit test list).

On failure: stop, fix root cause, re-run from step 2.

Procedure (agent)

  1. Read README.md and .github/workflows/publish-pypi.yml for tag ↔ version rules and secrets.
  2. Run Pre-publish gate (blocking); do not continue until green.
  3. Tag discipline: publish-pypi requires v$VERSION where $VERSION equals project.version in pyproject.toml (e.g. tag v1.1.0 for version 1.1.0).
  4. Credentials: PYPI_TOKEN must be configured on GitHub; do not commit tokens. User may run python -m build and twine check dist/* locally without uploading.
  5. After a successful publish (or dry-run build), note the artifact paths under dist/ if relevant.

CI parity

.github/workflows/ci.yml runs Ruff, pre-commit, and fast pytest on macOS arm64. Manual release prep should honor the same checks.

Anti-patterns

  • Tagging when Ruff or tests are red.
  • Bumping pyproject.toml version without updating the tag format expected by CI.
  • Lowering coverage or lint thresholds to “make release green.”

Related docs

  • README.md
  • docs/CONTRIBUTING.md
  • README/notes/debug-notes.md

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.