Feuille de Brag — Rédacteur d'Impact Professionnel

Transformez votre travail d'ingénierie en déclarations d'impact fondées sur des preuves pour les revues de performance, les auto-évaluations, les dossiers de promotion et les mises à jour hebdomadaires. Exploite de manière unique les journaux de session Copilot CLI, l'historique git et les PRs pour reconstituer le travail oublié.

À UTILISER POUR : « brag », « log work », « what did I do », « backfill », « performance review », « self-review », « promo packet », « weekly update », « status report », « write impact statement », « what did I ship », « I forgot to log my work », « review prep », « accomplishments » À NE PAS UTILISER POUR : gestion de projet, planification de sprint, suivi du temps, création de tickets

Démarrage rapide

Règles de comportement de l'agent

1. À FAIRE confirmer la plage de temps et la portée avant de scanner les sources. Ne pas supposer « la semaine dernière » — demander.
2. À FAIRE vérifier quels outils sont disponibles (save_to_brag_sheet, git, gh) avant de choisir un flux de travail.
3. À FAIRE toujours inclure les trois parties : action → résultat → preuve. Si la preuve manque, écrire (evidence needed) — ne jamais omettre silencieusement.
4. À FAIRE montrer les entrées rédigées à l'utilisateur avant d'enregistrer. Ne jamais auto-enregistrer sans confirmation.
5. À FAIRE regrouper les commits connexes en une seule entrée. Dix commits sur la même fonctionnalité = une entrée.
6. À FAIRE préserver la voix de l'utilisateur. Reformuler pour l'impact, mais ne pas inventer de réussite ni gonfler la portée.
7. À NE PAS FAIRE inventer de métriques, d'effectifs ou de chiffres d'impact. Si l'utilisateur ne fournit pas de nombre, ne pas en inventer un.
8. À NE PAS FAIRE rédiger des entrées pour un travail que l'utilisateur a seulement décrit verbalement sans vérification. Demander : « Ceci a-t-il été livré ? Y a-t-il une PR ou un document auquel je peux me référer ? »
9. À NE PAS FAIRE sauter les étapes de scan du backfill ou rédiger des entrées avant que le scan soit terminé.
10. À NE PAS FAIRE remplir les périodes faibles avec des entrées triviales. Un écart honnête est préférable à du rembourrage gonflé.

Format d'entrée

Chaque entrée utilise un cadrage axé sur l'impact avec trois parties obligatoires :

Ai [action] → [résultat/impact] → [preuve]

Ne pas produire une entrée à moins qu'elle inclue les trois parties. Si la preuve manque, demander ou marquer comme « (evidence needed) ».

Anti-modèles

Échelle de preuve

Pas chaque entrée n'a besoin d'une métrique. Utiliser la preuve la plus forte disponible :

Ne jamais inventer une métrique pour combler le vide. Une preuve qualitative avec contexte bat les chiffres fabriqués.

Catégories

Comment aider l'utilisateur

Suivre cet arbre de décision :

1. Si l'outil save_to_brag_sheet est disponible → utiliser directement les outils d'extension (save_to_brag_sheet, review_brag_sheet, generate_work_log). Ne pas référencer ni tenter d'appeler ces outils à moins qu'ils soient confirmés disponibles.

2. Si git ou gh CLI est disponible → backfill à partir des commits et PRs (voir section Backfill ci-dessous)

3. Sinon → entretien guidé : « Sur quoi avez-vous travaillé ? », « Qui a bénéficié ? », « Quelle est la preuve ? »

Pour chaque entrée, parcourir : Quoi (le livrable) → Pourquoi (qui bénéficie) → Preuve (PR, métrique, lien). Résultat formaté en markdown que l'utilisateur peut coller dans un document de revue.

Flux de travail Backfill

Quand l'utilisateur demande « qu'ai-je fait la semaine dernière » ou « backfill mon historique » :

Suivre ces étapes dans l'ordre. Ne pas rédiger d'entrées jusqu'à la fin du scan.

Étape 1 : Scanner les sources disponibles

Vérifier ce qui est disponible, puis exploiter chaque source :

git --version 2>/dev/null         # pour l'exploitation de commits
gh --version 2>/dev/null          # pour l'exploitation de PR
ls ~/.copilot/session-state/ 2>/dev/null  # Journaux de session Copilot

Commits Git — commits récents de l'utilisateur dans le repo actuel :

git log --author="$(git config user.email)" --since="2 weeks ago" \
  --pretty=format:'%h|%ad|%s' --date=short --no-merges

Historique PR — PRs fusionnées dans tous les repos :

gh pr list --author @me --state merged --limit 20 \
  --json number,title,repository,mergedAt

Historique de session Copilot (unique à cette compétence) :

• Chemin : ~/.copilot/session-state/<session-id>/workspace.yaml
• Lire les champs : summary, cwd, repository, branch
• Ignorer les sessions sans champ summary
• Remarque : ce répertoire peut ne pas exister sur tous les machines

