LINE、PDF、打ち合わせ。散らばった修正依頼を、抜けのない作業指示書にするSkill

以下の内容を `SKILL.md` として保存し、Agent Skillとして登録してください。

- 本文を省略・要約・独自変更しない
- 登録後は「整理したい修正依頼と、現在の成果物、当初の依頼内容があれば指定してください」と案内する
- 修正依頼の整理だけを頼まれた場合は、成果物の変更や外部への送信を行わない

---
name: client-feedback-triage
description: クライアントからメール、チャット、PDFコメント、打ち合わせメモなどで届いた修正依頼を一件ずつ分解し、制約内の具体案、確認事項、追加対応の概算、実行可能な修正指示書を作る。AI利用者への確認とクライアント向け文面を分け、Web制作、デザイン、動画、文章などの成果物に対する複数のフィードバックを、止めすぎず根拠付きで前へ進めたいときや、修正後の対応漏れを照合したいときに使う。人事評価のフィードバック作成や、AI回答への単純な書き直し指示には使わない。
---

# Client Feedback Triage

クライアントの言葉を都合よく補完せず、散らばった修正依頼を**確認可能な作業単位**へ変える。曖昧さを見つけるだけで終わらず、確認できている制約の中で具体案を出し、相手が選びやすい状態まで前へ進める。整理の結果と、成果物そのものの変更は別の作業として扱う。

## 入力を確認する

利用可能な範囲から、次の資料を確認する。

- クライアントから届いた修正依頼：メール、チャット、コメント、PDF、議事メモなど
- 現在の成果物：Webページ、画像、動画、文章、スライドなど
- 当初の依頼内容：見積書、提案書、仕様書、初回ヒアリング記録など
- 必要に応じて、過去の修正版と承認記録

すべてが揃っている必要はない。読めなかった資料や不足している資料は明示し、読めた情報だけで判断する。ユーザーがすでに示した情報を聞き直さない。

対象案件や参照範囲が分からず、別案件の情報を混ぜる危険がある場合だけ、作業前に確認する。

「前に送った」「以前の案」のように、参照物が存在すると分かる表現がある場合は、すぐ再共有を求めない。ユーザーが参照を許可した案件フォルダ、会話、添付、共有資料の範囲で、ファイル名だけでなく内容や日付も使って探す。PC全体や無関係な会話へ探索範囲を広げない。見つからなければ、まずAI利用者へ、手元にあるか、または参照先を指定できるか確認する。

## 確認先を分ける

質問や提案を作る前に、誰が次の情報を持っているかを判断する。確認先は次の4つを混ぜない。

1. `AIが自分で確認する`：アクセスを許可された案件ファイル、URL、会話、添付、仕様書、見積書を調べれば分かること
2. `AI利用者への確認`：このSkillを使っている制作者・担当者が、ファイルの場所、実装状況、料金表、判断基準などを回答できること
3. `クライアントへ確認が必要`：AI利用者も分からず、クライアントの選択、承認、未共有情報がなければ決められないこと
4. `クライアント向け文面案`：ユーザーが必要としている場合だけ作る、3の内容を尋ねるための下書き

まず1を行い、解決しなければ2へ進む。AI利用者へまだ確認していないことを、いきなりクライアント向け文面へ入れない。AI利用者が「手元にもない」「クライアントに聞く必要がある」と判断した項目だけを3へ移す。

クライアント向け文面案は、AI利用者への質問と別の見出しで示す。ユーザーから作成を求められていない場合は作らない。作成しても自動送信はしない。

## 修正依頼を分解する

メッセージ単位ではなく、**独立して完了確認できる変更単位**へ分ける。1文に複数の変更が含まれていれば分割し、同じ変更が複数資料に現れる場合は統合して参照元を併記する。

各項目には次を持たせる。

- ID
- 対象箇所または時間位置
- 元の依頼を短く忠実に要約した修正内容
- 参照元と日時
- 状態
- 完了条件
- こちらからの提案
- 必要な確認

原文の転載は判断に必要な最小限に留める。発言者と日時を確認できない場合は推測しない。

## 状態を判定する

状態の定義と修正指示書の形式は、次の「修正依頼の状態と指示書形式」を使う。

# 修正依頼の状態と指示書形式

この資料は、修正依頼を仕分けるとき、修正指示書を作るとき、修正後を検品するときに使う。

## 状態

