メニュー
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.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
SOC 職業分類に基づく
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/TuYv/ccpm --skill incoming-request-advisorコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SKILL.md を表示中
Use when auditing a paid ad account for incremental contribution, wasted spend, or measurement integrity before scaling; runs a typed 20-item ROAS profile with verified vetoes and a SHIP/FIX/BLOCK/UNDECIDED gate on own exported data. Not for campaign structure design — use campaign-architect; not for creative production — use ad-creative-builder. 付费广告账户审计/ROAS评分
Use when the user asks to "write ad copy", "generate RSA headlines", or "build ad creative at volume"; produces ad units — RSA headlines/descriptions, hooks, and an angle matrix — message-matched to the destination landing page. Not for scoring an ad account — use ad-account-auditor; not for the post-click page — use landing-optimizer; not for organic articles — use content-writer. 广告创意/广告文案/RSA标题
Use when the user asks to "design an A/B test", "set up a creative/landing test", "run an incrementality test", or "is this result statistically and practically material?"; produces a hypothesis, variant matrix, sample-size/duration/power plan, and a documented effect/uncertainty read from own exported results. It applies only a precommitted owner-approved action rule; the statistical helper never chooses a business action. Not for producing variants — use ad-creative-builder; not for reading back one shipped change — use paid-measurement-loop. 广告AB测试设计/实验设计/显著性判定/增效测试
| 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 |
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.
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:
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.
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.
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.
These are not the same thing, and conflating them is a classic PM error:
A deliverable can hit every must-have and still fail the success criteria. Keeping them separate is a core teaching of this skill.
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.
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.
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.
Use workshop-facilitation as the default interaction protocol for this skill.
It defines:
For this skill specifically: the pasted message is the context dump. Ask clarifying questions only when sender or situation is genuinely unknown and it changes the read — at most 3, one at a time.
Pull the full message from whatever form it arrives in (screenshot, image, file, PDF, or text) before analyzing. If any part is unreadable or cut off, say so and work with what you have.
If sender identity or situation is unknown and it would change the analysis, ask at most 3 targeted questions, one at a time:
Then proceed with clearly labeled assumptions. Do not ask questions the message already answers.
Render in Markdown using the structure below. Scale depth to the message: collapse or skip any empty section; mark it "none stated" where the template calls for it. Apply the Sticky-Note Rule (4–8 word bullets, ASCII only; verbatim quotes exempt). Use template.md for the copy/paste fill-in structure a PM can work through by hand.
## 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]
After rendering, ask the 1 to 3 sharpest questions you need to sharpen the recommendation, then offer exactly 4 next options:
Ask the user to reply with 1, 2, 3, 4, a combination like 1 and 3, or a custom path.
See examples/conversation-flow.md for a full end-to-end interaction, including message extraction, gap-filling, the rendered breakdown, and the closing options.
Message pasted: "Any chance the dashboard redesign lands next sprint? Board's asking." — from the VP of Product.
Agent output (abridged):
Then: "Is the board meeting date fixed? Do they need working software or a credible plan?" → offers the 4 options, recommends 4 — counter-proposal that protects the outcome (a demoable slice beats an over-committed full redesign).
Message pasted: "Heads up — legal signed off on the new terms." — from a peer PM.
Agent output: Classify (FYI, Slack) + Sender Read + Literal Ask only. Sections 4–11 marked "none stated." Recommended Next Step: acknowledge, file for the launch checklist. No twelve-section wall for a one-liner.
Symptom: Treating a feature-shaped request as a build order and jumping to implementation tasks.
Consequence: You optimize the wrong thing efficiently. You solve the ask and miss the job, then wonder why the sender is still unhappy after you delivered exactly what they said.
Fix: Always run Section 4 (Underlying Problem Space). Name the outcome and the job-to-be-done before touching "how."
Symptom: Listing "the dashboard must have export" under the same heading as "they'll judge this by whether the board is reassured."
Consequence: You build a deliverable that ticks every requirement and still fails the real bar. The two answer different questions — what goes in vs. how they judge it.
Fix: Keep Sections 6 and 8 strictly separate. Ask yourself: is this a thing in the box, or the ruler they measure the box with?
Symptom: Presenting a guess about the sender's motive as if the message stated it.
Consequence: The human acts on fabricated certainty, walks into the room wrong, and loses trust when the assumption cracks.
Fix: Mark every guess as an inference and surface it in Assumptions to Validate. If you didn't read it in the message, it's an assumption — label it.
Symptom: Rendering all twelve sections for a two-sentence FYI.
Consequence: Analysis theater. The reader can't find the signal, and the breakdown looks rigorous while adding nothing.
Fix: Scale depth to the message. Collapse empty sections; mark "none stated." A one-line ping earns a one-paragraph read.
workshop-facilitation — Facilitation protocol for this interactive skill (source of truth)jobs-to-be-done — Deepen the job-to-be-done read surfaced in Section 4stakeholder-mapping — Extend the Sender Read into a full power/stake mapopportunity-solution-tree — Use when option 3 (reframe as discovery framing) is chosenproblem-statement — Turn the Underlying Problem Space into a shareable framing