mark-helme/career-record

Dossier de carrière

Construit un dossier de carrière à partir des preuves de travail réel d'une personne :

• Dossier long : un résumé exécutif, des tuiles d'impact, un graphique des PR par trimestre, des puces CV, des histoires STAR, une frise chronologique trimestrielle, des fiches projet, des compétences, du leadership, de la reconnaissance, des moments de croissance, et une annexe listant chaque PR, ticket Jira et page Confluence.
• Court dossier pour les entretiens de screening : un pitch, des faits clés, une frise chronologique interactive, les plus grandes victoires, des citations et la stack technique.

Les deux sont publiés sous forme d'artefacts privés et exportés en PDF.

Exécutez ceci en collaboration multi-sessions avec la personne ; ce n'est pas une tâche unique. Attendez-vous à plusieurs rounds de relecture.

Règles strictes

1. Lecture seule partout. N'envoyez jamais de messages Slack, n'ajoutez pas de réactions, ne créez ni ne mettez à jour de tickets Jira ou de pages Confluence, et n'enregistrez pas de graphiques Amplitude. Mettez cette règle dans chaque prompt de sous-agent.

2. Capturez d'abord, analysez ensuite. L'accès peut disparaître à tout moment, par exemple lors d'un licenciement. Déversez les données brutes sur le disque avant de résumer, et n'attendez pas l'analyse pour capturer la source suivante.

3. Pas de métriques inventées. Chaque nombre doit avoir une source. Lorsqu'un nombre manque, écrivez [DEMANDER À <NOM> : …] dans les notes et demandez à la personne ; ne devinez jamais.

4. Confidentialité. Suivez references/confidentiality.md en intégralité. En bref :

   • pas de noms de clients ou d'identifiants ;
   • pas de chiffres de revenus ou de ARR internes ;
   • pas de rémunération, de RH ou de contenu personnel ;
   • pas d'identifiants de connexion ;
   • pas d'URL internes en tant que contenu.

   Les déversements bruts restent locaux.

5. Créditez avec précision. Pour les fonctionnalités d'équipe, dites « fonctionnalité d'équipe ». Si un collègue a mis en œuvre quelque chose, dites-le. La personne décide de la force avec laquelle chaque élément est présenté.

6. Avant de modifier les notes après un cycle de relecture, copiez-les dans notes/backups/<fichier>.pre-<cycle>.md.

Espace de travail

Par défaut : ~/career-record/. Demandez à la personne si elle souhaite un emplacement différent.

career.json          # identité + contenu de premier plan pour les deux pages (voir examples/career.json)
raw/{github,jira,confluence,slack,cultureamp,amplitude}/   # exports non modifiés
notes/               # résumés par source + fichiers de synthèse que la construction lit
notes/session-handoff.md   # état courant ; à lire en premier après chaque compactage
output/              # achievements.html, overview.html, *-standalone.html, *.pdf

Tenez notes/session-handoff.md à jour au fur et à mesure. Enregistrez :

• l'état des phases ;
• les faits confirmés ;
• les décisions de la personne et ses préférences de mise en valeur ;
• les URL des artefacts ;
• les étapes de reconstruction.

Sauvegardez une courte mémoire de projet qui y pointe, afin qu'une session ultérieure puisse reprendre.

Phases

0. Entretien (AskUserQuestion)

Demandez :