| 状態 | 判定条件 | 次の処理 |
|---|---|---|
| 作業可能 | 対象箇所、望む変化、完了確認の方法が分かり、他の指示と両立する | 指示書へ入れる |
| 提案付き確認 | 複数解釈があるが、制約と現在の成果物を確認できる | 観察した原因に対応する案と推奨案を示して選んでもらう |
| 要確認 | 必要値や判断材料がなく、合理的な案を作るための制約もない | 分からないことを示し、回答しやすい質問を一つにまとめる |
| 探索後に確認 | 「前に送った」など参照物の存在が分かる | 許可範囲を探し、見つかれば対応づけ、なければまずAI利用者へ参照先や手元の資料を確認する |
| 矛盾 | 同じ対象へ両立しない指示がある、または承認済み方針と衝突する | 両方の根拠を示して選択を求める |
| 追加対応案 | 当初資料に対象外の明記がある、または新しい成果物・機能・工程が増える | 実現案、前提、概算工数・納期・根拠のある金額を示す |
| 参照不能 | 必要な添付、リンク、版、環境を確認できない | 不足資料を示す |
| 対応不要 | 取り下げ、重複、すでに反映済みであることを根拠付きで確認できる | 指示書の対象外欄へ残す |

迷う場合は`作業可能`へ寄せず、最も具体的な未解決状態を選ぶ。

## 修正項目表

```markdown
| ID | 対象箇所 | 修正内容 | 状態 | 完了条件 | こちらからの提案 | 参照元 | 確認先 | 確認事項 |
|---|---|---|---|---|---|---|---|---|
| R-001 | [ページ、部品、段落、時刻] | [一つの変更] | [状態] | [観察可能な条件] | [必要な場合のみ] | [資料名・日時] | [AI自身／AI利用者／クライアント／なし] | [必要な場合のみ] |
```

IDは`R-001`から連番にする。元の番号やコメントIDがある場合は参照元欄に残す。

## 修正指示書

```markdown
# 修正指示書

- 案件：
- 対象成果物：
- 対象版・確認日時：
- 作成日：

## 参照資料

- [資料名、URLまたはパス、日時]

## 作業可能な修正

| ID | 対象箇所 | 修正内容 | 完了条件 | 参照元 |
|---|---|---|---|---|

## 提案・選択待ち

| ID | 確認済みの制約 | こちらからの案 | 推奨案と理由 | 選んでほしいこと |
|---|---|---|---|---|

## 探索・確認が必要

| ID | 状態 | 確認した範囲 | 次に必要なこと |
|---|---|---|---|

## 追加対応案

| ID | 実現案 | 前提 | 概算工数・納期 | 概算金額と根拠 |
|---|---|---|---|---|

## AI利用者への確認

- [AIが自分で確認できず、制作者・担当者なら回答または資料指定できること]

## AI利用者への提案

- [確認した成果物と根拠に基づく提案。クライアントの決定事項とは分ける]

## クライアントへ確認が必要なこと

- [AI利用者も回答できず、クライアントの選択・承認・情報が必要なこと]

## クライアント向け文面案

[ユーザーが求めた場合だけ作る。不要または時期尚早なら「未作成」と記す]

## 今回の対象外

- [取り下げ、重複、対応済みなど。根拠を添える]
```

空の節は無理に残さず、「なし」と一行で示す。

## 照合結果

```markdown
# 修正対応の照合結果

- 確認した成果物：
- 照合した指示書：
- 確認日時：

| ID | 結果 | 確認した根拠 | 残っていること |
|---|---|---|---|

## 再確認が必要な項目

- [未対応、一部対応、確認不能だけを列挙]
```

見た目や動作の確認に特定の画面幅、端末、アプリ、再生環境が必要なら、確認環境を根拠欄に書く。

主な判断原則：

- 対象箇所と望む変化が特定でき、他の指示と両立するものだけを`作業可能`にする。
- 「もっと目立たせる」のような視覚的な依頼は、現在の成果物を実際に確認し、目立たない原因を観察してから案を作る。色調、ブランド、対象者などの制約と観察結果の両方が分かる場合は、その範囲で案と推奨案を出して`提案付き確認`にする。
- 「前に言ったところ」のように参照先の存在が示されている場合は、許可範囲を探索してから`探索後に確認`または`参照不能`を判断する。
- 同じ箇所への指示が両立しない場合は、新しい方を自動採用せず`矛盾`にする。
- 当初資料との不一致を根拠で示せる場合は、止めるだけでなく、現実的な実現案、前提、概算工数、納期への影響をまとめて`追加対応案`にする。料金内外や契約上の結論は断定しない。
- 成果物や添付を開けず対象を確認できない場合は`参照不能`にする。

## 提案してから確認する

作業可能でない項目のうち、作業開始を妨げるものだけを質問にする。質問は項目ごとにばらばらに送らず、相手が短く選べる形へまとめる。

提案を作るときは、確認できた制約と、成果物から観察した根拠を先に示す。そのうえで実現可能な案を必要な数に絞り、違いと推奨案を示す。実物から一つの原因と適切な修正が明確なら、選択肢を水増ししない。AIが考えた内容は「こちらからの提案」と明記し、クライアントの決定事項と混ぜない。

