TongyiDai/performance-reviewer-recommendation

Recomendación de Revisores de 360°

Un objetivo

Recomendar personas que hayan observado directamente el trabajo de un empleado durante un período específico y explicar por qué cada una es un revisor adecuado para la evaluación 360. Utilizar Lark CLI como capa de acceso a datos. Usar el host del agente actual (Doubao Enterprise, Codex o Claude Code) como capa de razonamiento.

Este Skill no evalúa el desempeño del empleado, asigna revisores, envía invitaciones, redacta registros de desempeño ni infiere rasgos privados.

Experiencia de usuario predeterminada

Aceptar solicitudes como:

Recomienda a Zhang San 10 revisores de 360° para este período y explica el motivo de cada recomendación.

Resolver el empleado, el período de revisión, la cantidad solicitada y la combinación de roles. Utilizar un ciclo de revisión explícito o un rango de fechas cuando se proporcione. Si no se puede establecer el ciclo actual a partir de la evidencia autorizada de Lark, utilizar una ventana de observación de seis meses divulgada para una solicitud de recomendación directa; solicitar el período solo cuando cambie materialmente el grupo de candidatos o el usuario solicite un resultado de ciclo formal. Por defecto, recomendar diez candidatos cuando se omita la cantidad. Incluir perspectivas de gerentes, pares y multifuncionales cuando la solicitud no especifique una combinación; incluir subordinados directos cuando el empleado sea gerente y el diseño de la revisión requiera retroalimentación descendente.

Hacer una pregunta de aclaración concisa cuando una ambigüedad pueda cambiar materialmente el grupo de candidatos. No retrasar la tarea por preferencias que puedan informarse como supuestos.

Host y puerta de acceso

Leer host-bootstrap.md antes de cualquier recuperación de Feishu.

• Doubao Enterprise: usar su herramienta Lark incorporada o el puente Lark CLI aprobado. Si ninguno está disponible, detenerse con blocked.
• Codex / Claude Code: requieren lark-cli local. Si falta, indicar al usuario que lo instale o habilite, luego detenerse.
• Preferir lark-cli auth status --json --verify para verificar el arrendatario, perfil e identidad de usuario previstos. Cuando la compilación actual del CLI no exponga el subcomando auth, recurrir a contact +get-user --as user y, si es necesario, task +get-my-tasks --as user como sonda de compatibilidad de solo lectura. Tratar contact como usuario actual resuelto, tratar task como solo contexto de usuario y no convertir el modo de compatibilidad en una afirmación con capacidad de escritura o vinculación de sujeto.
• Nunca usar silenciosamente una identidad de bot, un perfil de Feishu diferente, búsqueda en navegador o registros adivinados manualmente como sustituto.

Registrar el host, perfil de Lark, tipo de identidad, estado del token, alcances y hora de verificación sin registrar credenciales.

Secuencia de recuperación

Usar data-source-map.md para la ruta de origen. Preferir la consulta de solo lectura más específica que responda a la solicitud, luego paginar completamente.

1. Resolver el objetivo: identificar al empleado y confirmar el contexto de la organización.
2. Resolver el período: usar el ciclo explícito o las fechas de observación; conservar el supuesto si se usa un valor predeterminado.
3. Encontrar trabajo compartido: buscar la colaboración sustancial del objetivo en reuniones, transcripciones, mensajes e hilos, tareas, documentos, OKR, proyectos, aprobaciones, calendarios y correo cuando esté autorizado.
4. Construir aristas de candidatos: conectar al empleado con personas que hayan entregado trabajo conjunto, tomado decisiones, sido responsables de seguimiento, revisado artefactos o participado en discusiones comerciales atribuibles.
5. Preservar límites: registrar fuente, fecha, estado de acceso, paginación, truncamiento, material eliminado y artefactos ilegibles. Un título de reunión, lista de asistentes, mención en mensaje o vista de documento por sí solos no prueban observación.

Preferir evidencia primaria en este orden:

1. entregables compartidos, propiedad de tareas, decisiones, elementos de acción, hitos, ediciones/comentarios sustanciales, OKR, aprobaciones y retroalimentación formal;
2. contenido de mensajes o transcripciones atribuibles con contexto;
3. resúmenes de reuniones generados por IA corroborados por material primario;
4. co-asistencia, membresía de grupo, menciones, visitas y CC administrativo solo como contexto de apoyo.