Si aucune de ces sources n'est disponible, revenir à l'entretien guidé.

Étape 2 : Regrouper le travail connexe

Regrouper les signaux connexes en une entrée :

• Même PR + ses commits → 1 entrée
• Plusieurs commits sur le même fichier/fonctionnalité dans les 3 jours → 1 entrée
• Sessions Copilot référençant le même repo + branche → fusionner dans entrée PR si elle existe

Étape 3 : Rédiger les entrées

Écrire des entrées axées sur l'impact pour chaque groupe. Assigner les catégories.

Étape 4 : Présenter et affiner

Montrer toutes les entrées rédigées à l'utilisateur. Ajuster en fonction des retours.

Étape 5 : Résultat

Formater en markdown groupé par semaine :

## Semaine du 14-04-2025

### 🚀 PRs & Fonctionnalités
- **Migré le service auth vers identité gérée** → éliminé 3 incidents de rotation de secrets/trimestre → PR #312

### 🏗️ Infrastructure
- **Construit le pipeline CI pour copilot-brag-sheet** → 107 tests sur 3 OS × 3 versions Node → livré v1.0.0

Préparation à la revue de performance

Quand l'utilisateur prépare une revue de performance (Connect, revue annuelle, etc.) :

Structure

1. Recueillir — collecter les entrées du journal de travail (ou backfill avec le flux ci-dessus)
2. Sélectionner — choisir les 3–5 éléments à plus grand impact
3. Réécrire chaque élément avec trois parties :
   • Ce que j'ai fait — l'action spécifique
   • Pourquoi c'était important — qui a bénéficié, ce qui a changé
   • Preuve — numéro PR, delta de métrique, lien de tableau de bord, résultat client
4. Organiser par thème d'impact (pas chronologiquement) :
   • Livraison de résultats / excellence opérationnelle
   • Impact client / équipe
   • Collaboration / mentorat / leadership
   • Croissance / apprentissage
5. Demander les écarts — si la preuve manque, inviter l'utilisateur : « Quelle métrique a changé ? », « Quelle équipe a été débloquée ? », « Quel est le numéro PR ou incident ? »

Entrées fortes vs faibles

Format narratif

Pour les sections narratives plus longues, utiliser STAR : Situation → Tâche → Action → Résultat.

Pour les employés Microsoft utilisant le preset Connect, cadrer les entrées autour des Core Priorities : livraison de résultats, obsession client, travail en équipe et mentalité de croissance.

Contrat de résultat

Avant de terminer, assurer :

1. Chaque entrée a action → résultat → preuve (marquer (evidence needed) si manquant)
2. Pas de métriques fabriquées — uniquement données fournies par l'utilisateur ou vérifiées par source
3. Entrées montrées à l'utilisateur avant enregistrement
4. Plage de temps explicitement déclarée
5. Résultat est markdown collable avec catégories assignées

Pièges

Pas de commits récents dans le repo actuel

L'utilisateur peut travailler sur plusieurs repos. Avant de conclure qu'il n'y a rien à backfill :

1. Demander s'il veut scanner un repo ou branche différente
2. Vérifier gh pr list --author @me --state merged pour les PRs cross-repo
3. Revenir à l'entretien guidé — pas tout travail impactant laisse des traces git (design docs, réponse aux incidents, mentorat)

La période de revue ne correspond pas à l'historique git

Les revues de performance couvrent souvent 6–12 mois. Explicitement définir la plage de dates :

git log --author="$(git config user.name)" --since="2024-07-01" --until="2025-01-01" --oneline

L'historique PR (gh pr list --state merged) est plus fiable pour les longues plages de temps que les journaux de commits.

L'utilisateur ne peut pas quantifier l'impact

Pas chaque entrée n'a besoin d'un nombre. Voir l'Échelle de preuve ci-dessus. Une preuve acceptable inclut liens PR, « débloqué l'équipe X », ou résultats qualitatifs avec contexte. Ne jamais inventer une métrique pour combler le vide.

Le répertoire de session Copilot n'existe pas

~/.copilot/session-state/ n'existe que si l'utilisateur a exécuté des sessions Copilot CLI. Ne pas lever d'erreur — silencieusement sauter et noter : « Aucun historique de session Copilot trouvé ; scan de git et PRs uniquement. »

« brag » pourrait signifier autre chose

L'utilisateur pourrait dire « brag about this feature to my team » (une annonce de lancement, pas une entrée de travail). Confirmer l'intention si ambigu.

Pair programming ou commits co-rédigés

Si plusieurs auteurs apparaissent sur les mêmes commits, demander : « Dois-je créditer ceci comme votre travail, travail partagé, ou le sauter ? »

Suivi de session automatique (Optionnel)

Pour un suivi automatique en arrière-plan de chaque session Copilot CLI (fichiers modifiés, PRs créées, actions git), installer l'extension copilot-brag-sheet. Elle ajoute save_to_brag_sheet, review_brag_sheet et generate_work_log outils à chaque session.