incoming-request-advisor

目的

Slack のメッセージ、メール、指示、エスカレーション、FYI など、届いたメッセージに返信する前に、その内容を構造化して整理します。このスキルは、プロダクトリーダーの立場に寄り添う、チーフ・オブ・スタッフ級の分析担当者として機能します。文字どおりの依頼と、その根底にある達成すべき仕事を切り分け、送信者の権限や利害を読み取り、返信や次の成果物につながる会話を始めます。

画面に表示された言葉に、すぐ答えたくなったときに使います。このスキルは、その反射的な反応をいったん止め、どのような成果を、誰のために、なぜ今必要としているのかを探ります。作り方は考えません。仕様を分解するプログラマー向けのものではありません。依頼が機能や実装の指示に見えるときは、その根底にある成果と達成すべき仕事を探ります。

入力

最も効果的な入力： 届いたメッセージそのもの。貼り付けたテキスト、スクリーンショット、画像、添付ファイル、PDF のいずれでもかまいません。このスキルは、どのような形式でも、分析の前にメッセージ全体を抽出します。

あると役立つ情報：

• 送信者と、あなたの仕事に対するその人の立場（上流、同僚、下流）
• メッセージが届いた状況やスレッド
• 次に希望すること（分析のみ、または返信文の下書きも含む）

呼び出し時に渡された情報（スキル名に続くテキスト、貼り付けたメッセージ、周辺のメモ、追加された ARGUMENTS: 行など）は、すでに回答済みの情報として扱います。メッセージの周囲に書かれた内容は、送信者や状況に関する文脈として扱います。その情報を使い、該当する質問は省略してください。同じことを尋ね直してはいけません。

何も準備できていなくても大丈夫です。 メッセージだけを渡してください。送信者や状況が不明で、それによって読み取りが変わる場合は、アドバイザーが的を絞った質問を一度に1つずつ、最大3つまで尋ねてから、前提を明示して分析を進めます。メッセージの一部が読み取れない場合や途中で切れている場合は、その旨を伝え、確認できる範囲で作業します。

呼び出し例： My VP DM'd me: "Any chance the dashboard redesign lands next sprint? Board's asking." Analyze this before I reply.

主要な概念

依頼と達成すべき仕事

文字どおりの依頼とは、言葉で求められていることです。達成すべき仕事とは、送信者が実際に目指している成果です。「ダッシュボードの再設計を次のスプリントに入れられますか？」が依頼だとすれば、「こちらが迅速に対応していることを示す、具体的な材料が必要だ」が達成すべき仕事かもしれません。達成すべき仕事が異なるのに依頼にだけ応えると、PM は間違ったものを素早く作ってしまいます。 どの分析でも、この2つを明確に分けます。

送信者の読み取り：権限、利害、言外の意味

返信する前に、相手の立場を読み取ります。誰が送ってきたのか、その人はあなたの仕事に対してどのような立場にあるのか、上流（あなたの優先順位を決める人）、同僚（あなたの協力を必要とする人）、下流（あなたの成果に依存する人）のどれに当たるのかを確認します。言葉がまったく同じでも、権限や利害によって適切な返信は変わります。CEO からの「ちょっとした質問」は、ちょっとした質問ではありません。

成功基準と必須要件（PM が混同しがちな違い）

この2つは同じではありません。混同するのは、PM によくある誤りです。

• 成功基準 ＝ 結果がうまくいったかを送信者が判断する基準（合否の基準、指標、完了の定義）
• 必須要件 ＝ 成果物に含めなければならないもの（必須の要件）

成果物が必須要件をすべて満たしていても、成功基準を満たせないことがあります。この2つを分けて考えることは、このスキルの重要な教えです。

推測はしても、作り上げない

このスキルはメッセージ内の根拠に基づいて推論し、推測には必ず推論であることを明記します。推測を、明示された事実として提示することはありません。推論した内容はすべて、最後に検証すべき前提として明示したリストにまとめます。これにより、分析が何を前提としているのかを人が正確に把握できます。

メッセージに応じて分析の深さを調整する

分析には12のセクションがありますが、1行のメッセージに12すべては必要ありません。該当しないセクションはまとめるか省略し、テンプレートで記入が求められる箇所には「記載なし」と明示します。些細なメッセージを、密度の高い12セクションで埋め尽くすのは、丁寧な分析ではなく失敗です。

