daily-meeting-update

Présentation de la compétence daily-meeting-update

La compétence daily-meeting-update est un workflow de préparation de réunion conçu pour transformer une activité brute en compte-rendu de standup exploitable. Elle s’adresse aux développeurs qui ont besoin d’une méthode rapide et structurée pour répondre aux vraies questions du daily meeting : qu’est-ce qui a changé hier, qu’est-ce qui vient ensuite aujourd’hui, qu’est-ce qui bloque, et quels sujets méritent d’être discutés en direct.

Ce que daily-meeting-update fait réellement

Contrairement à un simple prompt générique du type « écris mon standup », daily-meeting-update essaie d’abord de récupérer des éléments concrets à partir des outils que vous utilisez peut-être déjà, mène ensuite un court entretien, puis met le résultat en forme en Markdown. Sa vraie valeur ne tient pas seulement au résumé : il fait le lien entre les données d’activité et le contexte humain.

Utilisateurs pour lesquels c’est le plus pertinent

Cette daily-meeting-update skill convient particulièrement aux personnes qui :

• travaillent à partir de GitHub, Git, Jira ou des sessions Claude Code
• veulent un workflow de standup reproductible au lieu d’improviser chaque matin
• ont besoin d’une mise à jour soignée tout en gardant la main sur ce qui est inclus
• oublient souvent les sujets à discuter ou les blocages si on ne les relance pas

Le vrai besoin auquel elle répond

La plupart des utilisateurs n’ont pas besoin d’« écriture IA ». Ils ont surtout besoin d’aide pour reconstituer fidèlement la veille, repérer ce qui compte, et l’emballer dans une mise à jour courte qu’ils peuvent coller dans un chat ou dire à voix haute en réunion. daily-meeting-update for Meeting Prep est particulièrement efficace quand votre travail est réparti entre commits, PR, tickets et sessions de code.

Principaux différenciateurs face à un prompt simple

La différence principale tient à la discipline du workflow :

• vérifie si les intégrations sont disponibles au lieu de partir du principe qu’elles le sont
• récupère du contexte avant de poser des questions
• suit un entretien fixe en 4 parties
• combine le travail détectable automatiquement avec les nuances fournies par l’utilisateur

Le résultat est donc plus fiable qu’un prompt « à l’aveugle » basé uniquement sur la mémoire.

Quand cette compétence est un mauvais choix

Évitez daily-meeting-update si :

• vous ne voulez aucune étape d’entretien
• votre travail se passe surtout en dehors des outils de dev et reste difficile à prouver via Git/Jira/l’historique
• vous n’avez besoin que d’un statut d’une seule ligne
• vous cherchez un reporting d’équipe plutôt qu’une mise à jour quotidienne personnelle

Comment utiliser la compétence daily-meeting-update

Contexte d’installation pour daily-meeting-update

Le dépôt source est softaworks/agent-toolkit, dans skills/daily-meeting-update. Si votre environnement prend en charge les skills hébergées sur GitHub, un chemin d’installation courant est :

npx skills add softaworks/agent-toolkit --skill daily-meeting-update

Si votre plateforme d’agent utilise un autre mécanisme d’import, ajoutez la compétence depuis le chemin du dépôt puis relisez les fichiers source avant de vous y fier pour une vraie réunion en direct.

Commencez par lire ces fichiers

Pour un daily-meeting-update guide rapide, commencez par :

1. skills/daily-meeting-update/SKILL.md — le workflow réel et le comportement de déclenchement
2. skills/daily-meeting-update/README.md — explication plus claire des intégrations et des exemples
3. skills/daily-meeting-update/scripts/claude_digest.py — montre comment l’historique des sessions Claude Code est détecté et résumé

Cet ordre de lecture compte, car le script montre concrètement ce que signifie « l’intégration de l’historique ».

Comment se déroule le workflow daily-meeting-update

La compétence fonctionne en trois phases :

1. Détecter et proposer les intégrations
   • historique Claude Code
   • GitHub CLI
   • contexte du dépôt Git
   • Jira CLI
2. Entretien
   • hier
   • aujourd’hui
   • blocages
   • sujets de discussion
3. Générer la mise à jour
   • combine l’activité récupérée avec vos réponses
   • formate une mise à jour de standup partageable en Markdown

