Agent skill

Release And Versioning

by greenpau in greenpau/caddy-security

Maintain VERSION, release targets, versioned artifacts, GoReleaser packaging, and publication.

Apache-2.0Auto-check passedBackend & APIs

Install Release And Versioning

skills CLI
$ npx skills add greenpau/caddy-security --skill release-and-versioning -a claude-code

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

GitHub CLI
$ gh skill install greenpau/caddy-security release-and-versioning --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/greenpau/caddy-security.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.codex/skills/release-and-versioning .claude/skills/release-and-versioning && 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
release-and-versioning
GitHub stars
2.3k
Token cost
~2.5k tokens
SKILL.md length
1,241 words
Files
4 (incl. references)
Skills in repo
29
Repo updated
First seen
Licence
Apache-2.0

At a glance

Maintain VERSION, release targets, versioned artifacts, GoReleaser packaging, and publication.

  • Works in 4 steps: Confirm the intended version, main… → Verify dependencies resolve to the… → Run the requested make release or make… → …
  • Release preparation
  • SKILL.md covers Version Authority, Existing Release Targets, Preparation and Publication and CI and Automation Validation
  • Calls make, go and git

What it does

Release And Versioning is an agent skill from greenpau/caddy-security. Maintain VERSION, release targets, versioned artifacts, GoReleaser packaging, and publication. Use for release preparation, version checks, and explicitly requested releases; dependency refresh is separate.

Its SKILL.md is about 2.5k tokens, which your agent loads only when the skill is triggered. The skill folder holds 5 other files, including reference files (for example `agents/openai.yaml`, `references/ci-and-packaging.md` and `references/final-qualification.md`).

