New: 98,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

Production Release

by latitude-dev in latitude-dev/latitude-llm

Preparing a production release, pushing a vX.Y.Z release tag, running scripts/release.sh, or updating CHANGELOG.md with the changes that are about to be deployed to production.

MITAuto-check passedDevelopment

Install Production Release

skills CLI
$ npx skills add latitude-dev/latitude-llm --skill production-release -a claude-code

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

GitHub CLI
$ gh skill install latitude-dev/latitude-llm production-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/latitude-dev/latitude-llm.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/production-release .claude/skills/production-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/

Facts

Skill name
production-release
GitHub stars
4.7k
Token cost
~1.3k tokens
SKILL.md length
695 words
Files
1
Skills in repo
28
Repo updated
First seen
Licence
MIT

At a glance

Preparing a production release, pushing a vX.Y.Z release tag, running scripts/release.sh, or updating CHANGELOG.md with the changes that are about to be deployed to production.

  • Works in 6 steps: Treat it as approval to perform the full… → Determine the next patch version from… → Update CHANGELOG.md for that next patch… → …
  • Tasks that involve Changelog and release notes
  • SKILL.md covers Release invariants, Default behavior when no extra…, Workflow and Changelog style
  • Calls git

What it does

Production Release is an agent skill from latitude-dev/latitude-llm. Preparing a production release, pushing a vX.Y.Z release tag, running scripts/release.sh, or updating CHANGELOG.md with the changes that are about to be deployed to production.

Its SKILL.md is about 1.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 Changelog and release notes. The repository describes itself as: Open-source observability for AI agents. Find where your agents fail, dispatch your coding agent to fix it, and verify the fix against real traces. The licence is MIT.

When your agent uses it

  • Tasks that involve Changelog and release notes

Example prompts

  • “/production-release”

Workflow steps

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

  1. Treat it as approval to perform the full patch release workflow.
  2. Determine the next patch version from the latest vX.Y.Z tag.
  3. Update CHANGELOG.md for that next patch version using the production diff.
  4. Set version and appVersion in charts/latitude/Chart.yaml to the new
  5. Commit both with the exact message release: vX.Y.Z and push to
  6. Run scripts/release.sh --yes (without an explicit version) so it tags the

What it can do on your machine

Read from SKILL.md and the folder at commit 12e8591. 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

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

  • Network

    No URLs in SKILL.md. Its commands use git, 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

Production Release loads about 1.3k tokens when it runs. Until then it costs about 49 tokens; SKILL.md has 695 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~49
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 latitude-dev/latitude-llm at commit 12e8591, republished under its MIT licence (© latitude-dev). 695 words, ~1,335 tokens.

