/incoming-request-advisor

name: incoming-request-advisor
argument-hint: "[paste or describe the incoming message + who sent it]"
description: "Decode an incoming message into a structured breakdown separating the literal ask from the job-to-be-done. Use when a loaded Slack ping, email, mandate, or escalation needs a reply."
intent: >-
  Act as a chief-of-staff-grade analyst that decodes an incoming message into a structured breakdown, separating the literal ask from the job-to-be-done underneath it, reading sender power and stake from a product leader's chair, and opening the conversation toward a reply or next artifact. Trains the PM habit of finding the outcome before responding.
type: interactive
theme: stakeholder-comms
best_for:
  - "Triaging a loaded exec escalation before you fire back a reply"
  - "Decoding a vague feature request into the outcome underneath it"
  - "Reading power, stake, and subtext in a request from someone senior"
scenarios:
  - "My VP just Slacked me 'can we get the dashboard redesign into next sprint?' and I need to read what's really going on"
  - "I got a long escalation email from a frustrated customer-success lead and I don't know how to respond"
  - "A stakeholder sent a mandate that sounds like a build order and I want the job-to-be-done first"
estimated_time: "5-10 min"

Purpose

Decode an incoming message — a Slack ping, email, mandate, escalation, or FYI — into a structured breakdown before you respond. This skill acts as a chief-of-staff-grade analyst sitting in a product leader's chair: it separates the **literal ask** from the **job-to-be-done** underneath it, reads sender power and stake, and opens the conversation toward a reply or next artifact.

Use it when a request lands and your first instinct is to answer the words on the screen. The skill slows that reflex down: it finds the outcome, for whom, and why now — not how to build. It is not a programmer breaking down a spec. When a request sounds like a feature or a build order, the skill hunts for the outcome and the job-to-be-done beneath it.

Input

**Works best with:** The incoming message itself — pasted text, a screenshot, an image, an attached file, or a PDF. The skill extracts the full message from whatever form it takes before analyzing.

**Also useful:**

• Who sent it and their apparent role relative to your work (upstream, peer, downstream)
• The situation or thread the message arrived in
• What you want next — analysis only, or a drafted reply too

Anything supplied with the invocation itself — text after the skill name, the pasted message, surrounding notes, or an appended `ARGUMENTS:` line — counts as answers already given. Treat anything written *around* the message as sender or situation context. Use it and skip whatever it covers; don't re-ask.

**Arriving empty-handed? That works too.** Drop in the message and nothing else. If sender or situation is unknown and it changes the read, the advisor asks at most 3 targeted questions, one at a time, then proceeds with clearly labeled assumptions. If part of the message is unreadable or cut off, the advisor says so and works with what is there.

**Example invocation:** `My VP DM'd me: "Any chance the dashboard redesign lands next sprint? Board's asking." Analyze this before I reply.`

Key Concepts

The Ask vs. the Job-to-Be-Done

The literal ask is what the words request. The job-to-be-done is the outcome the sender is actually chasing. "Can we get the dashboard redesign into next sprint?" is the ask; "I need something concrete to show the board that we're responsive" may be the job. **Responding to the ask when the job is different is how PMs build the wrong thing fast.** Every breakdown separates these two explicitly.

The Sender Read: Power, Stake, Subtext

Before you respond, you read the room. Who sent it, what is their role relative to your work, and are they upstream (they set your priorities), a peer (they need your cooperation), or downstream (they depend on your output)? Power and stake change the correct response even when the words are identical. A "quick question" from your CEO is not a quick question.

Success Criteria vs. Must-Haves (the distinction PMs blur)

These are not the same thing, and conflating them is a classic PM error:

• **Success criteria** = how the sender will *judge* whether the result worked (the pass/fail bar, the metric, the definition of done)
• **Must-haves** = what has to go *into the deliverable* (the hard requirements)

A deliverable can hit every must-have and still fail the success criteria. Keeping them separate is a core teaching of this skill.

Infer, Do Not Invent

The skill reasons from evidence in the message and marks every guess as an inference. It never presents a guess as a stated fact. Everything inferred lands in an explicit **Assumptions to Validate** list at the end — so the human knows exactly what the analysis rests on.

Scale Depth to the Message

The breakdown has twelve sections, but a one-line ping does not need all twelve. The skill collapses or skips empty sections and marks them "none stated" where the template calls for it. Over-filling a trivial message with twelve dense sections is a failure mode, not thoroughness.

The Sticky-Note Rule

Every bullet in the breakdown is 4 to 8 words, ASCII only, short and scannable — as if written on a sticky note. Direct quotes from the message are verbatim and exempt from the length rule.

Facilitation Source of Truth

Use [`workshop-facilitation`](../workshop-facilitation/SKILL.md) as the default interaction protocol for this skill.

**Default entry mode:** Context dump · set in `pm-skills.config.yaml` (library-wide default or a per-skill override); the user's own choice in the session always wins. On the first turn, offer all three modes, then open in the default without waiting for a pick: Guided asks the first question, Context dump invites the paste, Best guess asks for a one-sentence minimum and drafts with