Timesheet — récap journalier client-friendly

Arguments

L'utilisateur invoque la commande sous l'une de ces formes :

• /timesheet 2026-04-27 → start = 27/04, end = aujourd'hui, repo = cwd
• /timesheet 2026-04-27 2026-05-01 → start + end explicites, repo = cwd
• /timesheet 2026-04-27 2026-05-01 C:/path/to/repos → start + end + chemin de scan
• /timesheet 2026-04-27 - C:/path/to/repos → start + end auto + chemin (le - = end auto)

Date de début OBLIGATOIRE. Format ISO YYYY-MM-DD.

Étape 1 — Scan des commits

1. Détermine le chemin de scan : argument 3 si fourni, sinon pwd.
2. Walk récursif dans le chemin pour trouver tous les dossiers .git/ (limite la profondeur à 4 niveaux pour éviter de balayer des node_modules ou autres).
3. Pour chaque repo trouvé :
   • Récupère l'email git de l'utilisateur : git -C <repo> config user.email
   • Liste les commits dans la fenêtre :

     git -C <repo> log --since="<start>" --until="<end> 23:59:59" \
       --author="<email>" --pretty=format:"%ad|%h|%s" \
       --date=format:"%Y-%m-%d"

4. Agrège tous les commits, groupe par date.

Étape 1.5 — Compléter avec l'historique Claude (optionnel)

Les commits git ne capturent pas le travail non-commité : exploration de code, refactos intermédiaires, configuration d'outils, debug long, etc. Cette étape propose d'enrichir les données de l'étape 1 avec ce qui s'est passé dans les sessions Claude Code de la fenêtre.

1) Vérifie la dispo du scanner :

Cherche <skill-dir>/lib/scan-claude-history.ps1 (le dossier lib/ à côté de ce SKILL.md). S'il existe, le scanner est dispo. Sinon, saute cette étape entièrement.

2) Lance le scan :

powershell -NoProfile -ExecutionPolicy Bypass `
  -File "<skill-dir>/lib/scan-claude-history.ps1" `
  -Start "<start-date>" -End "<end-date>"

Le script retourne un JSON avec :

• by_day[] — par jour calendaire local : files_edited, files_written, user_prompts_preview (premiers 80 chars), cwds (répertoires de travail), session_count, event_count, span_minutes
• sessions[] — détail par session si besoin

Le script ne retourne que des métadonnées (paths, comptes, aperçus tronqués), jamais le contenu brut des messages — c'est conçu pour la confidentialité.

3) Filtre les chemins meta/internes avant utilisation :

Retire de files_edited / files_written tout ce qui n'est pas du travail client facturable :

