TongyiDai/performance-reviewer-recommendation

Empfehlung von 360-Grad-Bewertern (Performance Reviewer Recommendation)

Aufgabe

Empfehlen Sie Personen, die die Arbeit eines Mitarbeiters während eines bestimmten Zeitraums direkt beobachtet haben, und erklären Sie, warum jede Person ein geeigneter 360-Grad-Bewerter ist. Verwenden Sie die Lark-CLI als Datenzugriffsschicht. Nutzen Sie den aktuellen Agent-Host – Doubao Enterprise, Codex oder Claude Code – als Reasoning-Schicht.

Dieses Skill bewertet nicht die Leistung des Mitarbeiters, weist keine Bewerter zu, sendet keine Einladungen, schreibt keine Leistungsbeurteilungen und leitet keine privaten Merkmale ab.

Standard-Benutzererfahrung

Akzeptieren Sie Anfragen wie:

Empfehle Zhang San für diesen Zyklus 10 360-Grad-Bewerter und begründe die Empfehlung für jede Person.

Lösen Sie den Mitarbeiter, den Bewertungszeitraum, die angeforderte Anzahl und die Rollenmischung auf. Verwenden Sie einen expliziten Bewertungszyklus oder Datumsbereich, sofern angegeben. Wenn der aktuelle Zyklus nicht anhand autorisierter Lark-Nachweise ermittelt werden kann, verwenden Sie ein bekannt gegebenes sechsmonatiges Beobachtungsfenster für eine direkte Empfehlungsanfrage; fragen Sie nach dem Zeitraum nur, wenn dies das Kandidatenpool wesentlich verändern würde oder der Benutzer ein Ergebnis für einen formellen Zyklus wünscht. Standardmäßig zehn Kandidaten, wenn die Anzahl nicht angegeben ist. Beziehen Sie Perspektiven von Vorgesetzten, Kollegen und funktionsübergreifenden Bereichen ein, wenn die Anfrage keine Mischung vorgibt; beziehen Sie direkte Untergebene ein, wenn der Mitarbeiter eine Führungskraft ist und das Bewertungsdesign eine Aufwärtsbeurteilung vorsieht.

Stellen Sie eine präzise Klärungsfrage, wenn eine Unklarheit den Kandidatenpool wesentlich verändern würde. Verzögern Sie die Aufgabe nicht für Präferenzen, die als Annahmen mitgeteilt werden können.

Host und Zugangsgate

Lesen Sie host-bootstrap.md vor jedem Feishu-Abruf.

• Doubao Enterprise: Verwenden Sie das integrierte Lark-Tool oder die genehmigte Lark-CLI-Brücke. Ist keines verfügbar, stoppen Sie mit blocked.
• Codex / Claude Code: Erfordert lokale lark-cli. Fehlt diese, teilen Sie dem Benutzer mit, sie zu installieren oder zu aktivieren, und stoppen Sie dann.
• Bevorzugen Sie lark-cli auth status --json --verify, um den vorgesehenen Mandanten, das Profil und die Benutzeridentität zu verifizieren. Wenn der aktuelle CLI-Build den Unterbefehl auth nicht bereitstellt, greifen Sie auf contact +get-user --as user und, falls erforderlich, auf task +get-my-tasks --as user als schreibgeschützten Kompatibilitätstest zurück. Behandeln Sie contact als den aufgelösten aktuellen Benutzer, behandeln Sie task nur als Benutzerkontext und verwandeln Sie den Kompatibilitätsmodus nicht in eine schreibfähige oder subjektbindende Behauptung.
• Verwenden Sie niemals stillschweigend eine Bot-Identität, ein anderes Feishu-Profil, eine Browsersuche oder manuell geratene Datensätze als Ersatz.

Zeichnen Sie Host, Lark-Profil, Identitätstyp, Token-Status, Bereiche und Prüfzeitpunkt auf, ohne Anmeldeinformationen zu speichern.

Abrufreihenfolge

Verwenden Sie data-source-map.md für die Quellenroute. Bevorzugen Sie die engste schreibgeschützte Abfrage, die die Anfrage beantwortet, und paginieren Sie dann vollständig.

1. Ziel auflösen: Identifizieren Sie den Mitarbeiter und bestätigen Sie den Organisationskontext.
2. Zeitraum auflösen: Verwenden Sie den expliziten Zyklus oder die Beobachtungsdaten; behalten Sie die Annahme bei, falls ein Standard verwendet wird.
3. Gemeinsame Arbeit finden: Durchsuchen Sie die substanzielle Zusammenarbeit des Ziels in Meetings, Transkripten, Nachrichten und Threads, Aufgaben, Dokumenten, OKRs, Projekten, Genehmigungen, Kalendern und E-Mails, sofern autorisiert.
4. Kandidatenkanten aufbauen: Verbinden Sie den Mitarbeiter mit Personen, die gemeinsam an der Arbeit beteiligt waren, Entscheidungen getroffen, Nachverfolgungen übernommen, Artefakte überprüft oder an zurechenbaren geschäftlichen Diskussionen teilgenommen haben.
5. Grenzen wahren: Zeichnen Sie Quelle, Datum, Zugriffsstatus, Paginierung, Kürzungen, gelöschtes Material und nicht lesbare Artefakte auf. Ein Meeting-Titel, eine Teilnehmerliste, eine Nachrichtenerwähnung oder eine Dokumentenansicht allein belegt keine Beobachtung.

Bevorzugen Sie Primärnachweise in dieser Reihenfolge:

