avav25/release-tools-by-stack
plugin/skills/release-tools-by-stack/SKILL.md
Use this skill when the agent is picking a release tool for a stack or running version bump + changelog generation inside the `/release` workflow — for the release tooling reference covering release-please, semantic-release, Changesets, GoReleaser, cargo-release, JReleaser, plus monorepo per-package versioning via Changesets, Lerna, and Nx, including detection markers, per-tool version-bump + changelog commands, and per-stack release conventions for Node, Go, Rust, and Java.
$ install --global
skillsauthnpx skillsauth add avav25/ai-assets release-tools-by-stackInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 23, 2026, 4:35 AM104.2s1 file scanned
SKILL.md
- name:
- release-tools-by-stack
- description:
- Use this skill when the agent is picking a release tool for a stack or running version bump + changelog generation inside the `/release` workflow — for the release tooling reference covering release-please, semantic-release, Changesets, GoReleaser, cargo-release, JReleaser, plus monorepo per-package versioning via Changesets, Lerna, and Nx, including detection markers, per-tool version-bump + changelog commands, and per-stack release conventions for Node, Go, Rust, and Java.
- disable-model-invocation:
- true
Release Tools by Stack
Per-tool and per-stack reference for the /release workflow. Covers detection of existing release tooling, the version-bump and changelog commands each tool exposes, and monorepo per-package versioning approaches. Knowledge skill — never invoked directly; loaded as context by /release.
Tool Detection Table
Before running any inline release flow, check whether the repo already has release tooling configured. If so, route to it; the team's choice supersedes anything inline.
| Marker file present | Tool |
|---|---|
| release-please-config.json or .release-please-manifest.json | release-please (Google) |
| .releaserc* (.json/.yml/.js) or release.config.js | semantic-release |
| .changeset/ directory + .changeset/config.json | Changesets (monorepo Node) |
| .goreleaser.yaml / .goreleaser.yml | GoReleaser |
| Cargo.toml with [workspace.metadata.release] or local release.toml | cargo-release |
| jreleaser.yml | JReleaser (JVM polyglot) |
If a tool is detected:
- Inspect its config for current state (next version, release branch, prerelease suffixes).
- Run its release command (or open a PR / merge a release-please PR depending on tool).
- Skip the inline version-bump + changelog + tag steps; the tool handles all three.
- Continue at the
/releaseMemory Write step so the release is recorded inruns.jsonl.
Per-tool commands
release-please
Releases happen via the GitHub Action on PR merge. Check for an open release-please PR; review and merge it instead of cutting manually. The action proposes a release PR that bumps versions and updates CHANGELOG.md; merging it creates the tag and GitHub Release.
Detection: release-please-config.json, .release-please-manifest.json.
semantic-release
Releases happen in CI on push to the release branch. Verify the next release will fire; do not bump manually. Commit-message conventions (Conventional Commits) drive the version bump and changelog generation automatically.
Detection: .releaserc* (.json/.yml/.js), release.config.js, or a semantic-release entry in package.json.
Changesets
Monorepo Node release tool. Per-package versioning workflow:
npx changeset— for each affected package, record an intent file (<random>.mdwith package name + bump type + summary).npx changeset version— rewrites all affectedpackage.jsonversions and changelogs based on accumulated intent files.npx changeset publish— tags and publishes (typically via CI).
Detection: .changeset/ directory + .changeset/config.json.
GoReleaser
Go release automation — builds binaries, creates archives, generates checksums, pushes to GitHub Releases / Docker registries.
Command: goreleaser release --clean (CI usually drives it on tag push).
Detection: .goreleaser.yaml or .goreleaser.yml.
cargo-release
Rust release automation for crates.
Command: cargo release <level> — e.g., cargo release minor, cargo release patch, cargo release major.
Detection: Cargo.toml with [workspace.metadata.release], or local release.toml.
JReleaser
JVM polyglot release tool (Java, Kotlin, Scala, etc.).
Command: jreleaser release (Maven and Gradle plugins also available).
Detection: jreleaser.yml.
Monorepo per-package versioning
If .changeset/, pnpm-workspace.yaml, lerna.json, or nx.json is present, the repo uses per-package versioning. Different bump strategy applies — pick by tool present:
Changesets (Node monorepo)
For each affected package:
npx changeset— records an intent file (<random>.md) with package name + bump type + summary.npx changeset version— rewrites all affectedpackage.jsonversions and updates per-package changelogs.npx changeset publish— tags and publishes (or via CI).
Use when: Node monorepo with independent per-package versions; team wants explicit human-authored intent files; pnpm/yarn workspaces.
Lerna
npx lerna version <minor|patch|major>— bumps versions across affected packages.npx lerna version --conventional-commits— derives bumps from commit history.npx lerna publish from-package— releases the bumped packages.
Use when: existing Lerna workspace; Conventional Commits already in use.
Nx release
npx nx release— replaces Lerna for Nx workspaces 17+.
Use when: Nx workspace (17+); team has standardized on Nx tooling for build + release.
For monorepos, fall back to per-package single-package flow only when the team has decided to handle one package outside the workspace tooling.
Per-stack release conventions
If no release tool is detected, the inline /release flow updates version files per stack:
| Stack | Files to Update |
|---|---|
| Node.js | package.json (version field) |
| Java/Maven | pom.xml (<version>) |
| Java/Gradle | build.gradle (version) |
| Python | pyproject.toml (version) |
| .NET | *.csproj (<Version>) |
| Go | Git tag only (no version file) |
When this applies
| Phase | Apply this knowledge |
|---|---|
| /release detection (Step 0a) | Pick tool from the detection table |
| /release version bump (Step 3) | Run the per-tool command, or fall back to per-stack file edits |
| /release changelog (Step 4) | Use the per-tool changelog output (release-please / semantic-release / Changesets generate it; GoReleaser / cargo-release / JReleaser emit release notes) |
| /release monorepo flow (Step 3a) | Route to Changesets / Lerna / Nx based on workspace marker |
Integration
- Used by:
/release(orchestrator — detection + bump + changelog stages) - External references:
- release-please: https://github.com/googleapis/release-please
- semantic-release: https://semantic-release.gitbook.io
- Changesets: https://github.com/changesets/changesets
- GoReleaser: https://goreleaser.com
- cargo-release: https://github.com/crate-ci/cargo-release
- JReleaser: https://jreleaser.org
Related Skills
avav25/knowledge-sync
development
VerifiedTrustedCommunity
Use this skill when running the recurring (daily) knowledge-base rescan for a repo that already has knowledge/.knowledge-sync.yml — the main-thread dispatcher that reads the config, computes the git delta since last_scanned_sha, maps changed paths to affected doc areas, early-exits cheaply when nothing changed, then fans out one Agent(content-writer) per affected area, applies the propose/direct update policy, advances the baseline only on success, and writes an L4 run log — all with the G1 untrusted-content choke-point, secret-scan, deny-list, and budget controls woven in. For first-time setup use /knowledge-sync-init.
1SKILL.mdUpdated May 24, 2026
avav25/knowledge-sync-init
development
VerifiedTrustedCommunity
Use this skill when bootstrapping scheduled knowledge-base sync for a repo that has no knowledge/.knowledge-sync.yml yet — to run one-time setup that detects the knowledge_root from CLAUDE.md/AGENTS.md, maps doc areas to source globs, records opt-in external sources (Linear/Notion/WebFetch, all disabled by default), captures a baseline last_scanned_sha, sets the per-area update policy, generates or seeds knowledge/CONVENTIONS.md, provisions the L4 memory dir, and offers to register the daily routine. Routes ongoing recurring sync operations to /knowledge-sync.
1SKILL.mdUpdated May 24, 2026
avav25/ai-skills-init
tools
VerifiedTrustedCommunity
Use this skill when bootstrapping a target repository to be ai-skills-aware — on the first run of any ai-skills workflow in a fresh repo, when adopting the ai-skills plugin in an existing repo, or after upgrading to a plugin version that adds new memory paths or templates, including when the user does not say "init" but asks to "set up" or "onboard" the repo — to detect codebase type, create CLAUDE.md + AGENTS.md scaffolding, initialize the .ai-skills-memory/ directory tree from L1 templates, and configure .gitignore. Idempotent — safe to re-run. Accepts `--codebase-type <type>` and `--overwrite`. Not for re-initializing only memory — use `/memory-init` instead.
1SKILL.mdUpdated May 18, 2026
avav25/plugin-author
tools
VerifiedTrustedCommunity
Use this skill when extending, repairing, or improving plugin assets, when ingesting a `/feedback` report as a fix-cycle backlog, or when you do not remember which lower-level command is right for the job — the umbrella workflow for ai-skills plugin-asset authoring and maintenance: creating, auditing, fixing, improving, refactoring, and migrating skills, agents, rules, hooks, prompts, schemas, and rubrics inside the plugin. Auto-classifies the request, loads the right knowledge skills (`@prompt-engineering`, `@context-engineering`, `@team-protocols`), and spawns the right subagents (`prompt-engineer`, `system-architect`, `python-engineer`, `software-engineer`, `qa-engineer`, `eval-judge`) via the `Agent` tool.
1SKILL.mdUpdated May 14, 2026