Communitygithub.com

Document de valorisation à partir de l'historique Git

Construisez un document de valorisation ou un brouillon d'auto-évaluation fondé sur vos pull requests et commits fusionnés, en laissant des lacunes visibles là où les résultats sont inconnus. À utiliser pour la saison des revues, les dossiers de promotion ou les mises à jour de CV.

Qu'est-ce que Document de valorisation à partir de l'historique Git ?

Cette compétence transforme l'historique Git d'un développeur, principalement via GitHub CLI, en un document de valorisation (brag document) structuré mais honnête. Elle collecte automatiquement les PR fusionnées et les commits, puis les regroupe par thèmes (fiabilité, nouvelles fonctionnalités, performances, mentorat, etc.) sans inventer de métriques ou d'impact. Pour chaque thème, elle rédige une section « Ce que j'ai fait » et une section « Résultat » qui ne contient une valeur que si une mesure ou une citation a été fournie par l'utilisateur ; sinon, elle insère un marqueur [LACUNE] explicite. La compétence se termine par une liste hiérarchisée des lacunes et trois questions clés à poser pour renforcer le dossier. Elle respecte scrupuleusement les règles d'honnêteté : pas de chiffres inventés, pas de gonflage des contributions, et protection des informations privées. L'utilisateur peut ensuite demander à transformer le brouillon en auto-évaluation, en dossier de promotion ou en points pour CV.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/agentkitco/agentkit-dev-skills/tree/HEAD/skills/brag-doc-from-git

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Que fait Document de valorisation à partir de l'historique Git ?

Objectif : transformer ce que vous avez réellement livré en un brouillon que vous pouvez éditer, sans inventer d'impact. Un document de valorisation liste le travail et les résultats ; cette compétence collecte le travail et marque chaque résultat manquant comme une lacune à combler.

Étape 1 : collecter les preuves

Demandez la fenêtre temporelle (par défaut : les 6 derniers mois) et les dépôts. Ensuite, avec GitHub CLI connecté :

gh search prs --author @me --merged --merged-at ">=AAAA-MM-JJ" --json title,url,closedAt,repository --limit 200

Pour le code qui n'est pas sur GitHub, utilisez git log --author="<nom ou email>" --since="AAAA-MM-JJ" --no-merges --pretty="%h %ad %s" --date=short dans chaque dépôt. Demandez aussi à l'utilisateur de coller tout ce que Git ne peut pas montrer : incidents traités, mentorat, revues effectuées, présentations, documentation, astreintes, décisions de conception, compliments de collègues.

Ne lisez pas les dépôts privés que l'utilisateur n'a pas nommés. Ne devinez pas les noms, les équipes ou les chiffres.

Étape 2 : grouper, ne pas encore résumer

Regroupez les éléments par thèmes (par exemple : fiabilité, nouvelles fonctionnalités, performances, outils, mentorat, travail inter-équipes). Listez chaque élément sous son thème avec date et lien. Fusionnez les doublons (une PR de fonctionnalité et ses correctifs ultérieurs).

Étape 3 : rédiger chaque thème

Pour chaque thème, écrivez :

  • Ce que j'ai fait : une ou deux phrases avec des verbes simples, en utilisant uniquement ce que les titres, les diffs et les notes de l'utilisateur supportent.
  • Résultat : seulement si un nombre, une citation ou un résultat a été fourni. Sinon, écrivez [LACUNE : qu'est-ce qui a changé pour les utilisateurs ou l'équipe ? une métrique avant/après ?].
  • Preuves : liens.
  • Signal de portée (si pris en charge) : a dirigé, a fait seul, a travaillé entre équipes, était d'astreinte, a revu les autres.

Étape 4 : terminer par les lacunes et les questions

Terminez par une liste de chaque [LACUNE], classée par l'impact qu'elle aurait sur le dossier, et les trois questions dont les réponses apporteraient le plus. Proposez de transformer la version finale en auto-évaluation, en plan de dossier de promotion ou en points pour CV.

Règles

  • N'inventez jamais de métriques, pourcentages, noms de clients, titres ou portée. Une lacune visible vaut mieux qu'un chiffre inventé.
  • N'enjolivez pas : « a contribué à » reste « a contribué à ». Faites correspondre les verbes aux preuves.
  • Gardez le crédit de l'utilisateur honnête : si une PR était un effort d'équipe, précisez quelle partie était la sienne.
  • Restez discret sur les détails privés ou confidentiels, sauf si l'utilisateur dit que le document est interne.
  • Produisez du Markdown que l'utilisateur peut coller dans ses notes.

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

Skills associés