peer-feedback · git:20260705.848fd9b · 2026-07-05 · sha256 0b4f7372b0294b83
peer-feedback git:20260705.848fd9bA
Immutable. This exact content is served forever at /api/v1/blob/0b4f7372b0294b83.
---
name: peer-feedback
description: "同僚への半期ピアフィードバック下書きを自動生成する。workIQ で 1:1 チャット・グループチャット・メンション・共通会議・メール・SPO の履歴を収集し、6項目テンプレートに沿ってポジティブかつプロモーション志向で起票する。Use when: ピアフィードバック, フィードバック下書き, 同僚評価, 半期フィードバック, 360度フィードバック。"
argument-hint: "同僚の名前（例: 田中さん、Alex Smith）。オプションで期間を指定（例: 田中さん 2025年下期）"
user-invocable: true
license: CC BY-NC-SA 4.0
metadata:
author: yamapan (https://github.com/aktsmm)
---
# 半期ピアフィードバック下書き生成
同僚への半期ピアフィードバックを、workIQ のインタラクション履歴を根拠にしてポジティブかつプロモーション志向で起票するスキル。
## When to Use
- 半期ピアフィードバック（同僚評価）の下書きを作りたいとき
- 「{同僚名}へのフィードバック下書きを作って」という依頼
- 「/peer-feedback {同僚名}」で直接呼び出したとき
## Prerequisites
- workIQ の EULA に同意済みであること
- 未同意の場合は `mcp_workiq_accept_eula` で同意を取得
## Done Criteria
- [ ] Phase 0: 同僚名・対象期間が確定している
- [ ] Phase 1: workIQ 6クエリを全て実行し、インタラクション履歴を収集した
- [ ] Phase 2: 業務関与を4観点で構造化した
- [ ] Phase 3: 6項目テンプレートに沿って下書きを生成した（ポジティブ re-frame 済み）
- [ ] Phase 4: 下書きを出力し、workIQ 不足点を注記した
---
## Phase 0: 入力確認
同僚名と対象期間を確認する。
| 項目 | デフォルト | 指定例 |
| -------- | ---------------------- | ----------------------------- |
| 同僚名 | （必須・引数から取得） | 田中さん、Alex Smith |
| 対象期間 | 直近 6 ヶ月 | 2025H2、2025年10月〜2026年3月 |
**同姓同名ガード**: 姓のみ指定の場合、フルネームまたは部署を確認してから進む。
**ロール確認（MANDATORY）**: workIQ で同僚のロール・役職・チーム・組織を取得する。Phase 3 でロールに即したフィードバックを書くための前提情報。
```
{name} のロール、役職、チーム、組織情報を教えてください。
```
**ミッション・バリュー確認（MANDATORY）**: 対象者の所属組織の公式ミッション原文と、公式に定義されたカルチャー / バリュー要素名を確認する。Phase 3 で本文に原文・固有名を展開するため、`組織のミッション` `コアバリュー` のような一般語に丸めず、原文と固有名を Phase 0 で控えておく。既に既知の場合は再取得不要。
---
## Phase 1: インタラクション収集（workIQ 6クエリ）
以下の順にクエリを実行し、結果を記録する。
**取得失敗・件数 0 の場合でもスキップしない**。取得できなかった旨を Phase 4 で注記する。
> ⚠️ **ラベル検証**: workIQ が返す会議名やチャット名はカレンダー上の表示名であり、活動の実態と一致しないことがある（例: 「勉強会」名義だが実態はプロジェクト定例）。Phase 2 の構造化前に、主要な活動の実態をユーザーに確認する。
### Q1: 1:1 直接チャット
```
{name} との 1:1 のダイレクトメッセージを {period} の分を教えてください。
主なトピックや相談内容のサマリーもお願いします。
```
### Q2: グループチャット共同参加
```
{name} と私の両方が参加したグループチャットを {period} の分で教えてください。
どんな話題・プロジェクトの会話だったか概要もお願いします。
```
### Q3: 相互メンション
```
{period} に {name} が私をメンションしたメッセージ、または私が {name} をメンションしたメッセージを教えてください。
```
### Q4: 共通会議
```
{period} に {name} と私の両方が参加した会議の一覧を教えてください。会議名と日時もお願いします。
```
### Q5: メール往来（To / Cc を含む）
To での直接往来だけに絞ると取得が弱くなりやすいので、Cc 同席も含めて「同じ案件のメンバーとして関わったメール」を広く拾う。
```
{period} に {name} と私が関与したメールを教えてください。To での直接往来だけでなく、片方が To で片方が Cc に入っているもの、または同じスレッドに両者がいるものも含めてください。件名と概要、両者の関与（To / Cc / From）をリストで。
```
### Q6: SPO / ファイル共同編集
```
{period} に {name} と私が共同で編集または共有した SharePoint・OneDrive のファイルを教えてください。
```
---
## Phase 2: 業務関与の構造化
Phase 1 の収集結果を以下の4観点に分類する。
| 観点 | 整理する内容 |
| ------------------------------ | ---------------------------------------------------- |
| **協働プロジェクト・テーマ** | どのプロジェクト・業務で一緒に動いたか |
| **その人の貢献・行動** | 具体的にどんな行動・成果物があったか |
| **自分との関係で生まれた価値** | その人の関与で何が良くなったか、助かったか |
| **成長余地の素材** | 改善できそうな点（ポジティブ re-frame 前の事実メモ） |
---
## Phase 3: フィードバック下書き生成
### 参照テンプレート
→ [./references/feedback-template.md](./references/feedback-template.md) を参照する
### 文体ルール（MANDATORY）
- **差別化を軸にする**: 冒頭で「その役割なら誰でもやること」を書かない。同じロールの他者と比較して「この人だからこそ」の行動パターンを起点にする。基本的な職務遂行の描写は読み手に刺さらない
- **名前で呼ぶ**: 本文中は二人称（あなた）ではなく同僚の名前（例: 堀さん、田中さん）で統一する。セクション見出しはフォーム定義のまま（「あなたの〜」）で残してよいが、本文は名前呼びの方が具体的で説得力が出る
- **です/ます統一**: フィードバックフォームはフォーマル文脈のため、本文は「です/ます」で統一する。リズム変化が必要な場合は体言止めで作る。常体（〜できた。〜ない。〜だと思う。）を混ぜない
- **プレーンテキスト出力**: マークダウンの太字（`**`）や装飾記法を使わない。フィードバックフォームへのコピペ時に崩れるため、装飾なしの地の文で書く
- **コアバリュー・ミッション接続**: 行動や成果を所属組織のコアバリューやミッションと紐付けて言語化する。パターン: 行動を先に描写し、同じ段落内でバリュー名と接続理由を1文で示す。ラベル貼り単独（「〜の実践そのものです」だけ）は避け、全省略も避ける。各セクションに最低1箇所は接続を入れる。以下を厳守する: (1) `組織のミッション` `コアバリュー` のような抽象ラベルに丸めず、Phase 0 で取得した公式ミッション原文と公式バリュー固有名（例: Growth Mindset, Customer Obsession 等の固有名）を本文に直接展開する。(2) 同一バリューの繰り返しを避け、セクションごとに異なるバリューに接続して多面性を出す。(3) 可能ならミッション原文は引用形式で本文に1回以上登場させる
- **抽象化を優先**: 個別案件名を列挙するとプロジェクト報告になる。案件名は例示に留め、「繰り返し発揮されたパターン」や「関係性の質」を中心に書く
- **多者価値の言語化**: その人の行動が複数の関係者（顧客・自分・組織など）に同時に価値を生んでいる場合、「三方よし」の構造として明示すると説得力が増す。単一方向の貢献（「顧客に良かった」だけ）より、構造的な価値創出として描く
- **ロールに即したフレーミング**: Phase 0 で取得した役職を踏まえ、「その役割で卓越している点」を軸に書く。相手の職責から見て何が価値かを意識する
- **相談関係の言語化**: 自分が頻繁に相談・壁打ちしていた場合、相手を「信頼できるアドバイザー」「安心して途中段階の話を持ちかけられる存在」として描写する。単なる調整役扱いにしない
- **数値・インパクトの活用**: 「よくやってくれた」ではなく、頻度・規模・影響範囲で価値を伝える
### ポジティブ re-frame ルール（MANDATORY）
- **ネガティブな観察は書き換える**: 「〜が不足している」→「さらなる影響拡大のために〜を強化すると、次のステージでさらに輝ける」
- **再考セクションは無理に埋めない**: 記載できる具体例がない場合はセクションごとスキップしてよい
- **プロモーション志向**: その人が昇進・昇格できるように、成果・行動・影響範囲を具体的に書く
### 出力フォーマット
以下の構造で Markdown を生成する（詳細は feedback-template.md を参照）:
```
# {対象者名} へのフィードバック
## 継続してほしいこと
### 私が思うあなたのとても良いところと継続してほしいこと
（記入）
### あなたの強みをより活かすための私からの提案
（記入）
## 再考してほしいこと（任意）
### 私が思う考え直してはどうかと思うこと
（記入、またはスキップ）
### 私が思う別の方法で実施してはどうかと思う具体的な例
（記入、またはスキップ）
## 追考
### 私があなたと協業していて最も価値を感じることは
（記入）
### その他私からのフィードバック
（記入）
```
---
## Phase 4: 出力・レビュー
1. 上記フォーマットで下書き Markdown を出力する
2. 末尾に以下の注記セクションを追加する:
```markdown
---
### ⚠️ workIQ から取得できなかった情報
- （取得できなかったクエリと理由を列挙。全件取得できた場合はこのセクションを省略）
```
3. 出力後、以下をユーザーに確認する:
- 「追加したいエピソードや具体的な出来事はありますか？」
- 「再考セクションに記載したい内容があれば教えてください」
- 「全体のトーンや強調箇所に修正はありますか？」
---
## Error Handling
| 状況 | 対応 |
| ------------------------ | ---------------------------------------------------------------------- |
| workIQ クエリが全て 0 件 | 取得失敗を報告し、ユーザーにエピソードを直接ヒアリングして下書きを生成 |
| 同名の同僚が複数いる | フルネームまたは部署を確認してから再クエリ |
| 期間が不明確 | 「直近 6 ヶ月」で実行し、その旨を注記 |
| workIQ EULA 未同意 | `mcp_workiq_accept_eula` で同意後に再実行 |