• Chemins sous ~/.claude/, %USERPROFILE%\.claude\, ~/.claude.json → config Claude perso
• Fichiers SKILL.md, CLAUDE.md, MEMORY.md, *.md dans des dossiers .claude/
• Hooks (*/hooks/*.ps1, */hooks/*.sh)
• Skills (*/skills/*)
• Tout fichier dans un projet outil/MCP perso (ex. un MCP local que l'utilisateur a créé pour lui-même — pas client-billable)

Garde tout ce qui correspond à un repo client (les chemins qui matchent un des repos détectés à l'étape 1).

4) Demande à l'utilisateur via AskUserQuestion :

Présente d'abord un résumé court : "X sessions Claude détectées sur la fenêtre, Y fichiers client touchés au total." Puis options :

• "Oui, intégrer l'activité Claude" — fusionne avec les commits git pour la reformulation à l'étape 2
• "Non, juste les commits git" — passe à l'étape 2 sans cette donnée

5) Si "Oui" :

• À l'étape 2, le LLM dispose des fichiers client touchés par jour + des aperçus de prompts utilisateur comme signaux supplémentaires pour rédiger les bullets
• Ne jamais exposer un chemin brut au client (src/BillingService/BillingController.cs reste interne ; le bullet dit "côté BillingService")
• Les prompts utilisateur (user_prompts_preview) ne servent qu'à inférer le thème, jamais à les recopier dans le rendu

Edge cases :

• Aucune session sur la fenêtre : signaler "(aucune session Claude trouvée sur la période)", passer à l'étape 2
• Scanner absent : sauter cette étape sans erreur
• Span suspect (span_minutes énorme alors que peu d'events) : c'est juste la fenêtre d'inactivité de la session, ignorer ce chiffre pour le timesheet — on ne reporte pas un temps de travail à partir de là

Étape 2 — Reformulation client-friendly

Pour chaque jour, transforme les messages de commit techniques en bullets compréhensibles par un non-développeur :

Règles :

• Pas de jargon technique brut (refactor, chore, wip) — explique l'intention métier
• Mentionne le service / module quand pertinent (ex. "côté BillingService", "sur le workflow facturation")
• Une bullet = une action ou un thème cohérent (groupe les commits successifs sur le même sujet)
• Verbes au passé ou substantifs ("Correction de…", "Mise en place de…")
• Court (1 ligne par bullet idéalement)

Exemple de transformation :

• Commit : fix: validate min price on patch endpoint → Bullet : Correction de la validation du prix minimum à la modification d'un produit
• Commit : chore: bump packages → Bullet : Mise à jour des dépendances techniques
• Commit : feat: add export pdf → Bullet : Ajout de l'export PDF

Étape 3 — Demander si enrichissement Azure DevOps

Après avoir présenté la première version, utilise impérativement le tool AskUserQuestion (pas une question en texte libre) pour proposer l'enrichissement ADO. Adapte les options selon que la MCP Azure DevOps est dispo dans la session ou non :

Si MCP ADO dispo — options :

• "Oui, récupérer les titres" — appelle la MCP pour chaque work item détecté
• "Non, garder tel quel" — passe à l'étape 4

Si MCP ADO non dispo — options :

• "Coller les titres manuellement" — l'utilisateur fournit les titres des US/Tasks
• "Installer la MCP ADO officielle" — l'utilisateur installe une MCP uniquement depuis une source officielle (Microsoft / Anthropic / registre MCP officiel). Ne jamais suggérer de paquets npm tiers ou de repos GitHub communautaires. Si aucune MCP officielle n'existe, le dire et ne pas proposer cette option.
• "Sauter cette étape" — passe à l'étape 4

Détecte au préalable les références ADO dans les messages de commit : patterns #1234, AB#1234, US 1234, Task 1234, PR <num>, etc., et liste-les dans le texte qui précède la question pour que l'utilisateur sache de quoi on parle.

Si l'utilisateur fournit les titres (manuellement ou via MCP), régénère les bullets en intégrant le contexte business des work items.

Étape 4 — Demander si intégration Outlook / M365

Après l'éventuel enrichissement ADO, utilise impérativement le tool AskUserQuestion (pas une question en texte libre) pour proposer l'intégration des réunions.

Détection préalable — avant d'afficher la question, vérifie si une MCP de listing de calendrier M365 est dispo dans la session. Détecte par capacité (un tool qui prend une fenêtre de dates et retourne des réunions), pas par nom de serveur. Indices typiques : tool dont le nom contient list_meetings / list_events / calendar, accepte start_date + end_date, retourne des objets { subject, start, end, duration_minutes, ... }.

Si une MCP calendrier M365 est dispo — options :

• "Oui, récupérer via la MCP calendrier" (recommandé) — appelle le tool de listing avec {start_date, end_date} sur la fenêtre demandée. Garde les filtres par défaut du tool (declined / all-day / annulées sont normalement déjà exclus). Si le tool propose un mode strict "accepted_only" ou équivalent, ne pas l'activer : sur les occurrences récurrentes, les clients Outlook retournent souvent un statut "NotResponded" à tort, ce qui masquerait les dailies/standups.
• "Coller les réunions manuellement" — fallback
• "Fournir un fichier .ics" — autre fallback
• "Sauter cette étape" — finalise le récap

Si aucune MCP calendrier M365 n'est dispo — options :

• "Coller les réunions manuellement" — l'utilisateur fournit titre + jour + durée
• "Fournir un fichier .ics" — l'utilisateur exporte son calendrier et donne le chemin
• "Installer une MCP calendrier M365" — pointer vers une MCP officielle (Microsoft / Anthropic / registre MCP officiel) si elle existe, sinon suggérer à l'utilisateur de créer sa propre MCP locale exposant list_meetings(start_date, end_date). Ne jamais proposer de MCP tierce (npm communautaire, repo GitHub non-vendor). À ce jour, aucune MCP officielle Microsoft ne couvre le calendrier personnel — la Microsoft MCP Server for Enterprise ne couvre que des scopes admin/tenant.
• "Sauter cette étape" — finalise le récap

Traitement des réunions retenues :

• Une bullet par réunion sous la bonne date : Réunion : <titre> (<durée formatée>) ou Point équipe — <titre>
• Formate la durée à partir de duration_minutes (ou équivalent retourné) : 30min, 1h, 1h30, 2h
• Si plusieurs occurrences d'une même série récurrente sur la fenêtre, regroupe-les si pertinent (ex. "Daily — 5 occurrences cette semaine") ou liste-les jour par jour selon le contexte
• Ne mentionne pas les détails sensibles (participants externes, contenu) sauf si demandé
• Le champ organizer peut servir à enrichir le contexte ("Réunion organisée par X") mais reste optionnel

Format de sortie final

## Semaine du <date-debut> au <date-fin>

### Lundi <date>
- <bullet 1>
- <bullet 2>
- Réunion : <titre> (1h)

### Mardi <date>
- ...

• Pas de jour si aucune activité (pas de "Vendredi : RAS")
• Bullets dans l'ordre logique : travail produit d'abord, réunions ensuite

Edge cases à gérer

• Aucun commit trouvé : prévenir l'utilisateur, demander si l'email git est correct (git config user.email), suggérer git log --all pour debug.
• Repos avec emails différents : agréger quand même, lister les emails détectés à la fin pour info.
• Commits avec Co-Authored-By Claude : ignorer la mention Claude dans le bullet.
• Date début > date fin : erreur claire.
• Date début dans le futur : erreur claire.