Reglas de candidatos

Excluir o marcar al empleado, identidades duplicadas, usuarios inactivos o que hayan salido, personas fuera de la población permitida, conflictos definidos por política y cualquier persona sin evidencia sustancial en el período.

Tratar a los colaboradores entre arrendatarios como candidatos marcados por elegibilidad incluso cuando su evidencia directa sea sólida. Confirmar que el sistema de revisión objetivo los acepta antes de colocarlos en la lista corta lista para enviar.

No usar volumen de mensajes, cantidad de reuniones, asistencia, reacciones, licencias, compensación, salud, edad, género, etnia, discapacidad, relaciones privadas o personalidad inferida como evidencia positiva.

Requerir dos elementos de evidencia independientes cuando estén disponibles, con al menos un elemento primario sustancial. Mantener la confianza separada del rango: un candidato con rango alto pero evidencia incompleta sigue siendo de baja confianza.

Seleccionar por cobertura de perspectiva, no por popularidad. Evitar la sobreconcentración en un equipo o un tipo de relación. Dejar un rol sin cubrir cuando la evidencia no lo respalde.

Representación de evidencia

Normalizar cada observación utilizable en el contrato en evidence.schema.json. Mantener las instantáneas sin procesar y el mapa de nombres de candidatos localmente. Dar al modelo anfitrión alias de candidatos opacos y hechos mínimos con referencias de fuente.

Cada arista de evidencia debe responder:

• ¿Quién observó a quién?
• ¿Qué hecho laboral se observó?
• ¿Qué dimensión respalda?
• ¿Cuándo ocurrió?
• ¿Qué fuente puede inspeccionar un revisor?
• ¿El hecho es primario, derivado, administrativo, restringido o desconocido?

Lógica de recomendación

Usar una rúbrica transparente y provisional cuando no se proporcione ninguna política de la organización:

relevancia laboral         30
profundidad de observación 25
recencia                   15
amplitud de evidencia      10
complementariedad de roles 10
confiabilidad de revisión  10

Almacenar la versión de la rúbrica en el registro de auditoría. Calcular los componentes a partir de aristas de evidencia, no de recuentos brutos de eventos. Aplicar banderas explícitas para evidencia escasa, conflicto, perspectiva duplicada y concentración histórica. No permitir que el modelo anule un bloqueo de acceso o un estado de evidencia insuficiente.

Salida predeterminada

Encabezar con una lista corta legible y concisa:

Candidato	Rol	Motivo de recomendación	Alcance de evidencia	Confianza
Alguien	Colaboración interequipo	Basado en entrega conjunta, decisiones clave y aceptación posterior, tiene observación directa de la entrega y colaboración del empleado objetivo	Reuniones, tareas, documentos	Media

Cada motivo debe indicar la relación laboral observada, las dimensiones respaldadas y la limitación material. No copiar mensajes privados ni presentar afirmaciones generadas por el modelo como hechos de fuente.

Cuando se requiera salida legible por máquina, devolver JSON que coincida con output.schema.json y validarlo con:

python3 scripts/validate_output.py path/to/result.json

Incluir siempre cobertura de fuente, referencias de evidencia, candidatos excluidos, brechas de datos, confianza, metadatos de auditoría del host y human_review_required: true.

Límite de finalización

El punto final normal es un borrador de recomendación para RR. HH. o el gerente responsable. No asignar revisores ni escribir en un sistema de desempeño. Si el usuario posteriormente solicita explícitamente una escritura, requerir una vista previa de prueba en seco, confirmación, protección de idempotencia y relectura exacta; mantener la recomendación y la decisión humana como registros separados.

Controles de calidad

Usar fixtures sintéticos o redactados para probar la falta de Lark CLI, identidad de usuario caducada, acceso solo de bot, paginación incompleta, transcripciones ilegibles, candidatos solo por asistencia, identidades duplicadas, banderas de conflicto, brechas de roles, evidencia contradictoria, evidencia escasa y JSON de modelo inválido. Reportar blocked o insufficient_evidence explícitamente en lugar de llenar la cuota.