Performance Reviewer Recommendation

Recommandation d'Évaluateurs de Performance

Une mission

Recommander des personnes ayant directement observé le travail d'un employé pendant une période spécifiée, et expliquer pourquoi chaque personne est un évaluateur 360 approprié. Utiliser Lark CLI comme couche d'accès aux données. Utiliser l'hôte Agent actuel — Doubao Enterprise, Codex ou Claude Code — comme couche de raisonnement.

Ce skill n'évalue pas la performance de l'employé, n'attribue pas d'évaluateurs, n'envoie pas d'invitations, ne rédige pas de fiches de performance et n'infère pas de traits privés.

Expérience utilisateur par défaut

Accepter des requêtes telles que :

Recommander 10 évaluateurs 360 pour Zhang San pour ce cycle, et expliquer la raison de chaque recommandation.

Résoudre l'employé, la période d'évaluation, le nombre demandé et la répartition des rôles. Utiliser un cycle d'évaluation explicite ou une plage de dates lorsqu'elle est fournie. Si le cycle en cours ne peut être établi à partir des preuves Lark autorisées, utiliser une fenêtre d'observation de six mois divulguée pour une demande de recommandation directe ; ne demander la période que lorsqu'elle modifierait sensiblement le vivier de candidats ou que l'utilisateur demande un résultat de cycle formel. Par défaut, dix candidats lorsque le nombre est omis. Inclure les perspectives des managers, des pairs et interfonctionnelles lorsque la demande ne spécifie pas de répartition ; inclure les rapports directs lorsque l'employé est un manager et que la conception de l'évaluation nécessite un retour descendant.

Poser une seule question de clarification concise lorsqu'une ambiguïté modifierait sensiblement le vivier de candidats. Ne pas retarder la tâche pour des préférences qui peuvent être signalées comme des hypothèses.

Hôte et passerelle d'accès

Lire host-bootstrap.md avant toute récupération Feishu.

• Doubao Enterprise : utiliser son outil Lark intégré ou la passerelle Lark CLI approuvée. Si aucun n'est disponible, s'arrêter avec blocked.
• Codex / Claude Code : nécessite lark-cli en local. S'il est manquant, demander à l'utilisateur de l'installer ou de l'activer, puis s'arrêter.
• Privilégier lark-cli auth status --json --verify pour vérifier le locataire, le profil et l'identité de l'utilisateur prévus. Lorsque la version actuelle de la CLI n'expose pas la sous-commande auth, recourir à contact +get-user --as user et, si nécessaire, task +get-my-tasks --as user comme sonde de compatibilité en lecture seule. Traiter contact comme l'utilisateur courant résolu, traiter task comme contexte utilisateur uniquement, et ne pas transformer le mode de compatibilité en une revendication d'écriture ou de liaison de sujet.
• Ne jamais utiliser silencieusement une identité de bot, un profil Feishu différent, une recherche par navigateur ou des enregistrements devinés manuellement comme substitut.

Enregistrer l'hôte, le profil Lark, le type d'identité, le statut du jeton, les périmètres et l'heure de vérification sans enregistrer les identifiants.

Séquence de récupération

Utiliser data-source-map.md pour la route source. Privilégier la requête en lecture seule la plus étroite qui répond à la demande, puis paginer complètement.

1. Résoudre la cible : identifier l'employé et confirmer le contexte organisationnel.
2. Résoudre la période : utiliser le cycle explicite ou les dates d'observation ; conserver l'hypothèse si une valeur par défaut est utilisée.
3. Trouver le travail partagé : rechercher la collaboration substantielle de la cible dans les réunions, transcriptions, messages et fils de discussion, tâches, documents, OKR, projets, approbations, calendriers et courriels lorsque cela est autorisé.
4. Construire les arêtes candidates : relier l'employé aux personnes qui ont conjointement livré le travail, pris des décisions, assuré le suivi, examiné des artefacts ou participé à des discussions professionnelles attribuables.
5. Préserver les limites : enregistrer la source, la date, le statut d'accès, la pagination, la troncature, le matériel supprimé et les artefacts illisibles. Un titre de réunion, une liste de participants, une mention dans un message ou une vue de document ne prouvent pas à eux seuls l'observation.

Privilégier les preuves primaires dans cet ordre :

