Apache Struts is an open-source Java web framework that helps developers build applications using the Model-View-Controller pattern, separating data and business logic from page presentation and request handling. Java developers use it to create dynamic web applications with interactive forms and database-backed behavior. The catalogue's skills, instructions, and setting support work with Struts projects.
Borrowing it
Nothing to install: this file belongs to apache/struts. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/apache/struts/main/.claude/skills/releasing-struts/SKILL.mdgit clone --depth 1 https://github.com/apache/strutsWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/apache/struts/releasing-struts)<a href="https://agentmods.dev/skills/apache/struts/releasing-struts"><img src="https://agentmods.dev/badge/skills/apache/struts/releasing-struts/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/apache/struts/releasing-struts"><img src="https://agentmods.dev/badge/skills/apache/struts/releasing-struts.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00059 | $0.02163 |
| Opus 5.5 | $0.00024 | $0.00865 |
| Sonnet 5.5 | $0.00012 | $0.00433 |
| Haiku 4.5 | $0.00006 | $0.00216 |
Grade A, and why
releasing-struts scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 21d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 158 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Releasing Struts
Overview
A release is seven phases with a gate between each.
The process itself is published, at
Release Guidelines — every phase, every
command, the release policy and the one-time setup a new release manager needs. It is the source
of truth, it is maintained in apache/struts-site (source/release-guidelines.md), and it is
what you follow.
This skill is the agent's half of it: the judgement about ordering and when to stop, which
sibling skill owns which document, and the points where a step is the release manager's to take
rather than yours. release-runbook.md holds that last part.
Core principle: a phase is finished when its gate is verifiable by someone other than you. "I ran the command" is not a gate; "the URL resolves" is.
Corrections go to the site page. If a release teaches you something the guidelines get wrong,
fix them in a PR to apache/struts-site. Only what is genuinely agent-specific belongs here.
The phases
| # | Phase | Gate before moving on |
|---|---|---|
| 1 | Prepare | Branch green, version decided, parent poms released |
| 2 | Cut | Tag pushed, artifacts in a closed Nexus staging repo |
| 3 | Stage | Assemblies in dist/dev, Version Notes page live, [TEST] mail sent |
| 4 | Vote | 72 h elapsed, three binding +1, result mail sent |
| 5 | Promote | Nexus repo released, dist/dev → dist/release, 24 h rsync waited |
| 6 | Publish | Site PR merged, GitHub release un-flagged, [ANN] mail delivered |
| 7 | Advisories | On a Monday–Thursday: bulletins public, CVE records READY, advisory mails sent from the CVE tool; then Version Notes Security section, site PR, reporter notices, threat-model check |
Phase 7 only exists when the release carries a security fix, and publishing the advisory is strictly after phase 6 — see Security work is a separate clock below. Writing the bulletin is not: it is usually drafted long before the release exists, and often on its own timetable entirely.
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 21d ago Changed · +4 lines 650652187174
- 1mo ago First seen · 154 lines · 59 tokens per session scan A f0bd7c69a964
releasing-struts is a skill published in the GitHub repository apache/struts (1,371 stars, last pushed 2d ago), licensed Apache-2.0. It adds 59 tokens to every session and 2,163 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
release-plugin
Prepare and execute a new release for the flutter-intellij plugin, including updating dependencies, compatibility bounds, changelogs, and verification.
update-site-for-release
Update/publish the Apache Tika website (tika-site SVN repo) for a release — step 17 of the Release Process. Handles the 4.x track (Changes page + aggregate javadoc + Antora docs branch) vs the 3.x maintenance track (full per-version apt docs + javadoc). Use for "update the site", "publish the site for X.Y.Z", "the…
changelog-generator
Generate changelogs from git commits. Use when user says "generate changelog", "update changelog", "what changed since last release", or before preparing a new release.
zb-release-pipeline
Generate a GitHub Actions pipeline that builds a zb (Zero Dependencies Builder) project and publishes a GitHub Release with the produced JAR. Use whenever the user wants CI/CD, a build pipeline, a release workflow, or GitHub Actions for a zb-based Java project — phrases like "set up GitHub Actions for this zb…
shipping-and-launch
Pre-deploy hygiene for a Spring Boot 4 feature — verify gates, capture rollback plan, sign off observability, generate release notes, and stage the rollout. Used by /ship after /review approves the diff. The agent never deploys; it produces the plan a human executes.
changelog-release-notes
A BK-CI release-notes workflow for processing newly added version sections in a changelog. A changelog is a file that records software changes between releases.