パフォーマンスレビュアー推薦
ジョブ
指定された期間中に従業員の作業を直接観察した人を推薦し、各人がなぜ適切な360度レビュアーであるかを説明します。Lark CLIをデータアクセス層として使用します。現在のエージェントホスト（Doubao Enterprise、Codex、またはClaude Code）を推論層として使用します。
このスキルは、従業員のパフォーマンスを採点したり、レビュアーを割り当てたり、招待状を送信したり、業績記録を作成したり、私的な特性を推測したりしません。
デフォルトのユーザーエクスペリエンス
次のようなリクエストを受け付けます：
張三に、今期の360度レビュアー10名を推薦し、各人の推薦理由を説明してください。
従業員、レビュー期間、要求数、役割構成を解決します。明示的なレビューサイクルまたは日付範囲が指定されている場合はそれを使用します。承認されたLark証拠から現在のサイクルを確立できない場合は、直接推薦リクエストに対して明示された6か月の観察ウィンドウを使用します。期間が候補者プールを実質的に変更する場合、またはユーザーが正式なサイクル結果を要求した場合にのみ、期間を尋ねます。数が省略された場合はデフォルトで10名の候補者とします。リクエストに構成が指定されていない場合は、マネージャー、ピア、クロスファンクショナルな視点を含めます。従業員がマネージャーであり、レビューデザインが下方向からのフィードバックを求める場合は、直属の部下を含めます。
あいまいさが候補者プールを実質的に変更する場合に、簡潔な質問を1つ行います。前提として報告できる好みのためにタスクを遅らせないでください。
ホストとアクセスゲート
Feishu検索の前に host-bootstrap.md を読んでください。
- Doubao Enterprise: 組み込みのLarkツールまたは承認されたLark CLIブリッジを使用します。どちらも利用できない場合は、
blockedで停止します。 - Codex / Claude Code: ローカルに
lark-cliが必要です。ない場合は、ユーザーにインストールまたは有効にするよう伝え、停止します。 - 意図されたテナント、プロファイル、ユーザーIDを確認するには、
lark-cli auth status --json --verifyを優先します。現在のCLIビルドがauthサブコマンドを公開していない場合は、代替としてcontact +get-user --as userにフォールバックし、必要に応じてtask +get-my-tasks --as userを読み取り専用の互換性プローブとして使用します。contactを解決された現在のユーザーとして扱い、taskをユーザーコンテキストのみとして扱い、互換モードを書き込み可能またはサブジェクトバインディングの主張に変えないでください。 - ボットID、異なるFeishuプロファイル、ブラウザ検索、手動で推測されたレコードをサイレントに代用として使用しないでください。
ホスト、Larkプロファイル、IDタイプ、トークンステータス、スコープ、およびチェック時間を記録しますが、資格情報は記録しません。
検索シーケンス
ソースルートには data-source-map.md を使用します。リクエストに答える最も狭い読み取り専用クエリを優先し、完全にページネーションします。
- ターゲットの解決: 従業員を特定し、組織コンテキストを確認します。
- 期間の解決: 明示的なサイクルまたは観察日付を使用します。デフォルトが使用される場合は前提を保持します。
- 共有作業の検索: 権限がある場合、会議、トランスクリプト、メッセージとスレッド、タスク、ドキュメント、OKR、プロジェクト、承認、カレンダー、メールにわたってターゲットの実質的なコラボレーションを検索します。
- 候補エッジの構築: 従業員を、共同で作業を提供したり、意思決定を行ったり、フォローアップを所有したり、アーティファクトをレビューしたり、帰属可能なビジネス議論に参加した人々に接続します。
- 境界の保持: ソース、日付、アクセスステータス、ページネーション、トランケーション、削除されたマテリアル、読み取り不可能なアーティファクトを記録します。会議タイトル、出席者リスト、メッセージメンション、またはドキュメントビューだけでは観察を証明しません。
この順序で一次証拠を優先します：
- 共有成果物、タスク所有権、決定、アクションアイテム、マイルストーン、実質的な編集/コメント、OKR、承認、正式なフィードバック；
- コンテキストを伴う帰属可能なメッセージまたはトランスクリプトコンテンツ；
- 一次資料によって裏付けられたAI生成の会議サマリー；
- サポートコンテキストとしてのみの共同出席、グループメンバーシップ、メンション、ビュー、および管理用CC。
候補ルール
従業員自身、重複したID、非アクティブまたは退職済みユーザー、許可された母集団外の人、ポリシー定義の競合、および期間中に実質的な証拠がない人を除外またはフラグ付けします。
クロステナントコラボレーターは、直接的な証拠が強力であっても、資格フラグ付き候補として扱います。ターゲットレビューシステムがそれらを受け入れることを確認してから、提出準備完了のショートリストに配置します。
メッセージボリューム、会議数、出席、リアクション、休暇、報酬、健康、年齢、性別、民族、障害、私的な関係、または推測された性格を肯定的な証拠として使用しないでください。
利用可能な場合は2つの独立した証拠アイテムが必要であり、少なくとも1つは実質的な一次アイテムである必要があります。信頼度をランクから分離します：証拠が不完全な高ランクの候補は、依然として低信頼度です。
人気ではなく、視点のカバレッジを選択します。1つのチームまたは1つの関係タイプへの過度の集中を避けます。証拠がそれをサポートしない場合は、役割を未充足のままにします。
証拠表現
使用可能な各観察を evidence.schema.json のコントラクトに正規化します。生のスナップショットと候補名マップはローカルに保持します。ホストモデルには、ソース参照を持つ不透明な候補エイリアスと最小限の事実を提供します。
各証拠エッジは次に答える必要があります：
- 誰が誰を観察したか？
- どのような作業事実が観察されたか？
- それはどの次元をサポートするか？
- それはいつ発生したか？
- レビュアーが検査できるソースは何か？
- 事実は一次、派生、管理、制限、または不明か？
推薦ロジック
組織ポリシーが提供されていない場合、透過的で暫定的なルーブリックを使用します：
業務関連性 30
観察深度 25
新しさ 15
証拠の広がり 10
役割補完性 10
レビュー信頼性 10
ルーブリックバージョンを監査記録に保存します。コンポーネントを生のイベント数ではなく証拠エッジから計算します。証拠が乏しい、競合、視点の重複、過去への集中に対して明示的なフラグを適用します。モデルがアクセシブロックまたは証拠不十分状態をオーバーライドしないようにします。
デフォルト出力
人間が読みやすい短いリストを先頭に表示します：
| 候補者 | 役割 | 推薦理由 | 証拠範囲 | 信頼度 |
|---|---|---|---|---|
| 某人 | クロスチームコラボレーション | 共同納品、主要な意思決定、フォローアップ承認に基づき、対象従業員の納品とコラボレーションを直接観察 | 会議、タスク、ドキュメント | 中 |
各理由は、観察された作業関係、サポートされる次元、および重要な制限を述べなければなりません。プライベートメッセージをコピーしたり、モデル生成の主張をソース事実として提示したりしないでください。
機械可読な出力が必要な場合は、output.schema.json に一致するJSONを返し、次のコマンドで検証します：
python3 scripts/validate_output.py path/to/result.json
ソースカバレッジ、証拠参照、除外された候補、データギャップ、信頼度、ホスト監査メタデータ、および human_review_required: true を常に含めます。
完了境界
通常のエンドポイントは、HRまたは責任者マネージャーへの推薦ドラフトです。レビュアーを割り当てたり、パフォーマンスシステムに書き戻したりしないでください。後でユーザーが明示的に書き込みを要求した場合、ドライランによるプレビュー、確認、冪等性保護、そして正確な読み返しを必要とします。推薦と人間による決定は別々のレコードとして保持します。
品質チェック
合成または匿名化されたフィクスチャを使用して、Lark CLIの欠落、期限切れのユーザーID、ボットのみのアクセス、不完全なページネーション、読み取り不可能なトランスクリプト、出席のみの候補、重複ID、競合フラグ、役割ギャップ、矛盾する証拠、乏しい証拠、無効なモデルJSONをテストします。blocked または insufficient_evidence を明示的に報告し、割り当てを埋めることはしません。