Menu
Draft release notes from the git log, then bump versions and publish a release
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
HTTP API reference for the /api/* endpoints — generate-image, verify-access-code, verify-key, report, and the admin bearer-session endpoints, plus the CORS, rate-limiting, and auth model. Use before adding, changing, or calling any /api endpoint.
Inventory and evaluate every third-party dependency — who publishes it, its license, stars, release cadence, maintenance health, abandonment risk, and whether to keep or replace it — written to docs/DEPENDENCIES.md. Use when asked to inventory or catalog dependencies, assess dependency health or provenance, review maintenance/abandonment risk, find dependencies worth replacing, or produce an SBOM-style dependency review. It analyzes dependencies but never upgrades them — to apply version updates use dependency-update-audit instead.
Audit package.json dependencies for updates (incl. majors), then upgrade them one at a time — read the migration guide, fix all usage, verify, and commit each on its own
Splotch tech stack, file-by-file source map of web/src/, route table, and the canonical UI element glossary. Use when navigating unfamiliar parts of the codebase, deciding where new code belongs, or needing the proper name of a UI element.
Capacitor native app guide — Android/iOS toolchain setup (macOS + Linux), build/sign/run commands, on-device testing, Chrome remote profiling, and the store release & kids-compliance checklists. Use before touching anything Android, iOS, or Capacitor related.
Capture and read an automated performance profile of the drawing app (web, Android, iOS). Use when measuring drawing/canvas performance, investigating jank or a slow interaction, verifying a perf change, or checking for regressions over time. Covers the `npm run perf:*` harness, how to read report.md/summary.json, and the bottleneck decision guide.
| name | release |
| description | Draft release notes from the git log, then bump versions and publish a release |
You are cutting a new release of Splotch. The committed releases/<version>.md file is the single
source of truth; everything else (in-app About tab, store changelogs, GitHub release, version
numbers) is generated from it by scripts/release.mjs and scripts/generate-releases.mjs. Read
releases/README.md if you need the format.
Optional argument: a target version (e.g. /release 1.2.0). If omitted, you will propose one.
Follow these steps:
Gather commits since the last release.
git describe --tags --abbrev=0 (if it fails, there are no tags yet — use
the full history).git log <last-tag>..HEAD --pretty=format:"%h %s" (or all commits if no
tag).Propose the version number. Look at the current version in package.json and the nature of
the commits, then suggest a semver bump (patch for fixes only, minor for new user-facing
features, major for breaking changes). If the user passed a version as the argument, use that
instead.
Draft the release notes. Write Markdown grouped under the headings the project uses —
## ✨ New, ## 🚀 Improved, ## 🛠 Fixed (omit empty sections). Translate commit subjects into
concise, user-facing language — describe what changed for someone using the app, not the
implementation. Drop purely internal commits (tooling, refactors, test-only, CI) unless they
affect users. Keep it tight: the plain-text version feeds the Google Play "What's new" box, which
has a 500-character limit.
Review with the user. Show the proposed version and the drafted notes. Ask them to approve or edit. Iterate until they are happy. Do not proceed without explicit approval.
Write the release file. Create releases/<version>.md with frontmatter:
---
version: <version>
date: <today's date as YYYY-MM-DD>
---
<approved notes>
Get today's date from the environment (the date is in your context, or run
git log -1 --format=%cd --date=short). Omit androidVersionCode — the script assigns and pins
it.
Confirm the publish step, then run it. Publishing pushes to main, creates the v<version>
tag, and opens a public GitHub Release. Ask the user which they want:
npm run release <version>npm run release <version> -- --no-publishnpm run release <version> -- --dry-runReport the result — the new version, the versionCode that was assigned, and the GitHub
release URL if published. Remind the user that the Play / App Store "What's new" text is ready to
paste from fastlane/metadata/android/en-US/changelogs/<versionCode>.txt and
fastlane/metadata/en-US/release_notes.txt. If they want the .aab attached to the GitHub
release, it must be built first with npm run android:bundle before running the release.
Point to the next step. Once the version is committed and tagged, the store artifacts still
need to be compiled — that's a separate step. Suggest the user run /build next to produce
the signed .aab for this version.