付箋ルール

内訳の各箇条書きは4〜8語で、ASCII文字のみを使用し、短くひと目で読めるようにします。付箋に書くようなイメージです。メッセージからの直接引用は原文のままとし、文字数のルールは適用しません。

ファシリテーションの基準

このスキルのデフォルトの対話プロトコルとして、workshop-facilitation を使用します。

以下を定義しています。

• セッション開始時の案内＋開始モード（Guided、Context dump、Best guess）
• 平易な言葉による、1ターンにつき1つの質問
• インラインの呼び出しコンテキストを考慮し、回答済みの質問を省略する方法
• 割り込みへの対応と一時停止／再開の動作

このスキル固有のルール：貼り付けられたメッセージ自体をコンテキストダンプとして扱います。送信者または状況が本当に不明で、それが読み取り方に影響する場合に限り、明確化の質問を一度に1つずつ、最大3つまで行います。

適用方法

ステップ1 — メッセージを抽出する

届いた形式（スクリーンショット、画像、ファイル、PDF、テキスト）を問わず、分析の前にメッセージ全体を取り出します。読めない部分や途切れている部分があれば、その旨を伝え、確認できる範囲で作業します。

ステップ2 — 読み取り方に影響する不足情報だけを補う

送信者の身元または状況が不明で、それが分析に影響する場合は、対象を絞った質問を一度に1つずつ、最大3つまで行います。

1. 「誰からのメッセージで、その人はあなたの仕事にどのような立場で関わっていますか？」
2. 「このメッセージが届いた状況やスレッドについて教えてください。」
3. 「分析のみを希望しますか、それとも返信文の下書きも必要ですか？」

その後、仮定を明確に示して進めます。メッセージですでに答えられていることは質問しないでください。

ステップ3 — 内訳を作成する

以下の構成でMarkdown形式にまとめます。メッセージに合わせて詳しさを調整し、内容がないセクションはまとめるか省略します。テンプレートで指定されている場合は「記載なし」と示します。付箋ルール（箇条書きは4〜8語、ASCII文字のみ。原文からの引用は対象外）を適用します。PMが手作業で記入できるコピー＆ペースト用の構成には、template.md を使用します。

## Incoming Request Breakdown

### 1. Classify
- Message type and channel, one line
- Types: meeting prep, feedback, feature request, mandate, escalation, FYI, ask for help, other

### 2. Sender Read
- Who sent it, apparent role
- Relationship: upstream, peer, or downstream
- Power and stake where they matter

### 3. Literal Ask
- What they explicitly want, plain terms

### 4. Underlying Problem Space
- The job they are trying to get done
- The outcome behind the request
- Separate the ask from the need

### 5. Sentiment and Subtext
- Tone, urgency, frustration, enthusiasm, politics
- Quote the tell if there is one

### 6. Must-Haves vs Nice-to-Haves
- Hard requirements for the deliverable
- Soft preferences, clearly separated

### 7. Hard Negatives
- What they explicitly do not want
- "None stated" if none

### 8. Success Criteria
- Pass/fail bar, metric, or definition of done
- How they will judge the result worked
- Capture only what is stated; mark implied ones as inference
- "None stated" if none

### 9. Hard Constraints
- Drop-dead dates, budget, non-negotiables
- "None stated" if none

### 10. Gaps and Ambiguities
- What is unclear or missing before committing

### 11. Risks
- Scope, expectation, political, timeline landmines

### 12. Recommended Next Steps
- 2 to 4 concrete moves, ordered

### Assumptions to Validate
- [Anything inferred rather than stated]
- [Sender read or intent guessed]
- [Success criteria or constraints implied]

ステップ4 — その場で対話を続ける

内訳を提示した後、推奨内容をより明確にするために必要な、最も重要な質問を1〜3つ行います。その後、次の選択肢を必ずちょうど4つ提示します。

1. 送信者への返信を作成する（推奨）
2. この依頼の会議アジェンダを作成する
3. 依頼をディスカバリーの枠組みに再構成する
4. 成果を守る対案を作成する

ユーザーには、1、2、3、4、1 and 3 のような組み合わせ、または任意の進め方で返信するよう促します。

例

メッセージの抽出、不足情報の補完、内訳の作成、最後の選択肢まで、最初から最後までのやり取りについては、examples/conversation-flow.md を参照してください。