• les dates de début et de fin ;
• les équipes ou tribus, avec les dates ;
• les niveaux et les dates de promotion ;
• les managers (pour le contexte uniquement) ;
• le but du dossier (recherche d'emploi, promotion, archive) et le public ;
• l'organisation GitHub et l'identifiant de connexion ;
• les faits marquants dont ils se souviennent, comme liste de départ pour recoupement ;
• les clients ou sujets qui ne doivent jamais être nommés. Ceux-ci vont dans la liste de blocage.
• les canaux Slack importants :
  • canaux de l'équipe et de la tribu ;
  • canaux de mission, de projet ou d'escouade ;
  • canaux d'astreinte ou d'alerte ;
  • canaux d'incidents ;
  • canaux de reconnaissance comme #shoutouts ;
  • canaux de processus ou de lancement.
• si des canaux privés ou des messages directs sont importants, par exemple des fils avec les managers, des collaborateurs proches ou un canal d'escouade privé.

Dites-leur clairement que les outils Slack ne peuvent capturer que les canaux publics. S'ils souhaitent inclure des canaux privés ou des messages directs, ils doivent copier ces messages dans raw/slack/ eux-mêmes, sous forme de fichiers .txt ou .md, un par canal ou personne. Les étapes sont dans la section Slack de references/sources.md.

Écrivez les réponses dans notes/phase0-background.md, y compris la liste des canaux et les sources privées que la personne collera. Créez <scratchpad>/blocklist.txt, un terme par ligne : noms de clients, identifiants d'entreprise et tout ce qu'ils ont signalé. Gardez-le en dehors de l'espace de travail.

1–5. Capture

Suivez references/sources.md pour chaque source :

1. GitHub
2. Jira
3. Confluence
4. Slack
5. Culture Amp (PDFs manuels)
6. Amplitude, optionnellement

Exécutez les sources indépendantes en parallèle avec des sous-agents. Si l'accès risque d'être révoqué bientôt, capturez Slack et Culture Amp en premier. Ce sont les plus difficiles à recréer.

Après la capture, écrivez un résumé par source : notes/<source>-summary.md.

5b. Recoupement

Construisez notes/crossref.md, plus crossref.json si utile :

1. Mappez chaque PR à ses clés Jira.
2. Regroupez chaque ticket Jira dans son epic ou mission.
3. Attachez les documents Confluence et les fils Slack à ces regroupements.

Travail antérieur à 2 ans. L'historique Slack ne remonte qu'à environ 2 ans. Slack contient la plupart de la « colle » qui explique pourquoi le travail a été fait et comment les pièces sont liées, donc pour tout ce qui est plus ancien, reconstruisez l'histoire à partir de GitHub et Jira, plus Confluence là où il existe :

• Cherchez des regroupements. De nombreux tickets sur le même tableau concernant le même sujet ou un sujet similaire, créés ou résolus à proximité, sont probablement une mission ou un projet. Les exemples sont une série de tickets IM, QOL ou IL sur un domaine fonctionnel. Autres indices :

  • un epic ou parent partagé ;
  • un label ou nom de sprint partagé ;
  • des PR vers les mêmes dépôts dans les mêmes semaines ;
  • une liste de contrôle Confluence ou un document de conception de cette période.

• Enregistrez chaque regroupement dans les notes comme une mission probable, signalée comme reconstruite. Listez :

  • les tickets et PR ;
  • la période ;
  • votre estimation de l'objectif ;
  • les preuves correspondantes.

  Par exemple : **Mission probable (reconstruite, pré-Slack) :** règles de visibilité, sept. 2023, IM-762/763/764 + 3 PR. [DEMANDER À <NOM> : nom de la mission, objectif, votre rôle ?]

• Confirmez le contexte avec la personne sauf si vous êtes certain, par exemple si le nom et la description de l'epic le décrivent explicitement. Demandez :

  • le nom et le but de la mission ;
  • qui d'autre y a participé ;
  • leur rôle dans celle-ci ;
  • le résultat ;
  • tout ce qui a mal tourné.

  Regroupez ces questions par période plutôt que de les poser une par une.

• N'inventez jamais la colle. Sans Slack ou confirmation de la personne, décrivez ce que les tickets et les PR montrent, pas la motivation ou l'impact.

• Pas d'évaluations avant 2024. Culture Amp ne remonte qu'à 2024. Pour tout ce qui est antérieur, il n'y a ni notes ni citations d'évaluateurs. Ne laissez pas un vide qui donne l'impression que la personne n'a eu aucune reconnaissance pendant cette période : notez que la source n'existe pas, et demandez à la personne tout retour dont elle se souvient ou qu'elle a conservé.

Chaque PR dont vous êtes auteur doit atterrir dans exactement un regroupement ou dans « divers/maintenance ». Marquez les PR que vous avez groupés par dépôt, heure ou titre comme inférés. Les Epics sans PR sont du travail non codé, comme la conception, la coordination ou le leadership, alors conservez-les. Montrez les regroupements à la personne et appliquez ses corrections.

6. Synthèse

Écrivez les fichiers de notes dans les formats de references/notes-format.md :

• notes/timeline.md : l'arc de carrière plus une section par trimestre.
• notes/project-cards.md : une fiche par regroupement, couvrant le problème, le rôle, ce qu'ils ont construit, l'impact/résultat, la technologie et les preuves.
• notes/people-skills-recognition.md : chiffres clés, matrice de compétences, leadership, citations de reconnaissance et moments de croissance.
• notes/cv-and-stories.md : 8 à 12 puces CV et 5 à 8 histoires STAR.

Chaque affirmation porte une référence (src: …). Ensuite, faites relire les fiches et les métriques par la personne. Ce cycle réorganise généralement les priorités et corrige les erreurs d'attribution.

7. Sortie

1. Exécutez le démarrage rapide d'artefact avec intent: "other", qui couvre les directives de conception de page.

2. Remplissez career.json à partir de examples/career.json :

   • nom, dates et sous-titre ;
   • paragraphes de résumé ;
   • tuiles d'impact. Les tuiles telles que PR, dépôts, revues, tickets Jira et pages Confluence sont générées automatiquement ; n'ajoutez que des suppléments.
   • bandes de graphique telles que les promotions ;
   • motifs de masquage ;
   • le bloc overview : voies, jalons (row 0/1 et anchor start/middle/end empêchent les collisions d'étiquettes), victoires, citations, faits et stack.

   Les types de barres sont role, promoted, lead, work, oncall et alt.

3. Construisez :

   python3 <skill>/scripts/build.py <workspace>
   python3 <skill>/scripts/build_overview.py <workspace>
   <skill>/scripts/check_blocklist.sh <scratchpad>/blocklist.txt <workspace>/output/achievements.html <workspace>/output/overview.html   # doit être 0
   

4. Vérifiez la mise en page :

   • scripts/export_pdf.sh écrit *-standalone.html.
   • scripts/screenshot.sh le rend ; regardez le PNG pour les collisions d'étiquettes ou les débordements.
   • Regardez particulièrement les jalons de la frise chronologique.

5. Publiez chaque page en tant qu'artefact privé avec l'outil Artifact, puis transmettez le même file_path pour republier plus tard. Donnez les deux liens à la personne.

6. Exportez les PDF avec scripts/export_pdf.sh <workspace>/output/achievements.html et scripts/export_pdf.sh <workspace>/output/overview.html. Le PDF long est principalement une annexe et fait souvent 50 à 100 pages.

7. Demandez à la personne de vérifier par sondage environ 10 affirmations par rapport aux preuves.

Boucle d'ajustement

La personne demandera de réorganiser l'accent, d'ajouter ou d'échanger des citations, ou d'ajouter un travail ancien manquant.

1. Modifiez les notes ou career.json.
2. Reconstruisez.
3. Exécutez la vérification de la liste de blocage.
4. Republiez vers les mêmes URL.
5. Réexportez les PDF.
6. Enregistrez chaque décision dans le fichier de passation.

Les premières années sont souvent sous-documentées : l'historique Slack ne remonte qu'à environ 2 ans, et Culture Amp ne couvre que 2024 et après. Recherchez Jira, Confluence et GitHub pour cette période spécifiquement.

Leçons des exécutions précédentes

• Infobulles : Le survol SVG <title> ne fonctionne pas à l'intérieur des artefacts. La vue d'ensemble utilise une infobulle JS pilotée par data-tip="Label|detail", et la construction la gère déjà.
• Longues histoires STAR : gardez les puces courtes et imbriquées plutôt que de longs paragraphes.
• Préférences des personnes :
  • mettez en valeur des escouades ou missions entières plutôt que des tickets individuels ;
  • présentez les signaux de confiance par rapport au niveau, par exemple « alors qu'il était encore junior » ;
  • incluez les entretiens de recrutement, les présentations et le leadership de processus, pas seulement le code.
• Les erreurs et les retours en arrière sont un matériau « Croissance » précieux lorsqu'ils sont racontés honnêtement. Ne les cachez pas, mais laissez la personne décider si l'un d'eux devient une histoire STAR.