MartinezAgullo/évaluateur-d-offre-emploi

Évalue une offre d'emploi ou un message de recruteur (LinkedIn, email, chasseur de têtes) pour l'utilisateur. Il l'interviewe sur son package actuel, estime le salaire net à domicile pour le poste actuel et l'offre (sécurité sociale locale, impôt sur le revenu, coûts d'autónomo pour B2B), vérifie l'adéquation avec son CV, note les conditions (télétravail, avantages, trajectoire de carrière), propose les 2-3 questions importantes à poser au recruteur et rédige la réponse (refus ou demande de détails).

Qu'est-ce que évaluateur-d-offre-emploi ?

Ce skill est conçu pour aider les développeurs et professionnels à évaluer rapidement et précisément les offres d'emploi ou messages de recruteurs. Il se concentre sur le salaire net réel après impôts et cotisations sociales, un aspect souvent trompeur dans les comparaisons brutes. Le skill interroge l'utilisateur sur son package actuel et l'offre, puis calcule le net à domicile à l'aide de scripts Python (net_compare.py) et de données fiscales actualisées. Il analyse également la correspondance entre le CV de l'utilisateur et l'offre, note les conditions de travail, identifie les signaux du recruteur et propose des questions ciblées ainsi qu'un brouillon de réponse. Disponible sur les plateformes Claude Code, Codex CLI et Gemini CLI, ce skill utilise des fichiers de configuration séparés pour les données personnelles, garantissant la confidentialité et la réutilisabilité.

Compatible avec✓Claude Code✓Codex CLI~Cursor✓Gemini CLI
npx skills add https://github.com/MartinezAgullo/agent-skills-toolbox/tree/HEAD/skills/job-offer-evaluator

Installed? Explore more Productivité et collaboration skills: steipete/gemini, steipete/gh-issues, steipete/skill-creator · View all 6 →

Demander à votre IA préférée

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

Documentation

Évaluateur d'offre d'emploi

L'utilisateur reçoit régulièrement des messages de recruteurs et souhaite chaque fois le même tri : le rôle correspond-il, les conditions (nettes) réelles sont-elles meilleures que ce qu'il a, que demander, et que répondre. Les chiffres bruts selon les types de contrat et les pays sont trompeurs, donc le cœur de ce skill est une comparaison du salaire net à domicile basée sur les faits que l'utilisateur vous donne, jamais sur des faits que vous retenez ou supposez.

Étape 0 : Charger le contexte

Les données personnelles vivent en dehors du skill, donc la mise à jour, la copie ou la publication du skill ne les expose ni ne les écrase. Résolvez le dossier de données <data_dir> une fois, dans cet ordre :

  1. $JOB_SEARCH_DIR, si défini.
  2. job-search/ dans le dossier de configuration utilisateur de l'agent que vous exécutez : ~/.claude/job-search/ pour Claude Code, ~/.codex/job-search/ pour Codex CLI, ~/.gemini/job-search/ pour Gemini CLI. Pour tout autre agent, utilisez le dossier utilisateur équivalent.

N'utilisez jamais un dossier dans le skill ou dans un dépôt de projet. Si <data_dir> n'existe pas, créez-le, copiez les fichiers templates/profile.md et templates/offers_log.md de ce skill dans celui-ci, et dites à l'utilisateur quel chemin vous avez utilisé.

  1. CV. Lisez cv_path depuis <data_dir>/profile.md. S'il vaut ?, manque, ou que le fichier n'est pas trouvé, demandez à l'utilisateur un CV (chemin ou texte collé) et stockez le chemin dans le profil ; n'évaluez pas l'adéquation sans. Le CV est la source de vérité pour les compétences et le niveau d'ancienneté ; n'inventez pas d'expérience.
  2. LinkedIn (optionnel, au mieux). LinkedIn bloque généralement les lectures automatisées derrière un mur de connexion, donc essayez l'URL linkedin du profil une fois s'il y en a une, et si elle est bloquée, ignorez-la silencieusement. Ne demandez à l'utilisateur un profil collé ou un export PDF que lorsque quelque chose dans l'offre en dépend (par exemple, le recruteur prétend quelque chose sur son profil, ou le CV manque de quelque chose dont le rôle a besoin). Le CV reste principal ; LinkedIn n'est qu'une vérification croisée de ce que le recruteur a vu.
  3. Profil. Lisez <data_dir>/profile.md (voir Étape 1).
  4. Offres passées. Parcourez <data_dir>/offers_log.md. Mentionnez-le si la même entreprise ou le même recruteur réapparaît, ou si la rémunération se compare utilement à des offres antérieures.

Étape 1 : Confirmer ou interviewer (demandez, ne supposez pas)

Les chiffres de salaire et les conditions changent, et une mauvaise hypothèse ruine silencieusement la comparaison.

  • Le profil a des valeurs et last_verified existe : affichez un résumé compact des détails stockés et demandez à l'utilisateur de les confirmer ou de dire ce qui a changé. Ne posez une question que pour les champs marqués ? ou qu'ils corrigent. Si last_verified date de plus de 6 mois, dites-le et parcourez les champs plus attentivement.
  • Le profil est vide ou manquant (première exécution) : effectuez l'entretien complet ci-dessous, puis écrivez les réponses dans <data_dir>/profile.md et définissez last_verified à aujourd'hui.
  • Après tout changement, mettez à jour profile.md (conservez la disposition existante) pour que la prochaine exécution soit une confirmation rapide.

Envoyez les questions comme un message groupé (utilisez votre outil de questions structurées si l'agent en a un), ainsi que les détails de l'offre qui manquent.

1. Base financière et structure contractuelle

  • Salaire brut de base actuel et bonus/part variable annuel cible (et sa fiabilité de versement).
  • Type de contrat : indéfini/temporaire espagnol, EOR, autónomo/freelance, US W2 vs 1099, autre.
  • Nombre de versements (12 ou 14). Cela change les flux de trésorerie mensuels, pas le net annuel, mais compte lors de la comparaison des chiffres mensuels.

2. Localisation et contexte fiscal

  • Pays et ville/région où ils sont imposés maintenant, et où ils le seraient avec l'offre (les taux diffèrent par communauté autonome espagnole, canton suisse, État américain, etc.).
  • Tout régime spécial ou déduction (régime Beckham/impatrié, handicap, personnes à charge, prêt hypothécaire, déductions régionales).

3. Avantages et frais à la charge du salarié

  • Avantages non monétaires actuels : assurance santé privée, abondement retraite, tickets restaurant, subvention transport, actions, budget formation, chacun avec une valeur annuelle approximative en EUR.
  • Frais liés au travail qu'ils paient eux-mêmes : déplacements non compensés, équipement, coworking.

4. Mode de travail et impact financier

  • Modèle de travail actuel (100 % télétravail, hybride avec jours par semaine, au bureau) et leur modèle préféré avec le temps de bureau qu'ils toléreraient.
  • Si hybride ou au bureau : coût mensuel de déplacement et temps de déplacement hebdomadaire.

5. Seuil de décision

  • La hausse nette minimale qui rendrait un changement intéressant, par ex. "+15 % net effectif" (suggérez environ +15-20 % pour un changement d'emploi, plus élevé pour du B2B ou des offres moins stables, et laissez-les le modifier). Demandez les dealbreakers stricts (sur site, contrat seulement, secteur spécifique).

Par offre (jamais stocké dans le profil) : pour du B2B/horaire, les heures facturables réalistes par an et les écarts attendus entre contrats ; pour une rémunération non en EUR, le taux de change (l'Étape 2 le récupère).

Étape 2 : Comparaison du net à domicile

Comparez le net, pas le brut, pour le poste actuel et l'offre. Net signifie après sécurité sociale, impôt sur le revenu, et pour les freelances les coûts d'auto-emploi (cuota de autónomos, gestor, assurance). Ajoutez ensuite la valeur annuelle des avantages non monétaires et soustrayez les frais professionnels à votre charge pour obtenir un net effectif.

  • FX : pour les offres non en EUR, exécutez python3 scripts/fetch_fx.py USD (taux BCE via frankfurter.dev) et utilisez ce taux, en citant la date. Si la recherche échoue, demandez un taux à l'utilisateur.
  • Exécutez le script : python3 scripts/net_compare.py (voir --help). Le poste actuel est imposé dans --country, l'offre dans --offer-country (par défaut : le même). Il prend le type de contrat actuel, le brut (incluant la variable attendue), les avantages, les coûts supplémentaires, l'ajustement régional et les détails de l'offre, et imprime le net, le net effectif (en EUR), le delta et, avec --threshold, si la hausse franchit la barre. --irpf-shift (alias --region-adjust) est l'ajustement régional pour le pays actuel et --offer-region-adjust pour le pays de l'offre ; dites ce que vous avez passé.
    • Espagne (ES) : l'ajustement est un décalage de points de pourcentage IRPF (environ -0.01 à -0.015 pour les régions à faible imposition comme Madrid, +0.01 pour les régions plus imposées, 0 en cas de doute).
    • États-Unis (US) : fédéral uniquement, déclarant unique, déduction forfaitaire, pas de 401(k)/HSA, pas de déduction QBI. L'ajustement est le taux moyen d'impôt sur le revenu de l'État de l'utilisateur (0 pour TX/FL/WA, sinon demandez l'État). Pour du travail 1099, incluez l'assurance santé auto-payée dans --expenses ; pour des offres W-2, mettez la couverture santé de l'employeur et l'abondement 401(k) dans --offer-benefits.
    • Devises : les montants de l'offre sont dans la devise du pays de l'offre. --fx convertit la devise de rémunération dans cette devise (rémunération en USD imposée en Espagne : --fx 0.89), et --to-eur convertit la devise du pays de l'offre en EUR (rémunération en USD imposée aux US : --fx 1 --to-eur 0.89). Les avantages et coûts supplémentaires sont toujours en EUR.
  • Modules fiscaux : les règles par pays vivent dans scripts/tax/<cc>.py avec leurs chiffres dans data/tax_<cc>.json ; l'Espagne (ES) et les États-Unis (US) existent. Pour d'autres pays (Suisse, Royaume-Uni, etc.), estimez le net manuellement à partir des tranches d'imposition actuelles et des règles de sécurité sociale (recherche web pour les chiffres de l'année en cours), montrez les principales étapes, et étiquetez-le comme une estimation approximative. Si des offres de ce pays continuent d'arriver, suggérez de construire un module (references/adding-a-country.md).
  • Vérification d'obsolescence : net_compare.py imprime un WARNING lorsque les données fiscales sont obsolètes ou non vérifiées. Lorsque vous le voyez, dites-le à l'utilisateur et proposez la procédure de rafraîchissement ci-dessous avant de vous fier aux chiffres.
  • Énoncez toujours les hypothèses utilisées : taux de change, heures facturables, dépenses, région, année fiscale. Dites que le résultat est une estimation et qu'un gestor/conseiller fiscal doit le confirmer pour une décision réelle.
  • Pour du B2B, le net ignore toujours ce qu'un salarié obtient gratuitement : congés payés, arrêt maladie payé, protection chômage, accumulation de retraite, cotisations patronales. Donnez le "brut salarié équivalent" et signalez les risques contractuels (client unique, préavis, risque de faux auto-emploi, exclusivité).

Étape 3 : Adéquation et conditions

Adéquation (CV vs rôle). Notez sur 10 avec une ligne de justification. Listez les correspondances (avec preuves du CV), les lacunes (réelles vs simplement non listées), et le probable quotidien réel et niveau d'ancienneté par rapport à leur poste actuel. Les titres des recruteurs cachent souvent un travail plus restreint que ce qu'ils annoncent, donc dites ce qu'est probablement le rôle.

Conditions (priorité : salaire net > télétravail > trajectoire). Utilisez references/benefits-checklist.md pour la liste des avantages, et marquez chaque élément comme indiqué / par défaut légal / inconnu :

  • Salaire et avantages (santé, abondement retraite, congés payés, arrêt maladie, congé parental), en particulier pour les rôles hors d'Espagne où les valeurs par défaut légales diffèrent.
  • Mode de travail par rapport à leur préférence déclarée, plus le chevauchement de fuseau horaire et les déplacements.
  • Trajectoire de carrière : voie de progression, responsabilités, réputation de l'entreprise et du client, si le travail construit vers les target_roles_and_topics du profil ou s'en éloigne, stabilité de l'engagement.

Signaux du recruteur. Lisez le message lui-même en utilisant references/recruiter-signals.md (client final caché, prospection modélisée, salaires "jusqu'à", forme contractuelle vs rôle, périmètre vs titre) et listez les drapeaux et bons signes trouvés. Optionnellement, recherchez sur le web la réputation de l'entreprise et du client final.

Étape 4 : Verdict, questions, réponse

  • Verdict : Poursuivre, Demander d'abord, ou Refuser, avec les 2-3 raisons qui ont décidé, explicitement vérifiées par rapport à leur seuil et leurs dealbreakers.
  • Questions pour le recruteur : uniquement les 2-3 dont les réponses pourraient inverser la décision (généralement la structure de rémunération réelle et les conditions de congés payés, le périmètre réel et l'équipe, la durée du contrat et les conditions de résiliation). Pas de remplissage générique.
  • Brouillon de réponse, une fois la décision claire ou que l'utilisateur l'énonce, dans la langue du recruteur, court, dans la voix de l'utilisateur. Refus : remerciez, éventuellement une ligne de raison. Demande de détails : intérêt conditionnel plus les questions ; ne révélez pas leur salaire actuel (proposez plutôt une fourchette cible si utile). Si encore indécis, proposez brièvement les deux brouillons. Un paragraphe est une ligne (pas de retours à la ligne durs) et utilisez les tirets avec parcimonie.

Étape 5 : Enregistrer l'offre

Après le verdict, ajoutez une ligne à <data_dir>/offers_log.md (Date, Entreprise et client final, Rôle, Contrat, Rémunération offerte, Delta net effectif, Adéquation, Verdict, Résultat/commentaires). Demandez avant d'écrire si l'utilisateur n'a pas dit de l'enregistrer. Plus tard, lorsqu'il vous dit ce qui s'est passé (répondu, refusé, entretien), mettez à jour le Résultat de cette ligne.

Rafraîchissement annuel des données fiscales

Chaque data/tax_<cc>.json contient le barème de l'impôt sur le revenu de ce pays, les taux et plafonds de sécurité sociale ou de charges sociales, et les déductions (l'Espagne a aussi le tableau des cotisations autónomo), avec tax_year, verified_on et verified_by. Les chiffres deviennent obsolètes chaque janvier, donc rafraîchissez lorsque le script prévient, lorsque l'année civile dépasse tax_year, ou lorsque l'utilisateur le demande. Procédure :

  1. Recherchez les sources officielles listées dans le fichier sources. Espagne : AEAT pour le barème IRPF et le minimum personnel, Seguridad Social pour le tableau des cotisations RETA, la base de cotisation maximale et les taux salariés incl. MEI. US : Rev. Proc. d'ajustement à l'inflation de l'IRS pour les tranches et la déduction forfaitaire, SSA pour la base salariale de la Sécurité Sociale ; relisez les règles de l'Additional Medicare Tax et de l'impôt sur le travail indépendant, que la première version a prises de connaissances générales.
  2. Montrez à l'utilisateur une diff avant/après de chaque valeur modifiée avec son lien source. N'écrasez pas silencieusement : un mauvais chiffre fiscal corrompt silencieusement toutes les comparaisons futures, donc ils confirment d'abord.
  3. Sur leur approbation, modifiez le JSON, définissez tax_year, verified_on à aujourd'hui, et verified_by aux sources réellement lues (enlevez la mention "NOT checked" uniquement si vous avez vraiment vérifié par rapport aux pages officielles).
  4. Réexécutez un exemple de comparaison pour vérifier que rien n'est cassé.

Un rappel programmé est facultatif : si l'utilisateur veut un vrai rappel en janvier, proposez d'en configurer un avec le mécanisme de planification que l'agent ou le système d'exploitation fournit (cron, une tâche d'agent planifiée, un événement de calendrier) qui ouvre une session exécutant ce rafraîchissement.

Format de sortie

Gardez-le lisible, pas un essai. Utilisez exactement ces sections, dans cet ordre :

  1. TL;DR (2 lignes) : verdict, score d'adéquation, delta net effectif vs seuil.
  2. Comparaison nette : un tableau avec les lignes Brut, Sécurité sociale / cotisation, Impôt sur le revenu, Net, Avantages, Frais à votre charge, Net effectif, et les colonnes Actuel / Offre / Delta ; en dessous la liste des hypothèses.
  3. Adéquation : score, correspondances, lacunes, périmètre réel probable.
  4. Conditions : tableau court pour télétravail, avantages, trajectoire, risques.
  5. Signaux du recruteur (une ligne courte chacun) et Questions pour le recruteur : 2-3 éléments numérotés.
  6. Brouillon de réponse.
  7. Supposé ou non vérifié : liste à puces.

Ne produisez pas de paragraphes en prose là où un tableau ou des puces feront l'affaire.

Skills associés