1. livrables partagés, propriété de tâches, décisions, éléments d'action, jalons, modifications/commentaires substantiels, OKR, approbations et retours formels ;
2. contenu attribuable de message ou de transcription avec contexte ;
3. résumés de réunion générés par IA corroborés par du matériel primaire ;
4. co-présence, appartenance à un groupe, mentions, vues et CC administratifs comme contexte de soutien uniquement.

Règles concernant les candidats

Exclure ou signaler l'employé, les identités en double, les utilisateurs inactifs ou partis, les personnes en dehors de la population autorisée, les conflits définis par la politique, et toute personne sans preuve substantielle dans la période.

Traiter les collaborateurs inter-locataires comme des candidats marqués comme éligibles même lorsque leurs preuves directes sont solides. Confirmer que le système d'évaluation cible les accepte avant de les placer dans la liste restreinte prête à être soumise.

Ne pas utiliser le volume de messages, le nombre de réunions, la présence, les réactions, les congés, la rémunération, la santé, l'âge, le sexe, l'origine ethnique, le handicap, les relations privées ou la personnalité inférée comme preuve positive.

Exiger deux éléments de preuve indépendants lorsque disponibles, avec au moins un élément primaire substantiel. Garder la confiance séparée du rang : un candidat bien classé avec des preuves incomplètes reste de faible confiance.

Sélectionner pour la couverture des perspectives, pas pour la popularité. Éviter la sur-concentration dans une seule équipe ou un seul type de relation. Laisser un rôle non pourvu lorsque les preuves ne le soutiennent pas.

Représentation des preuves

Normaliser chaque observation utilisable dans le contrat dans evidence.schema.json. Conserver les instantanés bruts et la carte des noms de candidats en local. Donner au modèle hôte des alias de candidats opaques et des faits minimaux avec des références de source.

Chaque arête de preuve doit répondre à :

• Qui a observé qui ?
• Quel fait de travail a été observé ?
• Quelle dimension cela soutient-il ?
• Quand cela s'est-il produit ?
• Quelle source un évaluateur peut-il inspecter ?
• Le fait est-il primaire, dérivé, administratif, restreint ou inconnu ?

Logique de recommandation

Utiliser une grille transparente et provisoire lorsqu'aucune politique organisationnelle n'est fournie :

pertinence du travail             30
profondeur d'observation          25
actualité                         15
étendue des preuves               10
complémentarité des rôles         10
fiabilité de l'évaluation         10

Stocker la version de la grille dans le registre d'audit. Calculer les composants à partir des arêtes de preuve, pas des décomptes bruts d'événements. Appliquer des indicateurs explicites pour les preuves éparses, les conflits, les perspectives en double et la concentration historique. Ne pas laisser le modèle outrepasser un blocage d'accès ou un état de preuves insuffisantes.

Sortie par défaut

Commencer par une liste restreinte concise et lisible :

Candidat	Rôle	Raison de la recommandation	Étendue des preuves	Confiance
Quelqu'un	Collaboration inter-équipe	Basé sur la livraison conjointe, les décisions clés et la validation ultérieure, a directement observé la livraison et la collaboration de l'employé cible	Réunions, tâches, documents	Moyenne

Chaque raison doit indiquer la relation de travail observée, les dimensions soutenues et la limitation matérielle. Ne pas copier de messages privés ni présenter des affirmations générées par le modèle comme des faits sources.

Lorsqu'une sortie lisible par machine est nécessaire, retourner du JSON correspondant à output.schema.json et le valider avec :

python3 scripts/validate_output.py chemin/vers/resultat.json

Inclure toujours la couverture des sources, les références de preuves, les candidats exclus, les lacunes de données, la confiance, les métadonnées d'audit de l'hôte, et human_review_required: true.

Limite d'achèvement

Le point de terminaison normal est un projet de recommandation pour les RH ou le manager responsable. Ne pas attribuer d'évaluateurs ni écrire dans un système de performance. Si l'utilisateur demande explicitement une écriture plus tard, exiger un aperçu en simulation, une confirmation, une protection d'idempotence et une relecture exacte ; conserver la recommandation et la décision humaine comme des enregistrements séparés.

Contrôles qualité

Utiliser des jeux de données synthétiques ou anonymisés pour tester l'absence de Lark CLI, l'identité utilisateur expirée, l'accès bot uniquement, la pagination incomplète, les transcriptions illisibles, les candidats basés uniquement sur la présence, les identités en double, les indicateurs de conflit, les lacunes de rôles, les preuves contradictoires, les preuves éparses et le JSON de modèle invalide. Signaler blocked ou insufficient_evidence explicitement au lieu de remplir le quota.