define-audiences

name	define-audiences
description	Identify who evaluates the user's output, what each audience prioritizes, and where their priorities conflict.

/define-audiences - Audience Definition

When to Use

• After /discover-domain or /map-workflow
• When designing reviewer sub-agents (this feeds directly into /design-sub-agents)
• When domain-input/audiences.md needs completion

Inputs

• Auto-loaded: domain-input/audiences.md (partial, from /discover-domain)
• Auto-loaded: domain-input/domain-workflow.md (for context on what gets produced)

Process

Step 1: Enumerate Audiences

Ask the designer to list every person or system that evaluates the user's output. Push beyond the obvious:

1. Primary audience: Who is the direct recipient? (client, hiring manager, editor, investor)
2. Gatekeepers: Who filters before the primary audience sees it? (recruiter, associate, assistant, algorithm)
3. Technical evaluators: Who checks for correctness or compliance? (ATS, legal review, technical reviewer, peer review)
4. Internal reviewers: Who on the user's side reviews before it goes out? (manager, partner, mentor, accountability partner)

For each audience identified, ask:

Step 2: Deep Profile per Audience

For each audience:

1. What do they see first? In the first 5-10 seconds, what do they look at? (This becomes the "6-second scan" equivalent)
2. What makes them say yes? The 2-3 things that trigger a positive response.
3. What makes them say no? The 2-3 instant disqualifiers.
4. How much time do they spend? Seconds? Minutes? Hours?
5. What's their expertise level? Do they understand the domain deeply, or are they evaluating surface signals?
6. What's their incentive? Why are they evaluating? What do they gain from saying yes vs. no?

Structure into:

## Audience: [Name]

**Role in pipeline:** [which stage they evaluate at]
**Time spent:** [seconds/minutes/hours]
**Expertise:** [deep domain / surface signals / technical only]

### First 5-10 Seconds
They look at: [ordered list]

### Yes Signals
1. [X]
2. [X]
3. [X]

### No Signals (Instant Disqualifiers)
1. [X]
2. [X]
3. [X]

### Scoring Priorities (ranked)
1. [Most important]
2. [Second]
3. [Third]
4. [Least important but still checked]

Step 3: Conflict Map

Ask the designer:

1. Where do audiences disagree? (e.g., gatekeeper wants keywords; primary audience wants insight. Technical reviewer wants completeness; client wants brevity.)
2. When they conflict, who wins? What's the resolution priority?
3. How does the user navigate this? What's the strategy for satisfying conflicting audiences?

Structure into:

## Audience Conflicts

| Conflict | Audience A Wants | Audience B Wants | Resolution |
|----------|-----------------|-----------------|------------|
| [X] | [X] | [X] | [who wins and why] |

Step 4: Map to Sub-Agent Candidates

For each audience, determine if it should become a reviewer sub-agent:

• Yes, make a sub-agent if: The audience has specific, scorable evaluation criteria AND the user's output goes through this audience at a predictable point in the pipeline.
• No sub-agent if: The audience's evaluation is too subjective to score, or the evaluation happens outside the system's scope.

List the sub-agent candidates with their review trigger points:

## Sub-Agent Candidates

| Audience | Sub-Agent Name | Triggers After | Scores On |
|----------|---------------|----------------|-----------|
| [X] | /review-as-[X] | /[skill] | [dimensions] |

Output

Write the complete audience model to domain-input/audiences.md.

Tell the designer:

Audiences defined:
- [N] audiences identified: [list]
- [N] conflicts mapped
- [N] sub-agent candidates identified: [list]

Key insight: [the most important conflict or non-obvious audience behavior]

Next: Run /build-scoring to design evaluation rubrics for these audiences.

Quality Checks

Good audience definition:

• Each audience has specific yes/no signals, not vague preferences
• The "first 5-10 seconds" section describes observable behavior, not assumed behavior
• At least one audience conflict is identified
• Sub-agent candidates have clear trigger points

Bad audience definition:

• Audiences described in generic terms ("they want quality")
• No distinction between what audiences look at first vs. what they evaluate deeply
• No conflicts identified (unrealistic — audiences always conflict somewhere)
• Every audience proposed as a sub-agent (typically 2-4 sub-agents is right, not 7)