Incoming Request Advisor — Claude Skill for Analyzing and Deconstructing Incoming Requests

Skill Overview

Incoming Request Advisor (incoming-request-advisor) is a Claude skill designed for product managers to analyze incoming requests. It decodes Slack messages, emails, instructions, or escalation complaints into a structured breakdown, separating the literal request from the underlying goal (Job-to-be-Done). It helps you identify the outcome to achieve before replying, rather than rushing to answer the words on the screen.

Use Cases

1. Analyze urgent executive messages before responding: When a VP asks on Slack, “Can we ship the dashboard redesign in the next iteration?”, use the skill to uncover the underlying goal—“demonstrate responsiveness to the board”—and avoid blindly committing to scope.
2. Handle escalation emails from Customer Success: When you receive an emotionally charged escalation email from a Customer Success leader, first break down its tone, urgency, and political factors before deciding how to respond.
3. Decode ambiguous stakeholder requests: A stakeholder’s instruction may sound like a development task. Use the skill to look beyond the literal request, identify the outcome behind it, and understand why it is needed now.

Core Functions

1. Twelve-part structured breakdown: Classifies the message as an escalation, instruction, feature request, notification, or other type, then successively analyzes the sender, literal request, deeper problem space, required and optional conditions, hard constraints, risks, and recommended next steps. The length automatically scales with the complexity of the message—one-line notifications will not be artificially expanded into twelve lengthy sections.
2. Separates the literal request from the real goal: Clearly distinguishes “what the other person is asking for” from “what they are trying to accomplish,” while separately identifying success criteria (how the other person will judge whether the outcome is good) and required conditions (what the deliverable must contain). These are two dimensions that product managers most often conflate.
3. Inference labeling and follow-up actions: All guesses are labeled as inferences and consolidated into a “Hypotheses to Validate” list. Guesses are never presented as facts. After the analysis, you can directly move on to drafting a reply, generating a meeting agenda, creating a framework for discovery questions, or drafting a counterproposal that protects the outcome.

Frequently Asked Questions

How is this skill different from directly asking AI to draft a reply?

Drafting a reply directly means responding to the literal wording of the message, which can lead to “doing the wrong thing quickly and incorrectly.” This skill first performs a structured breakdown: identifying the sender’s power and interest relationships, separating the literal request from the real goal, and listing risks and gaps before drafting a response. It builds the habit of “finding the outcome before responding”; drafting is an optional step that comes afterward.

What information should I provide? Can it be used when information is incomplete?

Ideally, provide the original message (pasted text, screenshot, file, or PDF), along with the sender’s identity and the surrounding context. It can still be used with only the message itself: the skill will ask questions only when the sender or context genuinely affects the assessment—up to three questions, one at a time—and will then proceed with clearly labeled assumptions. Any context included with the request will be accepted directly and will not be asked for again.

What does the analysis include? Can I use it directly to respond?

The result is a twelve-part Markdown breakdown covering the message classification, sender interpretation, literal request, deeper problem space, tone and subtext, required and optional conditions, hard constraints, gaps and risks, recommended next steps, and a “Hypotheses to Validate” list. All inferences are clearly labeled, allowing you to verify the assumptions first and then choose to draft a reply, create a meeting agenda, develop discovery questions, or draft a counterproposal.

Skill Boundaries

• It is an analysis advisor, not a programmer: it will not turn feature requests into implementation task lists. Instead, it first identifies the desired outcome and why it matters.
• Its reasoning is based on evidence in the message. Any unverifiable elements are labeled as inferences and must be confirmed by the user.