1. gemeinsame Arbeitsergebnisse, Aufgabenverantwortlichkeit, Entscheidungen, Aktionspunkte, Meilensteine, substanzielle Bearbeitungen/Kommentare, OKRs, Genehmigungen und formelles Feedback;
2. zurechenbarer Nachrichten- oder Transkriptinhalt mit Kontext;
3. KI-generierte Meeting-Zusammenfassungen, die durch Primärmaterial gestützt werden;
4. gemeinsame Teilnahme, Gruppenmitgliedschaft, Erwähnungen, Ansichten und administrative CC nur als unterstützender Kontext.

Kandidatenregeln

Schließen Sie aus oder kennzeichnen Sie den Mitarbeiter, doppelte Identitäten, inaktive oder ausgeschiedene Benutzer, Personen außerhalb der zulässigen Population, richtliniendefinierte Konflikte und alle, für die im Zeitraum keine substanziellen Nachweise vorliegen.

Behandeln Sie mandantenübergreifende Mitarbeiter als berechtigungsgekennzeichnete Kandidaten, selbst wenn ihre direkten Nachweise stark sind. Bestätigen Sie, dass das Zielbewertungssystem sie akzeptiert, bevor Sie sie in die einreichungsbereite Shortlist aufnehmen.

Verwenden Sie Nachrichtenvolumen, Meeting-Anzahl, Anwesenheit, Reaktionen, Urlaub, Vergütung, Gesundheit, Alter, Geschlecht, ethnische Zugehörigkeit, Behinderung, private Beziehungen oder abgeleitete Persönlichkeitsmerkmale nicht als positive Nachweise.

Wenn verfügbar, fordern Sie zwei unabhängige Nachweise an, von denen mindestens ein substanzieller Primärnachweis vorhanden sein muss. Halten Sie Vertrauen getrennt vom Rang: Ein hochrangiger Kandidat mit unvollständigen Nachweisen bleibt mit geringem Vertrauen.

Wählen Sie nach Perspektivenabdeckung, nicht nach Beliebtheit. Vermeiden Sie eine Überkonzentration in einem Team oder einer Beziehungsart. Lassen Sie eine Rolle unbesetzt, wenn die Nachweise sie nicht stützen.

Nachweisdarstellung

Normalisieren Sie jede verwertbare Beobachtung in den Vertrag in evidence.schema.json. Behalten Sie Rohdaten und die Kandidaten-Namenszuordnung lokal. Geben Sie dem Host-Modell undurchsichtige Kandidaten-Aliase und minimale Fakten mit Quellenverweisen.

Jede Nachweiskante muss beantworten:

• Wer hat wen beobachtet?
• Welche Arbeitstatsache wurde beobachtet?
• Welche Dimension wird unterstützt?
• Wann ist es passiert?
• Welche Quelle kann ein Bewerter einsehen?
• Ist die Tatsache primär, abgeleitet, administrativ, eingeschränkt oder unbekannt?

Empfehlungslogik

Verwenden Sie eine transparente, vorläufige Bewertungsmatrix, wenn keine Unternehmensrichtlinie bereitgestellt wird:

Arbeitsrelevanz          30
Beobachtungstiefe        25
Aktualität               15
Nachweisbreite           10
Rollenkomplementarität   10
Bewertungszuverlässigkeit 10

Speichern Sie die Version der Bewertungsmatrix im Prüfprotokoll. Berechnen Sie Komponenten aus Nachweiskanten, nicht aus rohen Ereigniszahlen. Wenden Sie explizite Flags für spärliche Nachweise, Konflikte, doppelte Perspektiven und historische Konzentration an. Lassen Sie nicht zu, dass das Modell eine Zugangssperre oder einen Zustand unzureichender Nachweise überschreibt.

Standardausgabe

Führen Sie mit einer prägnanten, menschenlesbaren Shortlist:

Kandidat	Rolle	Empfehlungsgrund	Nachweisumfang	Vertrauen
Jemand	Funktionsübergreifend	Basierend auf gemeinsamer Lieferung, Schlüsselentscheidungen und nachfolgender Abnahme direkte Beobachtung von Lieferung und Zusammenarbeit des Zielmitarbeiters	Meetings, Aufgaben, Dokumente	Mittel

Jeder Grund muss die beobachtete Arbeitsbeziehung, die unterstützten Dimensionen und wesentliche Einschränkungen angeben. Kopieren Sie keine privaten Nachrichten und stellen Sie modellgenerierte Behauptungen nicht als Quellentatsachen dar.

Wenn eine maschinenlesbare Ausgabe erforderlich ist, geben Sie JSON zurück, das output.schema.json entspricht, und validieren Sie es mit:

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

Fügen Sie immer Quellenabdeckung, Nachweisverweise, ausgeschlossene Kandidaten, Datenlücken, Vertrauen, Host-Prüfmetadaten und human_review_required: true hinzu.

Abschlussgrenze

Der normale Endpunkt ist ein Empfehlungsentwurf für HR oder den verantwortlichen Manager. Weisen Sie keine Bewerter zu und schreiben Sie nicht in ein Leistungssystem zurück. Wenn der Benutzer später explizit einen Schreibvorgang anfordert, verlangen Sie eine Trockenlaufvorschau, Bestätigung, Idempotenzschutz und exaktes Rücklesen; halten Sie Empfehlung und menschliche Entscheidung als separate Datensätze.

Qualitätsprüfungen

Verwenden Sie synthetische oder bereinigte Testdaten, um fehlende Lark-CLI, abgelaufene Benutzeridentität, Bot-Zugriff nur, unvollständige Paginierung, unlesbare Transkripte, nur anwesenheitsbezogene Kandidaten, doppelte Identitäten, Konfliktflags, Rollenlücken, widersprüchliche Nachweise, spärliche Nachweise und ungültiges Modell-JSON zu testen. Melden Sie explizit 'blocked' oder 'insufficient_evidence', anstatt das Kontingent zu füllen.