14174/job-search-assistant

Veille sur les sites d'emploi et remplissage de CV

Modes d'entrée

• Déterminez d'abord si la demande de l'utilisateur relève de l'un des deux modes indépendants ci-dessous ; le remplissage ne dépend pas de la configuration de la veille.
  • Mode Veille : Lire le Processus de veille, les Règles de correspondance des postes et la Structure des données ; en cas d'envoi externe, lire également Confidentialité et limites de confirmation.
  • Mode Remplissage : Lire le Processus de remplissage de CV, la Structure des données et Confidentialité et limites de confirmation ; en cas d'interaction avec un ATS, lire également les Spécifications d'adaptation ATS.
• Si l'utilisateur demande explicitement la création d'un dossier, la veille ou le remplissage, et que le projet ne possède pas de dossier .jobhunt/, vous pouvez initialiser une structure vide ; ne l'initialisez pas si vous ne faites que vous renseigner sur les capacités.
• Avant toute initialisation, création de dossier individuel ou lecture/écriture d'un dossier, lisez d'abord la Structure des données.
• Extrayez d'abord les faits du CV existant de l'utilisateur, écrivez-les dans le dossier structuré et enregistrez la source de chaque champ ; ne référencez que le CV existant, ne générez, ne peaufinez, ne reformulez ou n'inventez pas de CV/expériences.
• En cas de conflit de sources, de champ obligatoire inconnu ou de réponse inapplicable, posez une seule question clé ayant le plus grand impact à la fois ; les réponses doivent enregistrer la source, la date, l'état de confirmation et le champ d'application.
• Les règles de correspondance (spécialité, diplôme, lieu, compétences, durée, etc.) doivent être confirmées par l'utilisateur. En l'absence de configuration, ne faites que des suggestions, ne lancez pas la veille ; l'inconnu n'est pas considéré comme non conforme.

Limites de la veille

• N'accédez qu'aux domaines et chemins exacts que l'utilisateur a ajoutés manuellement et pour lesquels enabled=true et confirmed=true ; après chaque navigation ou redirection, revérifiez la portée et arrêtez-vous si elle est dépassée, puis signalez-le.
• La veille peut fonctionner de manière indépendante. Extrayez les offres en respectant la fenêtre de publication confirmée, et conservez la source originale, l'identifiant du poste, les exigences, la date et les preuves ; en cas de date manquante ou ambiguë, marquez comme "à vérifier" sans inventer.
• La déduplication et l'écriture suivent les priorités d'identité et les règles de patch minimal des documents de référence ; appelez upsert_job.py en série ; les liens externes sont simplement enregistrés comme "en attente" sans étendre la portée.
• Le rapport de scan unique doit indiquer la couverture réelle, les nouvelles offres, les correspondances, les exclusions avec raisons, les changements dans le pool d'entreprises, les échecs et les éléments en attente de traitement par l'utilisateur ; ne rapportez pas "aucune nouvelle offre globale" si la couverture est incomplète.
• N'utilisez les outils d'automatisation Codex disponibles que si l'utilisateur demande explicitement une planification ; ne créez pas de service résident ou de cron. En l'absence de changement, restez silencieux conformément au processus de référence.

Lors de l'exécution de la veille, respectez un ordre d'écriture unique : vérifiez d'abord la portée, puis extrayez, vérifiez les dates, dédupliquez, faites correspondre, et enfin écrivez et rapportez. Si une étape manque de preuves, conservez les parties terminées et indiquez la portée non terminée. La sortie de correspondance des postes doit distinguer "confirmé satisfait", "confirmé non satisfait" et "inconnu/à vérifier", en conservant les exigences originales du poste, la source des faits de l'utilisateur et les raisons d'exclusion ; en l'absence de règles de notation confirmées par l'utilisateur, ne fournissez qu'une explication qualitative. Le pool d'entreprises peut être alimenté manuellement par l'utilisateur ou découvert par des offres correspondantes, mais l'ajout d'une entreprise au pool d'entreprises n'équivaut pas à l'ajouter au pool de veille ; les sites web des entreprises, les locataires ATS et les liens externes doivent être vérifiés séparément.

Limites de remplissage, d'enregistrement et de soumission

• Vérifiez d'abord l'entreprise cible, l'appartenance du site web et le locataire ATS ; utilisez le navigateur/outil spécifié par l'utilisateur et réellement disponible, sans supposer son existence. L'analyse de PDF/documents ne peut utiliser que les compétences disponibles correspondantes.
• L'utilisateur lui-même effectue la connexion, le captcha et toute autre authentification ; ne conservez pas de mots de passe, cookies, OTP, jetons, informations financières ou autres matériels d'authentification, et ne contournez pas l'authentification ni ne modifiez de force des pages contrôlées.
• Avant de remplir, ne lisez que les archives nécessaires à cette transaction, les réponses applicables et la version de CV spécifiée par l'utilisateur. Avant d'envoyer pour la première fois un champ quelconque (ordinaire, hautement sensible ou pièce jointe), affichez la destination actuelle, le contenu à envoyer/résumé anonymisé, la source et l'action, et obtenez une confirmation explicite.
• Une fois la transaction confirmée explicitement, vous pouvez couvrir les actions de remplissage, téléchargement, sauvegarde automatique de page et sauvegarde indépendante du CV de l'entreprise spécifiées dans cette transaction ; tout changement de portée nécessite une nouvelle confirmation, l'autorisation n'est pas permanente et ne peut être réutilisée entre entreprises ou tâches.
• La sauvegarde du CV de l'entreprise est une action indépendante autorisée, mais nécessite une confirmation pour cette transaction ; après la sauvegarde, relisez les champs de la page, les messages de succès ou toute autre preuve fiable. En l'absence de preuve, marquez seulement comme "non vérifié", ne prétendez pas à un succès.
• Ne cliquez jamais sur "postuler", "soumettre" ou "envoyer" pour une offre ; ne cliquez pas non plus sur les boutons combinés "enregistrer et postuler" ; laissez toujours l'utilisateur effectuer cette action lui-même. Remplir/télécharger/sauvegarder avec succès n'équivaut pas à postuler avec succès.
• En cas d'échec d'un contrôle, d'une connexion ou d'un champ, utilisez uniquement des méthodes limitées et fiables ; arrêtez-vous à l'échec et signalez les champs manquants, les obstacles et les progrès conservés, sans réécrire de force ni effacer les brouillons.