It sits in Backend & APIs. The repository describes itself as: 🔐 Authentication, Authorization, and Accounting (AAA) App and Plugin for Caddy v2. 💎 Implements Form-Based, Basic, Local, LDAP, OpenID Connect, OAuth 2.0 (Github, Google…. The licence is Apache-2.0.

When your agent uses it

  • Release preparation
  • Explicitly requested releases
  • Dependency refresh is separate

Example prompts

  • “/release-and-versioning”

Workflow steps

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

  1. Confirm the intended version, main checkout, clean index/worktree including
  2. Verify dependencies resolve to the intended published versions. Resolve any
  3. Run the requested make release or make minor-release once. The script
  4. Confirm the release commit, annotated tag, VERSION and intended publication

What it can do on your machine

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

    • make
    • go
    • 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

Release And Versioning loads about 2.5k tokens when it runs, and up to ~6.7k if it reads all its reference files. Until then it costs about 57 tokens; SKILL.md has 1,241 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~57
When it runs · the whole SKILL.md, loaded when a task matches
~2.5k
With references · SKILL.md plus every file in references/, read only if the agent opens them
~6.7k

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 greenpau/caddy-security at commit a48553d, republished under its Apache-2.0 licence (© greenpau). 1,241 words, ~2,486 tokens.

Download SKILL.mdSave it as .claude/skills/release-and-versioning/SKILL.md (or your agent's skills folder). This skill also uses 3 other files; get the full folder from GitHub.
name
release-and-versioning
description
Maintain VERSION, release targets, versioned artifacts, GoReleaser packaging, and publication. Use for release preparation, version checks, and explicitly requested releases; dependency refresh is separate.

Release and Versioning

Follow the repository scope. Version edits, dependency refreshes, commits, tags, and publication apply only to caddy-security. Read sibling versions/history as inputs; do not bump, sync, fetch into, tag, or release a sibling to unblock this module. Missing upstream releases are separate work. Keep chosen snapshot and report destinations here.

Version Authority

VERSION owns the caddy-security release number. Preserve the existing 1.<minor>.<patch> release line, with no v in the file and v<VERSION> for the Git tag. A feature change or dependency update alone does not request a version bump or publication. Read current values from the checkout instead of copying versions from examples or the sibling repository.

Keep these version surfaces distinct:

  • Makefile reads VERSION into PLUGIN_VERSION; release recipes read it again for the commit subject and annotated tag.
  • assets/scripts/generate_downloads.sh projects VERSION into README Caddy download URLs. It separately hard-codes the caddy-trace version. Verify its Download Caddy with the plugins enabled insertion marker exists before regenerating links, and inspect their placement afterward. The macOS branch requires gsed as well as BSD sed.
  • go.mod selects the go-authcrunch dependency version; ../go-authcrunch/VERSION is the sibling library's release number. Neither sets this module's version. make sync updates dependency references and removes local replacements; it is a separate dependency refresh, not caddy-security version synchronization.
  • cmd/authcrunch/main.go delegates to Caddy. It has no application version fallback declarations to synchronize. The Makefile does not inject its PLUGIN_VERSION with linker flags, so bin/authcrunch version alone does not establish this module's release identity.
  • bin/authcrunch security version reads the linked go-authcrunch module from embedded Go build metadata. It retains pseudo-versions and shows replacements, including (devel) for unversioned local paths. This is dependency identity, distinct from Caddy's version and this repository's release number; see security dependency version.
  • cmd/caddy-authenticator/main.go initializes *versioned.PackageManager with a literal fallback for ordinary go install builds. make build injects VERSION into main.appVersion; caddy-authenticator version prints its banner. GoReleaser builds separate platform archives and injects release/snapshot version, commit and build metadata; see CI and packaging. Keep the fallback synchronized using make version-sync after an explicit VERSION change. Sync validates VERSION first and changes only the existing fallback; it neither bumps the release nor stages files.

make version-check validates the fixed-major namespace through assets/scripts/version.py without rewriting files. It accepts a single optional trailing newline, rejects leading zeros and prerelease/build suffixes, and bounds components for versioned. check --tag additionally requires the exact v<VERSION> tag. It does not validate README link placement or contents. The check also rejects a missing, ambiguous or stale authenticator fallback; artifact identity validation enforces the same consistency without rewriting it.

make artifact-id validates the version and produces v<VERSION>_<UTC YYYYMMDDTHHMMSSZ>_<12-character SHA> for branch/PR/manual builds. An exact v<VERSION> tag produces v<VERSION>; another tag fails. GITHUB_SHA provides the checked CI revision (including PR merge commits), with local HEAD as fallback. Validated version and artifact_id values go to GITHUB_OUTPUT.

make release increments the patch; make minor-release increments the minor and resets the patch to zero. Both preserve the major release line. assets/scripts/version.py next --kind patch|minor computes the candidate without writing files and rejects an increment beyond the supported range. version-sync projects VERSION into the authenticator fallback only.

Existing Release Targets

Read the current Makefile before executing release operations. The targets have different side effects:

TargetActual behavior
make release-git-checkRead-only local check of main, a clean worktree/index including untracked files, and synchronized version values. Does not check the remote or run the quality gate.
make releaseRuns assets/scripts/release.sh patch for the complete checked patch release.
make minor-releaseRuns the same script with minor, resetting the patch to zero.
make fast-releaseRuns the patch workflow with --skip-tests, skipping local make ci-check.
make fast-minor-releaseRuns the minor workflow with --skip-tests, skipping local make ci-check.
make release-update-version, make release-git-commitFail with instructions to use a complete release target; partial publication paths are disabled.

The shared script serializes checks, bump, synchronization, download generation, make ci-check, commit, tag, and push even under parallel Make. It requires main with no tracked, staged, or untracked changes, fetches origin/main, rejects behind/diverged history and an existing candidate tag locally or on origin, and checks the README marker and macOS gsed prerequisite before bumping. The pinned go tool versioned command comes from go.mod; release operations do not depend on a globally installed versioned executable.

For regular releases, the gate runs once against the bumped version, including the binary build. Fast releases skip the entire local gate (automation tests, Go tests/reports, and build); GitHub release validation still runs before GoReleaser publication. All version/Git checks, synchronization, download generation, staging restrictions and atomic publication remain in place. Use a fast target only when the user requests it; release-git-check does not accept --skip-tests. Only VERSION, README.md, and cmd/caddy-authenticator/main.go are staged. Unexpected staged, other tracked, or untracked changes stop publication. The commit subject is ops: released v<VERSION> and the exact tag is annotated. One atomic push publishes HEAD:refs/heads/main and that tag to origin; unrelated local tags are excluded. There is no fallback to separate pushes.

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

Preparation and Publication

For a status check, start with read-only evidence: git status --short --untracked-files=all, git branch --show-current, git diff, git diff --cached, VERSION, and existing tags. make release-git-check adds the local preflight without modifying files. Release preparation can inspect and validate without executing a bump or publishing target.

For an actual release, carry forward the user's existing authorization and:

  1. Confirm the intended version, main checkout, clean index/worktree including untracked files, intended remote, remote branch state, and absence of the intended tag locally and remotely. Do not rely on stale remote-tracking refs or let unrelated staged changes enter the release commit.
  2. Verify dependencies resolve to the intended published versions. Resolve any local go-authcrunch replacement through the dependency refresh workflow before qualifying the release. Run make dep to resolve pinned tools and dependencies. Review any source changes before proceeding; validation itself must not rewrite them.
  3. Run the requested make release or make minor-release once. The script bumps, synchronizes projections, runs the complete gate, commits and tags the validated contents, and publishes the two explicit refs atomically. When a fast release is requested, use make fast-release or make fast-minor-release; only the local gate is skipped.
  4. Confirm the release commit, annotated tag, VERSION and intended publication refer to the same revision. Never force an existing release ref.

Only bump, tag, push, or dispatch a publishing workflow within the user's requested scope. A request to explain or port release guidance is not a request to execute a release. Do not ask again for actions already authorized.

If any step fails, inspect the worktree, index, release commit/tag, and remote refs before continuing. A transport failure can leave the outcome uncertain. Preserve that evidence and report the last completed step. Do not rerun the entire release, bump again, reset changes, delete tags, or retract a version as automatic recovery.

CI and Automation Validation

For release CI, artifact identity, dependency changelogs, toolchains, and packaging validation, read CI and packaging. It distinguishes the current workflow from release gates that would need implementation. For complete Caddy target builds, source/artifact vulnerability evidence, stripped-symbol limitations and unresolved official OP outcomes, use final integration qualification.

For automation changes, exercise success and failure paths in disposable repositories with local bare remotes. Include dirty/untracked state, wrong branch, an existing tag, unrelated local tags, failed validation, and rejected pushes as relevant to the change. Never test release automation by publishing this repository. For skill-only edits, validate skill metadata, links, and claims against source; no release, version bump, or Go build is needed.

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

Files

SKILL.md and 3 other files (references) in .codex/skills/release-and-versioning of greenpau/caddy-security.

  • SKILL.md
  • agents/openai.yaml
  • references/ci-and-packaging.md
  • references/final-qualification.md

Open the folder on GitHubat commit a48553d

Compare with similar skills

Release And Versioning 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.

Release And Versioning compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Release And Versioning this skillgreenpau/caddy-security2.3k—~2.5kAutomated safety check: PassApache-2.0
Configuring Horizoncoollabsio/coolify63k4 repos~898Automated safety check: PassMIT
Nestjs Best Practicesrolling-scopes/rsschool-app10k6 repos~1.2kAutomated safety check: PassMIT
Sub2API AdminWei-Shaw/sub2api44k1 repos~717Automated safety check: PassLGPL-3.0
Firecrawl Build Onboardingfirecrawl/firecrawl190k1 repos~1.4kAutomated safety check: NotesISC
Obsidian BasesAtmosphere/atmosphere3.8k22 repos~3.2kAutomated safety check: PassApache-2.0

Similar skills

  • Configuring Horizon

    coollabsio/coolify

    A skill your agent uses whenever the user mentions Horizon by name in a Laravel context.

    63k GitHub starsUsed in 4 repos~898 tokens
    Backend & APIsAuto-check passed
  • Nestjs Best Practices

    rolling-scopes/rsschool-app

    NestJS best practices and architecture patterns for building production-ready applications.

    10k GitHub starsUsed in 6 repos~1.2k tokens
    Backend & APIsAuto-check passed
  • Sub2API Admin

    Wei-Shaw/sub2api

    Manages a Sub2API deployment from the command line: accounts, redeem and invitation codes, groups, proxies, imports, exports and raw admin API calls.

    44k GitHub starsUsed in 1 repo~717 tokens
    Backend & APIsAuto-check passed
  • Firecrawl Build Onboarding

    firecrawl/firecrawl

    Gets Firecrawl working in a project: signs you in through the browser, saves FIRECRAWL_API_KEY to .env and picks the first SDK or REST path.

    190k GitHub starsUsed in 1 repo~1.4k tokens
    Backend & APIsAuto-check: notes
  • Obsidian Bases

    Atmosphere/atmosphere

    Create and edit Obsidian Bases (.base files) with views, filters, formulas, and summaries.

    3.8k GitHub starsUsed in 22 repos~3.2k tokens
    Backend & APIsAuto-check passed
  • Fortify Development

    coollabsio/coolify

    ACTIVATE when the user works on authentication in Laravel. An agent skill from coollabsio/coolify.

    63k GitHub starsUsed in 4 repos~1.9k tokens
    Backend & APIsAuto-check passed

More from greenpau/caddy-security

All 29 skills in this repo
  • Authentication Portal API

    greenpau/caddy-security

    Build or troubleshoot portal JSON/native login clients, refresh, profile and admin APIs, and public JWKS.

    2.3k GitHub stars~2.9k tokensUpdated 4 days ago
    Auto-check passed
  • Coding Directives

    greenpau/caddy-security

    Implement or review caddy-security Go code, Caddy modules, parsers, lifecycle, and HTTP delegation.

    2.3k GitHub stars~4.1k tokensUpdated 4 days ago
    Auto-check passed
  • Configuration

    greenpau/caddy-security

    Build or review caddy-security Caddyfiles and select focused configuration skills.

    2.3k GitHub stars~2.6k tokensUpdated 4 days ago
    Auto-check passed
  • Configuration Crypto

    greenpau/caddy-security

    Configure portal/policy JWT keys, token names and lifetimes, key loading and generation, public-key discovery, and System API encryption keys.

    2.3k GitHub stars~3.5k tokensUpdated 4 days ago
    Auto-check passed
  • Configuration HTTP Integrations

    greenpau/caddy-security

    Mount authenticate and authorize handlers, separate portal and protected routes, align auth URLs, and preserve trusted proxy metadata.

    2.3k GitHub stars~3.2k tokensUpdated 4 days ago
    Auto-check passed
  • Configuration State

    greenpau/caddy-security

    Configure durable AuthCrunch runtime state, exclusive storage ownership, stop/start persistence, reload rejection, and recovery.

    2.3k GitHub stars~1.6k tokensUpdated 4 days ago
    Auto-check passed

Categories

Questions about Release And Versioning

What does Release And Versioning do?

Maintain VERSION, release targets, versioned artifacts, GoReleaser packaging, and publication. Release And Versioning is an agent skill from greenpau/caddy-security. Maintain VERSION, release targets, versioned artifacts, GoReleaser packaging, and publication.

When should I use Release And Versioning?

Release And Versioning fits situations like: release preparation; explicitly requested releases; dependency refresh is separate.

How do I install Release And Versioning in Claude Code?

Run `npx skills add greenpau/caddy-security --skill release-and-versioning -a claude-code`. Or copy the skill folder (.codex/skills/release-and-versioning in greenpau/caddy-security) into .claude/skills/release-and-versioning in your project. Claude Code loads it when a task matches its description.

How do I install Release And Versioning in Codex?

Run `npx skills add greenpau/caddy-security --skill release-and-versioning -a codex`. Or copy the skill folder (.codex/skills/release-and-versioning in greenpau/caddy-security) into .agents/skills/release-and-versioning in your project. Codex loads it when a task matches its description.

Can I use Release And Versioning 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 greenpau/caddy-security --skill release-and-versioning -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-and-versioning, .gemini/skills/release-and-versioning, .github/skills/release-and-versioning and .opencode/skills/release-and-versioning in your project.

What does Release And Versioning need to run?

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

Does Release And Versioning 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 Release And Versioning 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 And Versioning use?

Release And Versioning 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 Release And Versioning use?

About 2.5k tokens (SKILL.md is roughly 9.9k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 4.2k tokens, read only when the agent opens those files.

What are the alternatives to Release And Versioning?

Skills that share tags, products or a category with Release And Versioning: Configuring Horizon (coollabsio/coolify, 63k stars), Nestjs Best Practices (rolling-scopes/rsschool-app, 10k stars), Sub2API Admin (Wei-Shaw/sub2api, 44k stars) and Firecrawl Build Onboarding (firecrawl/firecrawl, 190k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Release And Versioning?

greenpau (a GitHub user) maintains it in greenpau/caddy-security, which has 2,252 GitHub stars. The repository holds 29 skills in this directory. The repository was last updated on October 5, 2026.

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