Résumé marketing de la dotcom release

Résumer ce qui sort dans la release dotcom de cette semaine (les commits sur main qui ne sont pas encore sur production) pour l'équipe marketing, et le poster sur leur canal Discord.

C'est l'équivalent marketing de [[dotcom-release-crew]]. Même plage de commits, audience différente : le message release-crew nomme les ingénieurs à avoir à disposition ; celui-ci dit aux non-techniciens ce que les utilisateurs remarqueront pour qu'ils puissent planifier les annonces, posts réseaux et textes changelog. Pas de mentions d'ingénieurs, pas de framing risque release — juste des descriptions claires et humaines de ce qui est nouveau.

Entrées

DISCORD_MARKETING_WEBHOOK_URL — variable d'environnement contenant le webhook Discord qui poste sur le canal marketing. Obligatoire. S'il n'est pas défini, arrête-toi et demande à l'utilisateur de le configurer (ne hardcode pas une URL webhook — ce repo est public).
GH_TOKEN — utilisé par gh. Présent automatiquement en CI ; en local, assure-toi que gh auth status fonctionne.

Workflow

1. Récupérer la plage de commits

Récupère tous les commits sur main qui ne sont pas sur production, avec l'auteur et la première ligne du message. --paginate gère les plages supérieures à 250 commits.

gh api repos/tldraw/tldraw/compare/production...main --paginate \
  --jq '.commits[] | [ (.author.login // .commit.author.name), (.commit.message | split("\n")[0]) ] | @tsv'

Chaque ligne est : login\tsubject. tldraw fait des squash-merge des PRs, donc le subject est le titre de la PR (généralement un conventional commit comme feat(tldraw): ... avec un (#1234) à la fin).

Capture aussi l'URL diff lisible en référence : https://github.com/tldraw/tldraw/compare/production...main.

S'il y a zéro commits, poste une courte note indiquant qu'il n'y a rien de nouveau qui sort cette semaine et arrête-toi.

2. Sélectionner ce qui vaut la peine de dire au marketing

Lis les premières lignes de commit et garde seulement les changements qu'un utilisateur pourrait remarquer ou dont le marketing voudrait parler. C'est un filtre différent de la skill release-crew : tu te soucies de la visibilité pour les utilisateurs, pas du risque release.

À inclure (jugement, pas seulement le préfixe) :

feat — nouvelles fonctionnalités et capacités, surtout tout ce qui est visible pour l'utilisateur dans tldraw, editor, dotcom, ou sync/collaboration.
fix — corrections de choses que les utilisateurs auraient vues ou dont ils se seraient plaints (bugs visibles, interactions cassées, problèmes export/embed/rendering, glitches sync).
perf — améliorations de performance que les utilisateurs ressentiront (chargement plus rapide, canvas plus fluide).
Tout ce qui concerne la collaboration, le partage, les exports, les embeds, ou l'apparence générale et l'ergonomie.

À exclure :

docs, test, chore, style, ci, build, bumps de dépendances, et refactors internes sans effet visible pour l'utilisateur.
fix purement internes (typos, lint, tests instables, snapshots, erreurs type, outillage dev-only).
Tout ce qu'un non-ingénieur ne pourrait pas observer ou dont il ne se soucierait.

Garde la liste courte et à fort signal — une poignée de points clés, pas un changelog exhaustif. C'est normal d'avoir beaucoup de commits qui ne passent pas le filtre.

3. Traduire en langage courant

Pour chaque changement gardé, réécris le subject conventional-commit en une courte phrase humaine décrivant ce que cela fait pour les utilisateurs, pas comment c'est construit. Supprime le préfixe type(scope): et le (#1234) à la fin.

Exemples :

feat(tldraw): flip geo shapes with flipX/flipY like the image shape → "Vous pouvez désormais retourner les formes horizontalement et verticalement, comme les images."
fix(tldraw): size Vimeo embeds to their real aspect ratio → "Les embeds Vimeo affichent désormais le bon ratio d'aspect au lieu d'être croppées ou letterboxed."
perf(editor): faster hit-testing on dense canvases → "Le canvas reste fluide quand vous avez beaucoup de formes."

Groupe les points clés en quelques catégories quand ça aide à la lisibilité :

✨ Nouveau — nouvelles fonctionnalités et capacités.
💅 Amélioré — raffinements, polish, performance.
🐛 Corrigé — bugs notables éliminés.

Si une section serait vide, omets-la.

4. Composer le message

Garde-le sous 2000 caractères (limite Discord). Majuscule de phrase, amical et concret, pas de jargon. Ne mentionne ou ne ping pas les ingénieurs — c'est un résumé tourné vers le marketing. C'est bon de noter si c'est une semaine calme.

Format :

📣 **Shipping to tldraw.com this week**

✨ **Nouveau**
• Vous pouvez désormais retourner les formes horizontalement et verticalement, comme les images.

💅 **Amélioré**
• Les embeds Vimeo affichent désormais le bon ratio d'aspect.
• Le canvas reste fluide sur les tableaux avec beaucoup de formes.

🐛 **Corrigé**
• Fixed asset associations churning on bookmarks and external assets.

Full changes: https://github.com/tldraw/tldraw/compare/production...main

S'il n'y a rien de visible pour l'utilisateur qui a été sélectionné mais qu'il y avait des commits, dis-le brièvement (par exemple "Semaine calme pour les changements visibles — surtout du travail dans les coulisses.") et inclus quand même le lien diff.

5. Poster sur Discord

Poste le message comme content du webhook. Construis le JSON de manière sûre (ne fais pas d'interpolation de string du message dans le JSON à la main — utilise jq pour que les retours à la ligne et guillemets soient échappés) :

jq -n --arg content "$MESSAGE" '{content: $content, allowed_mentions: {parse: []}}' \
  | curl -sS -X POST -H "Content-Type: application/json" -d @- "$DISCORD_MARKETING_WEBHOOK_URL"

allowed_mentions.parse: [] s'assure qu'aucune mention @everyone/@here/rôle/utilisateur ne peut jamais partir de ce message — les résumés marketing ne doivent jamais ping personne.

Un post réussi retourne HTTP 204 avec un corps vide. Rapporte à l'utilisateur ce qui a été posté (ou que le post a échoué, avec la sortie curl).

Notes

Ne commite pas et n'affiche pas l'URL webhook complète nulle part.
Cette skill ne lit que l'historique git et poste un message ; elle ne modifie jamais le repo.
production...main suppose le flux hebdomadaire normal où la dotcom release est la promotion main → production, donc cette plage est exactement ce qui va sortir. Durant les semaines SDK freeze la plage est moins précise — voir la note dans [[dotcom-release-crew]].

dotcom-release-marketing