Le rapport de remplissage doit distinguer chaque élément : "rempli", "téléchargé", "sauvegardé avec preuve", "non vérifié" et "échec" ; le statut après sauvegarde peut être enregistré comme "en attente de soumission par l'utilisateur", mais jamais comme submitted, sauf si l'utilisateur lui-même a agi et fourni une preuve fiable. Si la page se sauvegarde automatiquement ou si la signification d'un bouton est ambiguë, arrêtez l'action et expliquez les risques spécifiques ; ne vous fiez pas à une autorisation historique, à un nom d'entreprise identique ou à l'expérience "c'est généralement comme ça" pour remplacer la confirmation actuelle.

Routage des interactions ATS

• Pour l'interaction ATS, lisez simultanément les Spécifications d'adaptation ATS et la documentation des outils/navigateurs de compétences réellement disponibles dans l'environnement actuel ; pour les systèmes non testés, enregistrez uniquement l'expérience historique, ne déclarez pas la compatibilité.
• Localisez les contrôles par étiquette visible, sémantique et conteneur, saisissez puis relisez le résultat ; en cas de doute sur l'appartenance du contrôle, de divergence des options de date ou de champ effacé, passez à l'utilisateur.

Données et confidentialité

• Les données personnelles ne sont stockées que dans le dossier ./jobhunt/ du projet actuel ; le Skill global ne stocke aucune valeur personnelle. Une base de réponses locales ordinaires peut conserver des réponses non sensibles, confirmées et sourcées. Les journaux et rapports sont minimisés, jamais de texte sensible original ; les informations sensibles/très sensibles sont placées uniquement dans les archives privées du projet, lues à la demande, et jamais affichées intégralement dans les dialogues ou les journaux.
• N'écrivez jamais les exigences d'un poste comme des faits de l'utilisateur ; l'index CV ne fait que référencer les fichiers existants, ne les copie pas dans un package générique. .gitignore n'équivaut pas à un chiffrement ou un contrôle d'accès.
• Avant de partager, ne vérifiez que les compétences explicitement autorisées, agents/openai.yaml, les six documents de référence, un modèle vide et les quatre scripts de bibliothèque standard, puis exécutez un scan de confidentialité avant révision manuelle ; n'incluez pas d'archives personnelles, de CV, de tests, de caches ou de rapports de projet.
• Le package partagé ne contient que les processus et les structures vides, sans nom réel, coordonnées, adresse, pièce d'identité, compte, contenu de CV, captures d'écran, chemins personnels ou données de remplissage historiques ; en cas de détection, retirez ou vérifiez d'abord.

En cas d'incertitude sur l'intention de l'utilisateur, posez une seule question clé qui modifiera le mode, la portée d'accès ou l'autorisation ; les détails de nommage, format et répertoire à faible impact sont décidés selon l'état actuel du projet. Toute déclaration d'achèvement doit s'appuyer sur des preuves vérifiables (page, fichier, sortie de script, etc.).

Scripts standard (Python 3.10+)

La ligne de commande ne transmet que les informations publiques du poste, jamais les données personnelles ; <RépertoireSkill> désigne le répertoire du Skill actuellement chargé, ne codez pas en dur le chemin de l'utilisateur.

python -X utf8 "<RépertoireSkill>/scripts/init_workspace.py" "<RacineProjet>"
python -X utf8 "<RépertoireSkill>/scripts/validate_workspace.py" "<RacineProjet>/.jobhunt"
python -X utf8 "<RépertoireSkill>/scripts/upsert_job.py" "<RacineProjet>/.jobhunt/jobs.jsonl" "<JSONPoste>"
python -X utf8 "<RépertoireSkill>/scripts/privacy_scan.py" "<RépertoirePartagé>"

Les scripts ne fournissent que des garanties mécaniques (structure, déduplication) et ne remplacent pas les vérifications de source, d'autorisation, de portée et de confidentialité. Ce Skill ne garantit pas la compatibilité avec un ATS réel et n'exécute pas de service de veille résident. Toutes les écritures externes sont limitées à la portée explicite actuelle de l'utilisateur ; une autorisation ne peut être dérivée d'une tâche unique pour un usage à long terme. Avant et après chaque exécution, vérifiez la cible, la portée, l'action et les preuves, afin d'éviter de marquer par erreur des suggestions ou des brouillons comme terminés.