Équipe de sortie Dotcom

Identifie qui a contribué des corrections critiques ou des fonctionnalités importantes à la sortie dotcom de cette semaine (les commits sur main qui ne sont pas encore sur production) et poste un bref résumé sur le canal Discord #development.

L'objectif est une liste très ciblée de personnes à impliquer dans la sortie — 2–3 personnes au maximum, pas un changelog et pas toute l'équipe d'ingénierie. Dépasse les 3 uniquement lors de semaines exceptionnelles où plus de trois personnes possèdent chacune un changement véritablement critique et risqué pour la sortie.

Entrées

• DISCORD_RELEASE_WEBHOOK_URL — variable d'environnement contenant le webhook Discord qui poste sur #development. Obligatoire. S'il n'est pas défini, arrête-toi et indique à l'utilisateur de le définir (ne hardcode pas une URL de webhook — ce dépôt est public).
• GH_TOKEN — utilisé par gh. Présent automatiquement en CI ; localement, assure-toi que gh auth status fonctionne.

Workflow

1. Récupère la plage de commits

Obtiens tous les commits sur main qui ne sont pas sur production, avec l'auteur et la ligne de sujet. --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.author.name), (.commit.message | split("\n")[0]) ] | @tsv'

Chaque ligne est : login\tdisplay name\tsubject. tldraw fusionne les PRs par squash, donc l'auteur du commit est l'auteur de la PR et le sujet est le titre de la PR (généralement un conventional commit comme feat(editor): ... avec un suffixe (#1234)).

Capture aussi l'URL de diff lisible pour le message : https://github.com/tldraw/tldraw/compare/production...main.

S'il y a zéro commit, poste une brève note indiquant qu'il n'y a pas de changements à sortir cette semaine et arrête-toi.

2. Sélectionne les contributeurs critiques

Lis les lignes de sujet et garde uniquement les commits pour lesquels un responsable de sortie voudrait une personne sur place. Groupe les commits conservés par auteur.

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

• feat — fonctionnalités importantes, en particulier limitées à dotcom, editor, sync, sync-core, store, tlschema, state.
• fix — corrections de cohérence, d'intégrité des données, de sync ou de crash significatives.
• perf — changements de performance affectant les utilisateurs.
• Tout ce qui touche au sync multiplayer, à la persistance/migrations, ou à l'authentification/facturation, même si c'est petit.

À exclure :

• docs, test, chore, style, ci, build, et mises à jour de dépendances (dependabot, « Bump versions », [skip ci]).
• fix triviales (typos, commentaires, lint, pins de tests flaky, mises à jour de snapshots).
• Reverts qui annulent un autre commit dans la même plage.

Puis classe les auteurs selon la criticité et le risque de sortie de leur changement, et garde uniquement les 2–3 meilleurs. En cas de doute sur la criticité d'un changement, penche-toi vers l'exclusion — l'objectif est une liste très courte et de haut signal. C'est tout à fait acceptable de présenter juste 1–2 personnes, et normal d'avoir certains commits conservés mais non listés.

Ne dépasse les 3 personnes que lors de semaines exceptionnelles — par exemple une grande migration plus une correction sync non liée plus un changement d'authentification qui arrivent ensemble, où chacun a véritablement besoin de son propre responsable sur place. Si tu le fais, justifie brièvement les noms supplémentaires avant de les inclure.

3. Compose le message

Reste sous 2000 caractères (limite Discord). Un point par personne ; si quelqu'un a plusieurs changements notables, liste-les sous un seul point. Utilise des noms simples — ne tente pas les mentions Discord @.

Format :

🚀 **dotcom release — personnes à impliquer cette semaine**
Changements critiques sur production...main :

• **Mime Čuvalo** (mimecuvalo) — fix(release): don't cut a new SDK version for docs-only patches
• **Kevin Ingersoll** (frolic) — feat(editor): finer, coarse-pointer-aware hit-testing

N changements critiques de M contributeurs · https://github.com/tldraw/tldraw/compare/production...main

Si aucun changement critique n'a été sélectionné mais qu'il y a eu des commits, dis-le brièvement (p. ex. « Aucun changement critique signalé cette semaine — la sortie semble de routine. ») et inclus toujours le lien de diff.

4. Poste sur Discord

Poste le message comme content du webhook. Construis le JSON en toute sécurité (ne fais pas d'interpolation de chaîne du message dans le JSON à la main — utilise jq pour que les retours à la ligne et les guillemets soient échappés) :

jq -n --arg content "$MESSAGE" '{content: $content}' \
  | curl -sS -X POST -H "Content-Type: application/json" -d @- "$DISCORD_RELEASE_WEBHOOK_URL"

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

Notes

• Ne committe pas et n'affiche pas l'URL complète du webhook nulle part.
• Cette skill ne lit que l'historique git et poste un message ; elle ne modifie jamais le dépôt.
• production...main suppose le flux hebdomadaire normal où la sortie dotcom est la promotion main → production, donc cette plage est exactement ce qui s'apprête à être shipped. Lors de semaines de gel SDK — quand production expédie des hotfixes cherry-picked tandis que main continue d'avancer — la plage est moins précise (elle peut manquer les auteurs de hotfixes production-only et inclure du travail main qui ne sort pas encore). C'est acceptable : les semaines de gel sont all-hands de toute façon, donc une liste d'équipe parfaitement adaptée importe moins alors.