Résumé hebdo SOS captain¶

Workflow pensé pour une automation Cursor (lundi ~14h Europe/Paris). Exécutable aussi à la demande.

Prérequis¶

MCP Slack connecté (OAuth workspace Bricks)
Outils : slack_read_channel, slack_read_thread, slack_send_message, slack_search_public (fallback)

Constantes¶

Ressource	ID
`#support` (lecture + publication du résumé)	`C02JZ3F9ZGD`
`#bug-report` (lecture seule)	`C03LN4FLXHU`
`@sos_captain` (mention en tête de message)	`S05BL6SCWMD` → `<!subteam^S05BL6SCWMD>`

Période couverte¶

Par défaut : fenêtre glissante de 7 jours, alignée sur la rotation SOS (lundi après-midi), fuseau Europe/Paris.

Borne	Règle
Fin	Instant d'exécution (`now`) en Europe/Paris — pas lundi 00:00
Début	`now` − 7 jours (même heure, Europe/Paris) — pas lundi 00:00

Exemple : automation le lundi 2 juin 2026 à 14:00 → période lundi 26 mai 14:00 → lundi 2 juin 14:00. Les messages postés lundi après-midi après la passation de garde appartiennent à la nouvelle semaine SOS (hors fenêtre si l'automation tourne avant la passation).

Planifier l'automation chaque lundi à heure fixe (ex. 14h) pour rester calé sur la rotation.

Période personnalisée¶

Si l'utilisateur précise d'autres dates (« du 26 au 29 mai », « semaine du 19 mai »), calculer explicitement les bornes avant toute lecture Slack :

Cas	Début (`start`)	Fin (`end`)
Dates calendaires sans heure	1er jour à 00:00:00 Europe/Paris	Dernier jour à 23:59:59 Europe/Paris
Date + heure explicites	Heure indiquée (Europe/Paris)	Heure indiquée (Europe/Paris)
« Semaine du X » sans précision	Semaine calendaire : lundi 00:00:00 → dimanche 23:59:59 Europe/Paris (ou `now` si non terminée) — ≠ semaine SOS (voir mode défaut)

En cas d'ambiguïté (fuseau, inclusion du dernier jour, « semaine SOS » vs calendaire), appliquer la règle mode défaut (fenêtre 7 j) ou stopper avec erreur explicite — pas de demande interactive.

Vérifier start ≤ end avant conversion — sinon stopper et signaler l'erreur (pas de récap vide publié).

Conversion timestamps¶

Convertir start / end en Unix timestamps entiers (secondes) uniquement pour les appels API.

Conserver start / end en datetime pleine précision (Europe/Paris) pour la ligne Période du récap — ne pas arrondir l'affichage aux secondes entières.

L'API Slack exclut les messages exactement sur oldest / latest. Pour couvrir les bornes inclusives de la période sur slack_read_channel, ajuster :

oldest = floor(start_unix) - 1
latest = ceil(end_unix) + 1

Pour slack_search_public, after / before sont inclusifs (schéma MCP) — utiliser start_unix / end_unix directement, sans ±1.

Workflow¶

0. Figurer la fenêtre (une seule fois)¶

Avant toute lecture Slack, capturer start et end une fois — ne pas recalculer now entre canaux, threads ou pagination.

Mode	Calcul
Défaut	`end` = instant d'exécution (Europe/Paris) ; `start` = `end` − 7 jours (même heure)
Personnalisé	voir table Période personnalisée

Puis appliquer Conversion timestamps → conserver les mêmes oldest / latest / after / before pour toute l'exécution.

1. Lire les messages parents¶

Pour chaque canal (C02JZ3F9ZGD, C03LN4FLXHU) :

slack_read_channel avec oldest / latest = timestamps ajustés (±1 s, voir Conversion timestamps), limit 100
Paginer avec cursor si has_more / next cursor présent — accumuler toutes les pages avant filtrage (ne pas ne garder que la dernière page)
Ne retenir que les messages racine (pas les réponses isolées dans le flux) dont le timestamp est dans [start, end] (le ±1 s sur oldest/latest élargit la requête API — re-filtrer ensuite sur les bornes figées)
Si slack_read_channel échoue ou la pagination est incomplète sur un canal → stopper, ne pas publier de récap partiel

Ignorer : messages bot sans contenu utile, réactions seules, « je serai votre @sos_captain cette semaine » (info rotation, pas un ticket).

2. Lire les threads pour la résolution¶

Pour chaque message parent pertinent :

slack_read_thread avec channel_id + message_ts du parent (inchangés à chaque page), limit 100
Paginer avec cursor tant que has_more / next cursor présent — accumuler toutes les pages avant de déterminer le statut
Si slack_read_thread échoue ou pagination incomplète → ne pas inférer « Non traité » ; stopper ou signaler l'erreur
Déduire le statut à partir de la dernière réponse tech/SOS chronologique — une réouverture « En cours » prime sur un « Résolu » antérieur
Si un message client/signaleur postérieur au dernier « Résolu » tech indique que le problème persiste (sans réponse tech ultérieure) → En attente ou À suivre, pas « Résolu »

Libellés de statut (un seul par sujet) :

Statut	Quand
Résolu	Fix déployé, action manuelle faite, client débloqué
Résolu (info)	Question répondue, pas de bug / pas d'action prod
Expliqué	Comportement attendu clarifié, pas de changement code
Clarifié	Malentendu levé côté process / outil
En cours	PR ouvert, investigation active, pas de clôture
À suivre	Cause connue mais action restante (hotfix, ticket Linear, etc.)

Si le thread est vide ou sans réponse tech : Non traité ou En attente selon le contexte.

3. Rédiger le résumé¶

Langue : français. Format : liste concise (pas de roman).

Structure obligatoire :

<!subteam^S05BL6SCWMD> — récap de la semaine SOS passée

*Période :* {date/heure début} → {date/heure fin} (Europe/Paris — {libellé fenêtre, ex. « fenêtre 7 j » ou « période personnalisée »})

---

*#support*

*{Jour ou regroupement logique}*
• *{Sujet court}* — *{Statut}* : {1 phrase max sur la résolution}

---

*#bug-report*

• ...

---

*Synthèse :* {2–3 phrases : thèmes dominants, incidents, bugs ouverts}

Règles rédaction :

La première ligne doit mentionner <!subteam^S05BL6SCWMD> (ping @sos_captain)
Un bullet = un fil de discussion (pas chaque message du thread)
Titre en gras Slack (*...*)
Dates des signalements vs cause infra : ne pas confondre (ex. incident TLS : cause jeudi soir, tickets vendredi)
Vérifier le jour de la semaine des dates (éviter « jeudi 29 » si le 29 est un vendredi)
La ligne Période affiche les horodatages réels (avec heure), pas « lun 00:00 → lun 00:00 »

4. Publier dans #support¶

slack_send_message avec channel_id = C02JZ3F9ZGD et le résumé complet (incluant <!subteam^S05BL6SCWMD> en tête)
Si Slack refuse (message trop long) : scinder le contenu en deux messages successifs dans #support (C02JZ3F9ZGD) — 1er message = section #support du récap, 2e = section #bug-report + synthèse. #bug-report est lecture seule, ne jamais y publier
Ne publier qu'après succès de slack_send_message — en cas d'échec API, stopper sans publier de récap partiel

Pièges connus¶

Pagination canal : accumuler toutes les pages de slack_read_channel avant filtrage — une semaine chargée dépasse souvent 100 messages
Pagination thread : idem pour slack_read_thread — assembler toutes les pages avant le statut
Bornes inclusives : ±1 s sur oldest / latest uniquement ; after / before = timestamps bruts (inclusifs)
Threads longs : lire tout le thread pour les sujets chauds (incidents, TLS, login)
Doublons : plusieurs messages sur le même incident → un seul bullet regroupé ; dédupliquer aussi les résultats slack_search_public par message_ts parent
Minuit : ne pas tronquer la fin de fenêtre au lundi 00:00 — utiliser l'heure d'exécution
Recherche complémentaire : si peu de résultats via read_channel, slack_search_public avec in:#support / in:#bug-report + after/before — fusionner avec les parents déjà collectés, sans doublon

Hors scope (won't fix)¶

Comportement volontaire — ne pas étendre le skill sans demande produit explicite :

Broadcast replies (thread_ts) dont le parent est hors fenêtre → le récap couvre les tickets ouverts dans la fenêtre, pas l'activité sur d'anciens fils
Mode passation SOS calendaire (lundi PM → lundi PM) → le défaut reste la fenêtre glissante 7 j depuis now ; l'automation lundi ~14h en est une approximation, pas une règle de conversion

Déclenchement¶

Automation Cursor : agent planifié dont le prompt charge ce skill (ex. « Exécute le skill sos-weekly-summary ») — chaque lundi ~14h Europe/Paris
À la demande : « Fais le résumé support / bug-report de la semaine SOS passée et poste-le dans #support en pingant @sos_captain »