ボタン、配色、余白、写真、レイアウトなど見た目に関する提案は、対象画面、ファイル、画像のいずれかを確認してから作る。実物を確認できない場合は、濃い色、110%、枠線追加などの具体策を想像で出さず、AI利用者へURL、ファイル、スクリーンショットのいずれかを頼む。確認後は、コントラスト不足、配置、余白、文言、競合要素など、実際に観察した原因に対応する案を出す。

小さく、可逆的で、既存方針を変えない調整は、推奨案を示してユーザーの判断を求める。ブランド、金額、納期、機能、公開内容などへ影響する選択は、承認前に確定しない。

ユーザーが顧客向け文面を必要としており、AI利用者への確認を経てもクライアントの回答が必要な場合は、責任追及や専門用語を避け、次の順で短い確認文を作る。

1. 受領したこと
2. そのまま進められる内容
3. こちらからの具体案と推奨案
4. 選んでほしいこと、または追加で必要な情報

外部への送信はしない。送信や下書き保存は、ユーザーが明示的に依頼した場合だけ行う。

## 追加対応の概算を作る

当初範囲から増えた可能性がある依頼は、「正式な依頼ですか」と聞くだけで返さない。現在分かる範囲で、最小構成と必要に応じた別案を作り、追加される作業、前提、概算工数、納期への影響を示す。

金額を出す根拠は次の順で探す。

1. 料金表、見積書、契約書にある単価や追加作業ルール
2. 同じユーザーが承認した類似作業の過去見積もり
3. 作業分解から出した概算時間と、ユーザーが指定した時間単価

根拠がない金額は作らない。その場合も、作業項目と概算時間または日数の幅は、前提を明記して提案する。技術構成や必要項目が不明で幅が大きい場合は、簡易案・標準案のように分ける。

ページ数、文字数、点数など作業量そのものが不明でも、確認だけで止めない。「4ページ・約2,000字の場合」のように仮の規模を明示したシナリオ別概算を作り、実資料の確認後に再計算すると伝える。概算は、原稿整理、制作、確認、修正、書き出しなどの作業分解から積み上げ、一般的な相場を根拠にしない。

顧客向けには、例えば「簡易フォームなら、氏名・連絡先・受取希望日を受け付け、店舗へ通知する構成で、概算○〜○時間です。自動返信や受付枠の管理を含める場合は別案になります」のように、相手が次を選べる形にする。具体値は案件資料と作業環境に基づいて調整する。

## 修正指示書を確定する

不明点への回答を受けたら、元の修正項目へ反映し、変更履歴を残す。回答によって別の変更が増えた場合は、新しいIDを付ける。

作業場所が明確で書き込み可能なら、案件内の分かりやすい場所に`修正指示書.md`として保存する。保存先が不明、またはファイル作成を求められていない場合は、同じ内容をチャット内のMarkdownで返す。

指示書には次を含める。

- 対象成果物と版
- 参照した資料
- 作業可能な修正項目
- 提案・選択待ちの項目
- 探索または確認が必要な項目
- 追加対応案
- 今回対象外と確認できた内容

完了条件は、修正後に観察できる表現にする。「見やすくする」ではなく、「スマートフォン幅で見出しが2行以内に収まり、ボタンと重ならない」のように書く。ただし、資料にない数値や仕様を勝手に追加しない。

## 成果物を変更するとき

修正依頼の整理だけを頼まれた場合、成果物を変更しない。ユーザーが実装・編集も依頼した場合だけ、確定した`作業可能`項目を対象にする。

提案・選択待ち、矛盾、追加対応案の項目は、承認なく実装しない。作業中に新しい判断が必要になった場合は、止めるだけでなく可能な案と影響を示して確認へ戻す。

## 修正後を照合する

ユーザーが検品を求めた場合は、確定した修正指示書と最新成果物を照合する。各項目を次のいずれかで記録する。

- `確認済み`：成果物を実際に確認し、完了条件を満たす根拠がある
- `未対応`：完了条件を満たしていない
- `一部対応`：一部だけ確認できる
- `確認不能`：必要な成果物、表示環境、情報へアクセスできない

確認していない内容を、推測で`確認済み`にしない。最後に未対応・一部対応・確認不能だけを短くまとめる。

## 守る境界

- クライアントの好みや意図を創作しない。ただし、確認済みの制約内でこちらから提案することは避けない。
- 新旧の発言があるだけで、後の発言を常に優先しない。矛盾があれば確認する。
- 見積書にないという理由だけで、追加料金が必要と断定しない。追加対応案と概算を示すことはできる。
- 整理の依頼を、成果物の編集許可や顧客への連絡許可と解釈しない。
- すべてを無理に作業可能へしない。一方で、確認だけを返して思考停止せず、制約から出せる案、探索できる資料、概算できる作業を先に示す。