Download SKILL.mdSave it as .claude/skills/production-release/SKILL.md (or your agent's skills folder).
name
production-release
description
Preparing a production release, pushing a vX.Y.Z release tag, running scripts/release.sh, or updating CHANGELOG.md with the changes that are about to be deployed to production.

Production release

Use this skill when preparing a production deployment. If the skill is invoked without additional context or constraints, assume the user wants the default patch production release flow: update CHANGELOG.md, bump the Helm chart version, commit both as release: vX.Y.Z, push it to origin/development, and run the production tag script for the next patch version. Production deploys are triggered by pushing a vX.Y.Z tag; the changelog is updated at release time as a human-readable diff of the code being pushed to production since the previous production deploy, focused on the major aspects rather than every commit.

Release invariants

  • development is trunk and deploys to staging by default.
  • Production is triggered only by pushing a vX.Y.Z tag that points at the latest origin/development commit.
  • Do not promote by merging development into main.
  • Do not tag unreleased local-only commits. The release commit, including any changelog update, must be pushed to origin/development before tagging.
  • The changelog release commit message must always have the exact shape release: vX.Y.Z, for example release: v1.2.3.
  • Update CHANGELOG.md during release preparation, before running the command that pushes the production tag.
  • The Helm chart (charts/latitude/Chart.yaml) tracks the Latitude release: set both version and appVersion to X.Y.Z (no leading v) in the same release: vX.Y.Z commit as the changelog. scripts/release.sh refuses to tag a release whose chart version does not match.

Default behavior when no extra context is given

When the user only invokes this skill (or says something like "production release") without specifying a version, dry run, changelog-only update, or other constraint:

  1. Treat it as approval to perform the full patch release workflow.
  2. Determine the next patch version from the latest vX.Y.Z tag.
  3. Update CHANGELOG.md for that next patch version using the production diff.
  4. Set version and appVersion in charts/latitude/Chart.yaml to the new X.Y.Z.
  5. Commit both with the exact message release: vX.Y.Z and push to origin/development.
  6. Run scripts/release.sh --yes (without an explicit version) so it tags the latest origin/development commit with the next patch version. The --yes flag is required when running non-interactively (agent or CI): the script's confirmation prompt cannot be answered without a terminal, and without --yes it exits with an error rather than tagging.

Still obey all release invariants: never tag local-only commits, never promote via main, and stop to ask if the working tree or branch state makes the release unsafe or ambiguous.

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

Workflow

  1. Push the commit intended for production to origin/development; the release script always tags the latest origin/development commit after fetching.
  2. Fetch tags and identify the previous production release tag:
    bash
    git fetch origin development --tags
git tag -l 'v*' --sort=-v:refname | grep -E '^v[0-9]+\.[0-9]+\.[0-9]+$' | head -n 1
  3. Inspect the release range (<latest-tag>..origin/development, or the initial release range if no tag exists) as the production diff. Read the commits and changed files enough to understand the main shipped behavior, not just the commit titles.
  4. Update CHANGELOG.md before deploying:
    • keep ## Unreleased at the top;
    • add a section for the release version and date, for example ## v1.2.3 - 2026-05-27;
    • summarize the major aspects of the production diff in language humans can scan quickly;
    • combine small related commits into one meaningful entry;
    • list only changes included in the release range;
    • group entries by area when helpful;
    • include references such as PR numbers or short commit SHAs when they help readers trace the change;
    • skip internal-only noise that does not matter to operators or users.
  5. Commit the changelog update with message release: vX.Y.Z (matching the release version exactly) and push it to origin/development.
  6. Run scripts/release.sh [version]. Use --dry first when you want to preview the release summary without tagging. Pass --yes to skip the confirmation prompt — always required when running without a terminal (agent or CI), otherwise the script errors out instead of tagging.

Changelog style

Use concise, past-tense entries that describe the major shipped behavior. The changelog is not an exhaustive commit log; it is a readable summary of what will change in production compared with the previous deploy:

markdown
## v1.2.3 - 2026-05-27

### Traces

- Added hover popovers for histogram incidents (ref: #3252).
- Fixed native OAuth redirect URI handling (ref: #3254).

Prefer release accuracy over exhaustive commit transcription. If a PR was merged but is not part of the tagged range, it does not belong in that release section. If many commits contribute to one capability, write one entry for the capability instead of one entry per commit.

© latitude-dev, 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 .agents/skills/production-release of latitude-dev/latitude-llm.

Open the folder on GitHubat commit 12e8591

Compare with similar skills

Production Release 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.

Production Release compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Production Release this skilllatitude-dev/latitude-llm4.7k—~1.3kAutomated safety check: PassMIT
Simple Englishmoeru-ai/airi50k2 repos~4.6kAutomated safety check: PassMIT
StarRocks Release NotesStarRocks/starrocks12k—~1.9kAutomated safety check: NotesApache-2.0
Cutting A ReleaseTriliumNext/Trilium38k—~3.2kAutomated safety check: PassAGPL-3.0
React Router Release Notes Prepremix-run/react-router57k—~1.1kAutomated safety check: PassMIT
Mole CLI Release Flowtw93/Mole70k—~2.5kAutomated safety check: PassGPL-3.0

Similar skills

  • Simple English

    moeru-ai/airi

    Write or rewrite technical text with the rules of ASD-STE100 Simplified Technical English so it is clear, unambiguous, and free of AI slop.

    50k GitHub starsUsed in 2 repos~4.6k tokens
    DevelopmentAuto-check passed

  • StarRocks Release Notes

    StarRocks/starrocks

    Drafts English release notes for a StarRocks patch release from the PRs merged into its release branch, then opens a documentation PR and hands translation to /translate.

    12k GitHub stars~1.9k tokensUpdated today
    DevelopmentAuto-check: notes

  • Cutting A Release

    TriliumNext/Trilium

    A skill your agent uses when cutting, preparing, or debugging a Trilium release — bumping the monorepo version, tagging, or diagnosing a failed "Release" workflow run.

    38k GitHub stars~3.2k tokensUpdated today
    DevelopmentAuto-check passed

  • React Router Release Notes Prep

    remix-run/react-router

    Polishes pending React Router change files before the versioning scripts run, and decides whether a long-form What's Changed section is warranted.

    57k GitHub stars~1.1k tokensUpdated yesterday
    DevelopmentAuto-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

  • Release

    PrefectHQ/fastmcp

    Cut a FastMCP release end to end. An agent skill from PrefectHQ/fastmcp.

    28k GitHub stars~2.9k tokensUpdated today
    DevelopmentAuto-check passed

More from latitude-dev/latitude-llm

All 28 skills in this repo

  • Better Auth Best Practices

    latitude-dev/latitude-llm

    Configure Better Auth server and client, set up database adapters, manage sessions, add plugins, and handle environment variables.

    4.7k GitHub starsUsed in 7 repos~1.6k tokens
    Auto-check passed

  • Artifact Designer

    latitude-dev/latitude-llm

    Create, validate, preview, and publish self-contained HTML artifacts.

    4.7k GitHub stars~1.1k tokensUpdated today
    Auto-check passed

  • CI Watchdog

    latitude-dev/latitude-llm

    Continuously monitor GitHub PR CI checks and automatically fix failures until all checks pass.

    4.7k GitHub stars~1.6k tokensUpdated today
    Auto-check passed

  • Temporal Developer

    latitude-dev/latitude-llm

    This skill should be used when the user asks to "create a Temporal workflow", "write a Temporal activity", "debug stuck workflow", "fix non-determinism error", "Temporal Python", "Temporal…

    4.7k GitHub stars~1.5k tokensUpdated today
    Auto-check passed

  • Docs

    latitude-dev/latitude-llm

    Review the current conversation context and git changes, then persist durable repository knowledge into dev-docs/.md by domain and into AGENTS.md for cross-cutting repo rules.

    4.7k GitHub stars~2.5k tokensUpdated today
    Auto-check passed

  • Managing Maintenance Windows

    latitude-dev/latitude-llm

    Enables or disables Latitude production maintenance mode by redirecting all publicly exposed production services to the Better Stack status page.

    4.7k GitHub stars~802 tokensUpdated today
    Auto-check passed

Categories

Questions about Production Release

What does Production Release do?

Preparing a production release, pushing a vX.Y.Z release tag, running scripts/release.sh, or updating CHANGELOG.md with the changes that are about to be deployed to production. Production Release is an agent skill from latitude-dev/latitude-llm.md with the changes that are about to be deployed to production.

When should I use Production Release?

Production Release fits situations like: tasks that involve Changelog and release notes.

How do I install Production Release in Claude Code?

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

How do I install Production Release in Codex?

Run `npx skills add latitude-dev/latitude-llm --skill production-release -a codex`. Or copy the skill folder (.agents/skills/production-release in latitude-dev/latitude-llm) into .agents/skills/production-release in your project. Codex loads it when a task matches its description.

Can I use Production Release 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 latitude-dev/latitude-llm --skill production-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/production-release, .gemini/skills/production-release, .github/skills/production-release and .opencode/skills/production-release in your project.

What does Production Release need to run?

Going by SKILL.md and its folder, Production Release needs the command-line tools its instructions call (git).

Does Production Release access the network?

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

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

Production Release 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 Production Release use?

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

Skills that share tags, products or a category with Production Release: Simple English (moeru-ai/airi, 50k stars), StarRocks Release Notes (StarRocks/starrocks, 12k stars), Cutting A Release (TriliumNext/Trilium, 38k stars) and React Router Release Notes Prep (remix-run/react-router, 57k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Production Release?

latitude-dev (a GitHub organization) maintains it in latitude-dev/latitude-llm, which has 4,714 GitHub stars. The repository holds 28 skills in this directory. The repository was last updated on October 7, 2026.

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