Le ritual de release Rubis demande de bumper `apps/web/src/version.ts`
et d'ajouter `apps/landing/src/content/changelog/<x.y.z>.md` dans le
*même* commit — sinon le toast SPA pointe sur une ancre absente côté
`/changelog`. Ce skill orchestre les deux pour éliminer la classe entière
des releases désynchronisées.
Workflow :
1. `git status` + `git diff` pour inspecter les changements pendants
2. Détection heuristique du type (feature/improvement/fix) → bump
semver correspondant (minor pour feature, patch sinon)
3. AskUserQuestion pour titre + highlights (au ton brand : produit-only,
pas de jargon tech, une phrase d'attitude max)
4. Edit `version.ts` + Write nouveau `.md` avec frontmatter Zod-validé
5. Stage + commit Conventional Commits (scope `release`)
6. Push gitea/main
Edge cases couverts : aucun changement à committer, branche ≠ main,
build cassé pré-existant (ne bloque pas la release, juste flag), conflits
remote, hook pre-commit échoue (jamais d'amend / no-verify), version
déjà utilisée, versionnage incohérent entre `version.ts` et le dossier
changelog.
Trigger : `/push`, "release ça", "sors une nouvelle version", "push avec
changelog", "deploy" (sauf si l'user dit explicitement "sans bump").
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
fc66775109