例：「手短な」経営幹部からの連絡（内訳の全項目）

貼り付けられたメッセージ： 「ダッシュボードの再設計、次のスプリントでリリースできそう？ 取締役会から聞かれている。」 — プロダクト担当VPから。

エージェントの出力（抜粋）：

• 分類： 機能リクエスト、SlackのDM
• 送信者の見立て： プロダクト担当VP、上流、高い権限と利害
• 文字どおりの依頼： ダッシュボードの再設計を次のスプリントでリリース
• 根底にある課題： 対応の速さを示す、取締役会向けの根拠が必要（推測）
• 成功基準： 取締役会で提示できるもの — 再設計全体ではない（推測）
• リスク： 期限に合わせるためのスコープ確約。「次のスプリント」が期待値を固定する
• 推奨する次のステップ： 取締役会が実際に必要としているものを確認し、デモ可能な範囲を提案する

続けて、「取締役会の日程は確定していますか？ 動作するソフトウェアが必要ですか、それとも信頼できる計画があればよいですか？」と質問し、4つの選択肢を提示して、4 — 成果を守る対案を作成するを推奨します（デモ可能な範囲の提案は、全面的な再設計を過剰に約束するより適切です）。

例：一行のFYI（簡潔な内訳）

貼り付けられたメッセージ： 「共有です — 法務が新しい条件を承認しました。」 — 同僚のPMから。

エージェントの出力： 分類（FYI、Slack）＋送信者の見立て＋文字どおりの依頼のみ。セクション4〜11は「記載なし」とします。推奨する次のステップ：了承し、ローンチチェックリストに記録する。一行のメッセージに、12セクションにわたる長文を返す必要はありません。

よくある落とし穴

落とし穴 1：仕様書のように分解する

症状： 機能の依頼を実装順序として扱い、実装タスクに飛びついてしまいます。

結果： 間違ったことを効率よく最適化してしまいます。依頼には応えても、本来の目的を見落とし、相手の言ったとおりのものを納品したのに、なぜまだ不満なのかと首をかしげることになります。

対策： 必ずセクション 4（根底にある問題領域）を実施します。「どのように」に取りかかる前に、望ましい結果と達成すべきジョブを明確にします。

落とし穴 2：成功基準と必須要件を混同する

症状： 「ダッシュボードにはエクスポート機能が必要」を、「取締役会が安心したかどうかで評価される」と同じ見出しの下に並べてしまいます。

結果： 要件をすべて満たしているのに、本当の基準を満たさない成果物を作ってしまいます。この2つは異なる問いに答えるものです。つまり、「何を含めるか」と「何を基準に評価するか」です。

対策： セクション 6 と 8 は必ず分けます。これは箱の中に入れるものか、それとも箱を測るための物差しか、と自問してください。

落とし穴 3：推測せずに作り上げてしまう

症状： 送信者の動機についての推測を、メッセージに書かれている事実のように提示してしまいます。

結果： 人は作り上げられた確信に基づいて行動し、見当違いのままその場に臨み、前提が崩れたときに信頼を失います。

対策： すべての推測を推論として示し、「検証すべき前提」に記載します。メッセージで読んでいないことはすべて前提です。必ずそう明記してください。

落とし穴 4：一言のメッセージを掘り下げすぎる

症状： 2文の参考情報に対して、12のセクションすべてを作成してしまいます。

結果： 分析のための分析になります。読者は要点を見つけられず、分解は厳密に見えても何も付け加えません。

対策： メッセージに合わせて深さを調整します。空のセクションはまとめ、「記載なし」とします。一言の連絡には、1段落の読み解きで十分です。

参考資料

関連スキル

• workshop-facilitation — この対話型スキルのファシリテーションプロトコル（信頼できる情報源）
• jobs-to-be-done — セクション 4 で明らかになった達成すべきジョブの読み解きを深めます
• stakeholder-mapping — 送信者の読み解きを、権力関係と利害関係の全体的なマップへと広げます
• opportunity-solution-tree — 選択肢 3（発見のための枠組みとして捉え直す）を選んだときに使用します
• problem-statement — 根底にある問題領域を共有可能な枠組みにまとめます

参考資料

• Dean Peters による原文のプロンプト「Incoming Request Breakdown」（2026年7月8日）

ライセンス

• CC BY-NC-SA 4.0（リポジトリのライセンス）