update-version
Updates the Dockerman website versioning, changelog, and release dates based on markdown input.
Install
mkdir -p .claude/skills/update-version && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/5109" && unzip -o skill.zip -d .claude/skills/update-version && rm skill.zipInstalls to .claude/skills/update-version
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Update Dockerman version and changelog. Use when releasing a new version with changelog content in markdown format.Key capabilities
- →Parse semantic versioning from markdown headers
- →Update central configuration files for site constants
- →Propagate release dates across multiple locale files
- →Inject release dates into UI component meta-versions
- →Handle date formatting for multiple languages
How it works
It regex-parses the provided markdown to extract version strings and maps them to pre-defined placeholders across local configuration files.
Inputs & outputs
When to use update-version
- →Bumping project version
- →Adding new release dates
- →Updating changelog files
About this skill
Update Version Skill
Updates the Dockerman website with a new version release.
Single sources of truth:
- Version lives in
apps/landing/src/app/siteConfig.tslatestVersion. All components (Navbar,Hero,SnapshotHero) and thedownloads.tsVERSIONconstant import from it; localehero.eyebrow/hero.metaVersionuse the{{version}}placeholder.- Release date lives in
apps/landing/src/config/downloads.tsRELEASE_DATE(ISO). It flows to the latesthistory[]entry, the Download page hero, and HerometaVersionviaformatDate(downloadsConfig.latest.releaseDate, locale)from@/lib/format+ a{{date}}placeholder.Do not reintroduce hardcoded version or date strings in those files.
The historical / per-release locations (changelog MDX entries, README badges, locale tagline highlight phrases, the
release-x-y-zslug) still need per-release edits, because they describe a specific release rather than "the latest version".
Input Format
User provides changelog content in markdown format:
## vX.Y.Z
### ✨ Features
- 🔔 **Feature Name**: Description of the feature
### 🎨 Improvements
- ⚡ **Improvement Name**: Description
Instructions
1. Extract Version Number and Date
Parse vX.Y.Z from the first ## vX.Y.Z heading. Use today's date as the release date.
Prepare the date in these formats — you'll need them in different files:
| Format | Where used | Example (Apr 26, 2026) |
|---|---|---|
ISO YYYY-MM-DD | downloads.ts RELEASE_DATE (single source) | 2026-04-26 |
en Mon DD, YYYY | en changelog, README badge | Apr 26, 2026 |
zh YYYY 年 M 月 D 日 | zh changelog | 2026 年 4 月 26 日 |
ja YYYY 年 M 月 D 日 | ja changelog | 2026 年 4 月 26 日 |
es D de mes de YYYY | es changelog | 26 de abril de 2026 |
| URL-encoded en | README release-date badge URL | Apr%2026%2C%202026 |
Hero
metaVersionno longer needs a per-locale date string — it interpolates{{date}}, withformatDate()deriving the localized date from the ISORELEASE_DATEautomatically.
2. Update apps/landing/src/app/siteConfig.ts (single source of truth for version)
latestVersion: 'X.Y.Z', // no 'v' prefix
This automatically propagates to:
Navbar.tsxbrand badge (v{siteConfig.latestVersion})Hero.tsxterminal animation line +eyebrow(interpolated via{{version}}) +metaVersion(interpolated via{{version}}and{{date}})SnapshotHero.tsxmetaBuildfielddownloads.tsVERSIONconstant + latesthistory[]entry
Never edit those files for the version literal — they already read siteConfig.latestVersion or {{version}}.
3. Update apps/landing/src/config/downloads.ts
Two edits per release:
- Bump
RELEASE_DATEto the new ISO date. - Prepend a new entry to
history[](keep prior entries):
history: [
{ version: VERSION, date: RELEASE_DATE, summarySlug: 'release-x-y-z' },
// ...previous entries (literal versions/dates — these are historical)
]
The latest history entry uses the VERSION and RELEASE_DATE constants directly. Older entries remain literal.
4. Update Locale Files in packages/shared/src/locales/
Update all four (en.json, zh.json, ja.json, es.json). Two keys per file:
-
hero.eyebrow— keep thev{{version}} —prefix; rewrite the highlight phrases for the new release (translated per locale).Pattern:
"v{{version}} — <highlight 1>, <highlight 2>, <highlight 3>" -
hero.metaVersion— pure template"v{{version}} · {{date}}". Do not edit per release — both placeholders are filled at runtime fromsiteConfig.latestVersionandformatDate(downloadsConfig.latest.releaseDate, locale).
The {{version}} placeholder is filled with siteConfig.latestVersion and {{date}} with the localized release date, so don't write either literal here.
5. Convert Markdown to MDX and Prepend to All Four Changelog Locales
Per-locale changelog files (translate body for zh/ja/es):
apps/landing/src/content/changelog/en/page.mdxapps/landing/src/content/changelog/zh/page.mdxapps/landing/src/content/changelog/ja/page.mdxapps/landing/src/content/changelog/es/page.mdx
Conversion rules
- Wrap with
<ChangelogEntry version="vX.Y.Z" date="<localized date>">…</ChangelogEntry> - Add a short H2 title summarizing the release
- Replace
**text:**patterns with<Bold>text:</Bold> - Preserve emoji prefixes
MDX Template
<ChangelogEntry version="vX.Y.Z" date="<localized date>">
## Short Release Title
Brief description of what this release introduces.
### ✨ Features
- <Bold>Feature Name:</Bold> Description of the feature
### 🔧 Improvements
- <Bold>Improvement Name:</Bold> Description
### 🐛 Bug Fixes
- <Bold>Fix Name:</Bold> Description
</ChangelogEntry>
The version literal does appear in <ChangelogEntry version="vX.Y.Z"> — that's intentional, because each entry is a historical record of a specific release.
6. Update README Files
Update all four READMEs: README.md (en), README.zh-CN.md, README.ja.md, README.es.md.
Update version + release-date badges:
[](https://github.com/dockerman/dockerman/releases/tag/vX.Y.Z)
[](https://github.com/dockerman/dockerman/releases/tag/vX.Y.Z)
URL encoding: spaces → %20, commas → %2C.
7. Update README Features Section
Add new features to the Features section in all four READMEs:
- One brief line per feature, no detailed sub-items
- Add under the appropriate section (Container Management, Image Management, etc.) or create a new section
- Translate for zh/ja/es
File References
| File | Per-release? | What changes |
|---|---|---|
apps/landing/src/app/siteConfig.ts | ✅ | latestVersion (single source of truth — propagates to all UI) |
apps/landing/src/config/downloads.ts | ✅ | RELEASE_DATE + prepend history[] entry (uses VERSION/RELEASE_DATE consts) |
packages/shared/src/locales/{en,zh,ja,es}.json | ✅ | hero.eyebrow only (rewrite tagline highlights). hero.metaVersion is a pure template — don't touch. |
apps/landing/src/content/changelog/{en,zh,ja,es}/page.mdx | ✅ | Prepend new <ChangelogEntry> (×4 locales, body translated) |
README.md / README.zh-CN.md / README.ja.md / README.es.md | ✅ | Version + release-date badges + Features section |
apps/landing/src/components/{shell/Navbar,landing/Hero,snapshot/SnapshotHero}.tsx | ❌ | Already read siteConfig.latestVersion — never touch for a version bump |
Section Types Supported
### ✨ Features— New functionality### 🔧 Improvements/### 🎨 Improvements— Enhancements (both emojis seen historically)### 🐛 Bug Fixes— Issue resolutions### ⚡ Performance— Performance optimizations### 🌐 Internationalization— i18n updates
Optional: Changelog Images
<ChangelogImage
src="/screenshots/X.Y.Z/image.png"
alt="Description"
/>
Verification Checklist
Single source of truth
-
siteConfig.tslatestVersionupdated (withoutvprefix) - No new hardcoded
vX.Y.Zstrings introduced inNavbar.tsx,Hero.tsx,SnapshotHero.tsx, or locale JSON files
downloads.ts
-
RELEASE_DATEupdated (ISO format) - New
history[]entry prepended (usingVERSION/RELEASE_DATEconsts), prior entries kept
Locale files (×4 — en, zh, ja, es)
-
hero.eyebrowhighlights rewritten (translated,v{{version}}placeholder kept) -
hero.metaVersionleft untouched (it's"v{{version}} · {{date}}"— both interpolated)
Changelog MDX (×4 — en, zh, ja, es)
- New
<ChangelogEntry>prepended to each locale (body translated) - Locale-specific date format used
- All
<Bold>and<ChangelogEntry>tags closed
README files (×4 — en, zh-CN, ja, es)
- Version badge updated
- Release-date badge updated (URL-encoded date)
- Features section updated (brief, translated)
Final scan
-
grep "v?<previous-version>"returns only legitimate historical references: changelog entries for that version, "Added in v…" doc lines,downloads.tshistory array, design specs indocs/superpowers/, andbun.lock(unrelated packages). -
grep "v?<new-version>"(literal) outsidesiteConfig.tsand the new changelog/README entries should return nothing — if it does, you reintroduced a hardcoded version somewhere.
When not to use it
- →If the project lacks a centralized version configuration
- →When changing logic instead of metadata
Limitations
- →Requires strict adherance to the changelog markdown format
- →Limited to the project's specific configuration file structure
- →Dates must follow the predefined ISO format requirements
How it compares
It maintains a single source of truth for versioning instead of manually editing every instance.
Compared to similar skills
update-version side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| update-version (this skill) | 1 | 3mo | No flags | Beginner |
| markdown-to-html | 16 | 6mo | Review | Beginner |
| docs-writer-reference | 1 | 6mo | No flags | Beginner |
| deepwiki-rs | 25 | 9mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
markdown-to-html
github
Convert Markdown files to HTML similar to `marked.js`, `pandoc`, `gomarkdown/markdown`, or similar tools; or writing custom script to convert markdown to html and/or working on web template systems like `jekyll/jekyll`, `gohugoio/hugo`, or similar web templating systems that utilize markdown documents, converting them to html. Use when asked to "convert markdown to html", "transform md to html", "render markdown", "generate html from markdown", or when working with .md files and/or web a templating system that converts markdown to HTML output. Supports CLI and Node.js workflows with GFM, CommonMark, and standard Markdown flavors.
docs-writer-reference
reactjs
Reference page structure, templates, and writing patterns for src/content/reference/. For components, see /docs-components. For code examples, see /docs-sandpack.
deepwiki-rs
sopaco
AI-powered Rust documentation generation engine for comprehensive codebase analysis, C4 architecture diagrams, and automated technical documentation. Use when Claude needs to analyze source code, understand software architecture, generate technical specs, or create professional documentation from any programming language.
obsidian
gapmiss
Comprehensive guidelines for Obsidian.md plugin development including all 27 ESLint rules, TypeScript best practices, memory management, API usage (requestUrl vs fetch), UI/UX standards, and submission requirements. Use when working with Obsidian plugins, main.ts files, manifest.json, Plugin class, MarkdownView, TFile, vault operations, or any Obsidian API development.
writing-registry-meta
siriwatknp
Use this skill when writing meta file for MUI Treasury registry.
project-overview
lobehub
Complete project architecture and structure guide. Use when exploring the codebase, understanding project organization, finding files, or needing comprehensive architectural context. Triggers on architecture questions, directory navigation, or project overview needs.