Le détail opérationnel important : elle est conçue pour récupérer les données avant l’entretien afin que les questions puissent être précises.

Quelles informations la compétence attend de vous

L’daily-meeting-update usage donne de meilleurs résultats si vous fournissez :

• la date de la réunion ou une fenêtre temporelle relative si « hier » est ambigu
• le dépôt ou projet sur lequel vous voulez vous concentrer
• une confirmation sur l’usage ou non des sources GitHub/Jira/historique
• tout travail hors outils qui n’apparaîtra pas dans les commits ou les tickets
• des contraintes de destinataire, comme « standup oral », « message Slack » ou « bref statut pour le manager »

Sans ce contexte, le résultat peut être techniquement exact mais incomplet.

Formulations de déclenchement adaptées à la compétence

Cette compétence est censée s’activer sur des demandes du type :

• « aide-moi avec mon daily »
• « prépare ma mise à jour de standup »
• « génère une mise à jour scrum »
• « c’est quoi mon statut pour la réunion d’aujourd’hui ? »

Si vous voulez le meilleur résultat, formulez une demande plus précise que la simple phrase de déclenchement.

Transformer une demande vague en prompt solide

Faible :

Help me with my daily.

Mieux :

Prepare my daily standup update for today. Use GitHub and Claude Code history if available, focus on repo my-app, keep it under 6 bullets, and make blockers explicit.

Idéal :

Prepare my daily standup update for today. Pull GitHub activity and Claude Code history if available, but ask before using Jira. Focus on work from yesterday in my-app and api-service. I need a Markdown version for Slack plus a shorter spoken version. Include: what I finished, what I’m doing next, blockers, and any topic I should raise with the team.

Un prompt plus solide améliore la sélection des sources, le format de sortie et l’adéquation au contexte de la réunion.

Comment obtenir une sortie plus riche grâce aux sources

L’daily-meeting-update install ne vous apporte que le workflow ; la qualité dépend des sources réellement accessibles. Avant usage, vérifiez que :

• gh auth status fonctionne si vous voulez le contexte GitHub
• votre dépôt est un dépôt git valide si vous attendez des signaux git locaux
• Jira CLI est configuré si vous voulez le contexte des tickets
• l’historique Claude Code existe dans ~/.claude/projects si vous voulez des synthèses de session

La compétence évite explicitement de supposer que les outils sont configurés, ce qui améliore la fiabilité, mais implique aussi de s’attendre à des vérifications de permissions et de disponibilité.

Ce qu’apporte le script d’historique Claude Code

scripts/claude_digest.py extrait une synthèse des sessions Claude Code, avec des champs comme :

• titre de session
• chemin du projet
• branche
• fichiers modifiés
• nombre de commandes
• date/nombre de sessions

C’est utile quand votre « travail réalisé » se reconstitue plus facilement à partir des sessions de code qu’à partir des seules PR fusionnées. Cela aide aussi à se rappeler d’un travail partiellement terminé qui n’est pas encore visible dans GitHub.

Workflow recommandé pour un usage quotidien

Un schéma pratique d’daily-meeting-update usage :

1. Lancez-le avant votre standup, pas pendant.
2. Autorisez les intégrations disponibles.
3. Passez en revue l’activité récupérée et ne gardez que les éléments pertinents.
4. Répondez aux 4 questions de l’entretien avec le contexte manquant.
5. Demandez une reformulation plus concise si la première version est trop verbeuse.
6. Conservez la sortie Markdown pour Slack ou pour vos notes.

Cela évite que l’outil ne devienne un simple déversement passif d’activité.

Formats de sortie à demander explicitement

La compétence génère du Markdown, mais vous devriez quand même préciser le style attendu :

• liste à puces pour un chat de standup
• script oral pour une restitution verbale
• statut orienté manager avec moins de détails d’implémentation
• version très concise pour le daily sync, version plus longue pour une mise à jour asynchrone

Les demandes de format changent concrètement l’utilité du résultat, donc mieux vaut les préciser dès le départ.

FAQ sur la compétence daily-meeting-update

daily-meeting-update est-il meilleur qu’un prompt de standup classique ?

En général oui, si votre travail laisse des traces dans GitHub, Git, Jira ou l’historique Claude Code. Un prompt classique dépend de la mémoire. daily-meeting-update essaie d’abord de reconstituer le contexte, puis pose des questions ciblées, ce qui réduit les oublis et les mises à jour vagues.

