Audience Judgment Framing
Use this skill before creating or reviewing an artifact that has readers.
The core principle: any artifact with a reader should first define what judgment the reader should form after reading it.
Core Job
Frame the artifact around:
- who will read it
- what decision, judgment, or confidence they need to form
- what evidence they need
- what they may question
- what the artifact must not over-explain or under-prove
This skill prevents outputs that are internally complete but fail their audience.
Use When
Use when preparing or reviewing:
- PRD / requirement docs
- prototype annotations
- embedded PRD left-side documents
- review materials
- project summaries
- weekly/monthly reports
- performance summaries
- PPT or presentation narratives
- leadership updates
- cross-team handoff docs
Do Not Use When
Do not use this skill for:
- purely private notes with no reader
- raw memory capture
- simple file edits or small local changes
- artifacts where the reader and expected judgment are already obvious and low-risk
Reader Types
Common reader frames:
- leadership: wants value, progress, risk, ownership, and next-step confidence
- development: wants implementable rules, boundaries, states, data expectations, and dependencies
- testing: wants verifiable behavior, edge cases, acceptance criteria, and regression risk
- design: wants layout intent, interaction priority, component reuse, and visual constraints
- operation/content: wants process impact, configuration rules, and action ownership
- user/customer-facing reviewer: wants clarity, benefit, trust, and reduced confusion
- future self / future AI: wants continuation pointers, stable decisions, and unresolved items
Working Flow
1. Identify the artifact
Name the artifact and its situation:
- PRD
- PPT
- review doc
- embedded PRD
- project summary
- handoff
- report
2. Identify the primary reader
Choose one primary reader. Secondary readers may exist, but do not let the artifact serve everyone equally.
3. Define the expected judgment
Write one sentence:
After reading this, the reader should conclude that {judgment}.
Examples:
- "this requirement is clear enough for development"
- "this project has produced meaningful business progress"
- "this prototype is ready for review but not freeze"
- "this AI workflow improves continuity, not only writing speed"
4. Identify required evidence
List the evidence needed to support that judgment:
- facts
- metrics
- milestones
- concrete examples
- before/after contrast
- risk handling
- state coverage
- implementation boundaries
- user/data feedback
5. Predict reader objections
Ask:
- what would this reader doubt?
- what would they ask next?
- where might they think the output is vague, inflated, or incomplete?
- what proof would make them more confident?
6. Shape the artifact
Recommend what the artifact should emphasize, reduce, or restructure.
For example:
- leadership materials should convert work detail into impact and confidence
- PRDs should convert product intent into implementable and testable rules
- embedded PRDs should keep explanation on the left and real prototype on the right
- project summaries should convert scattered work into state, result, risk, and next step
Output Format
## Audience judgment frame
- Artifact:
- Primary reader:
- Expected judgment:
- Evidence needed:
- Likely objections:
- Emphasis:
- Reduce / avoid:
- Recommended structure:
Relationship With Other Skills
- Use before
pm-prd-writer when reader confidence matters.
- Use before
pm-embedded-prd when the left document must guide review judgment.
Self-Check
Before finishing, check:
- Did I choose one primary reader?
- Did I define the judgment, not only the topic?
- Did I identify evidence instead of relying on polished wording?
- Did I predict likely objections?
- Did I avoid turning every artifact into a leadership report?
1---2name: audience-judgment-framing3description: 触发:文档/PPT/PRD需先定读者判断;不触发:需求价值→用pm-value-anchor;需求澄清→用pm-requirement-intake;输出:读者判断+证据4---56# Audience Judgment Framing78Use this skill before creating or reviewing an artifact that has readers.910The core principle: any artifact with a reader should first define what judgment the reader should form after reading it.1112## Core Job1314Frame the artifact around:15- who will read it16- what decision, judgment, or confidence they need to form17- what evidence they need18- what they may question19- what the artifact must not over-explain or under-prove2021This skill prevents outputs that are internally complete but fail their audience.2223## Use When2425Use when preparing or reviewing:26- PRD / requirement docs27- prototype annotations28- embedded PRD left-side documents29- review materials30- project summaries31- weekly/monthly reports32- performance summaries33- PPT or presentation narratives34- leadership updates35- cross-team handoff docs3637## Do Not Use When3839Do not use this skill for:40- purely private notes with no reader41- raw memory capture42- simple file edits or small local changes43- artifacts where the reader and expected judgment are already obvious and low-risk4445## Reader Types4647Common reader frames:48- leadership: wants value, progress, risk, ownership, and next-step confidence49- development: wants implementable rules, boundaries, states, data expectations, and dependencies50- testing: wants verifiable behavior, edge cases, acceptance criteria, and regression risk51- design: wants layout intent, interaction priority, component reuse, and visual constraints52- operation/content: wants process impact, configuration rules, and action ownership53- user/customer-facing reviewer: wants clarity, benefit, trust, and reduced confusion54- future self / future AI: wants continuation pointers, stable decisions, and unresolved items5556## Working Flow5758### 1. Identify the artifact5960Name the artifact and its situation:61- PRD62- PPT63- review doc64- embedded PRD65- project summary66- handoff67- report6869### 2. Identify the primary reader7071Choose one primary reader. Secondary readers may exist, but do not let the artifact serve everyone equally.7273### 3. Define the expected judgment7475Write one sentence:7677```text78After reading this, the reader should conclude that {judgment}.79```8081Examples:82- "this requirement is clear enough for development"83- "this project has produced meaningful business progress"84- "this prototype is ready for review but not freeze"85- "this AI workflow improves continuity, not only writing speed"8687### 4. Identify required evidence8889List the evidence needed to support that judgment:90- facts91- metrics92- milestones93- concrete examples94- before/after contrast95- risk handling96- state coverage97- implementation boundaries98- user/data feedback99100### 5. Predict reader objections101102Ask:103- what would this reader doubt?104- what would they ask next?105- where might they think the output is vague, inflated, or incomplete?106- what proof would make them more confident?107108### 6. Shape the artifact109110Recommend what the artifact should emphasize, reduce, or restructure.111112For example:113- leadership materials should convert work detail into impact and confidence114- PRDs should convert product intent into implementable and testable rules115- embedded PRDs should keep explanation on the left and real prototype on the right116- project summaries should convert scattered work into state, result, risk, and next step117118## Output Format119120```md121## Audience judgment frame122- Artifact:123- Primary reader:124- Expected judgment:125- Evidence needed:126- Likely objections:127- Emphasis:128- Reduce / avoid:129- Recommended structure:130```131132## Relationship With Other Skills133134- Use before `pm-prd-writer` when reader confidence matters.135- Use before `pm-embedded-prd` when the left document must guide review judgment.136137## Self-Check138139Before finishing, check:140- Did I choose one primary reader?141- Did I define the judgment, not only the topic?142- Did I identify evidence instead of relying on polished wording?143- Did I predict likely objections?144- Did I avoid turning every artifact into a leadership report?