Dois-je configurer toutes les intégrations ?

Non. La compétence est conçue pour vérifier ce qui est disponible et demander avant d’utiliser quoi que ce soit. Vous pouvez tout de même utiliser daily-meeting-update comme simple workflow d’entretien, mais sa valeur diminue lorsqu’aucun contexte externe ne vient ancrer le résumé.

Est-ce adapté aux débutants ?

Oui, avec une réserve : les débutants peuvent avoir besoin d’aide pour comprendre quelles intégrations sont réellement disponibles dans leur environnement. L’entretien lui-même est simple, mais la qualité de la configuration détermine en grande partie ce que la compétence peut préremplir.

Quelle est sa plus grande limite ?

La compétence ne sait pas magiquement quelle activité compte sur le plan politique ou stratégique. Elle peut faire remonter des preuves de travail, mais c’est encore à vous de décider :

• ce qu’il faut mettre en avant
• ce qu’il vaut mieux ne pas mentionner
• comment présenter un travail inachevé
• quels blocages méritent une escalade

Quand ne faut-il pas utiliser daily-meeting-update ?

Ne l’utilisez pas si :

• votre mise à jour doit rester entièrement manuelle et privée
• votre format de réunion est très spécifique et ne suit pas vraiment le schéma hier/aujourd’hui/blocages/sujets
• vous avez besoin d’une vue consolidée d’équipe sur plusieurs personnes plutôt que de votre propre statut
• votre journée a surtout consisté en planification, communication ou travail de conception non visibles dans les outils connectés

Comment améliorer la compétence daily-meeting-update

Définissez mieux le périmètre dès le départ

La façon la plus rapide d’améliorer les résultats de daily-meeting-update est de restreindre le périmètre :

• quel dépôt
• quel projet
• quelle plage de dates
• quelles intégrations utiliser
• à quel public la mise à jour s’adresse

Si vous ne définissez pas ce périmètre, la compétence risque de récupérer un contexte correct mais bruité.

Dites-lui explicitement quoi exclure

Un mode d’échec fréquent est la surreprésentation d’activités à faible valeur. Pour l’éviter, dites par exemple :

• « exclude routine review comments »
• « focus on merged work and meaningful progress »
• « don’t list exploratory branches unless they affect today »
• « omit internal troubleshooting details from the Slack version »

Vous obtiendrez ainsi une mise à jour qui ressemble davantage à un vrai standup humain qu’à un journal d’activité.

Ajoutez la couche humaine qui manque

Les données d’outils capturent rarement :

• pourquoi quelque chose a pris plus de temps
• quel compromis vous avez fait
• quelle décision est en attente
• ce dont vous avez besoin de la part de vos coéquipiers

Une fois le contexte auto-détecté affiché, ajoutez ces éléments pendant l’entretien. C’est là que la daily-meeting-update skill devient vraiment utile au lieu de se contenter d’automatiser du reporting.

Utilisez un affinage en deux passes

Un bon schéma :

1. Première passe : générer un standup Markdown complet.
2. Deuxième passe : demander une version plus resserrée, adaptée à la réunion.

Exemple de suivi :

Shorten this to 4 bullets, keep one blocker, and make the discussion topic a final line item.

C’est en général plus efficace que d’essayer d’obtenir une brièveté parfaite dès la première passe.

Corrigez les ambiguïtés après la première version

Si la première sortie mélange travail terminé, travail en cours et travail prévu, demandez explicitement une réécriture avec des libellés plus nets :

• Done yesterday
• Doing today
• Blockers
• Need input on

Cette structure est particulièrement utile quand l’activité GitHub comprend à la fois du travail fusionné et non fusionné.

Renforcez la fiabilité en vérifiant les sources de preuve

Si la mise à jour vous semble incorrecte, inspectez le chemin des sources plutôt que de vous contenter d’éditer le texte :

• vérifiez que gh est authentifié sur le bon compte
• confirmez que vous êtes dans le bon dépôt git
• vérifiez l’accès à Jira CLI
• inspectez le comportement de scripts/claude_digest.py si l’historique de session paraît incomplet

C’est la méthode la plus concrète pour améliorer la qualité de sortie de daily-meeting-update dans la durée.