design-sub-agents

name	design-sub-agents
description	Design reviewer personas — adversarial quality gates with different priorities than the creation skills they review.

/design-sub-agents - Reviewer Persona Design

When to Use

• After /define-audiences and /design-skills
• When domain-input/audiences.md has sub-agent candidates identified
• When designing the sub-agents/ directory for the target OS

Inputs

• Auto-loaded: domain-input/audiences.md (audience profiles and sub-agent candidates)
• Auto-loaded: domain-input/scoring-rubrics.md (evaluation dimensions)
• Auto-loaded: output/designs/skill-designs.md (which skills need reviewers)
• Auto-loaded: reference/sub-agent-anatomy.md (structural template)

Process

Step 1: Confirm Sub-Agent List

From audiences.md, review the sub-agent candidates. Typically 2-4 sub-agents is right:

• Too few (0-1): The OS has no quality gates. Generation errors will reach the user unchecked.
• Right (2-4): Each major output type has a reviewer with a distinct lens.
• Too many (5+): Over-reviewing slows the system. Merge sub-agents that share a similar evaluation lens.

For each confirmed sub-agent, verify:

1. It maps to a real audience (not an invented one)
2. It triggers after a specific creation skill
3. Its evaluation priorities DIFFER from the creation skill's priorities

Step 2: Priority Conflict Verification

This is the most important step. For each sub-agent, confirm the adversarial relationship:

## Adversarial Check: /review-as-[X]

**Reviews output of:** /[creation skill]
**Creation skill prioritizes:** [what the skill optimizes for]
**Reviewer prioritizes:** [what this audience actually cares about]
**Conflict:** [where these priorities diverge]
**Why this matters:** [what the reviewer catches that the skill misses]

If a reviewer's priorities align with the creation skill, it's not adding value. Either find the real conflict or merge it with another reviewer.

Step 3: Persona Specification

For each sub-agent, write the full persona using this template:

# /review-as-[name] - [One-Line Description]

## Role
You are a [specific persona with context]. [2-3 sentences establishing the persona's experience, constraints, and mindset. Make it vivid — "You receive 200+ proposals per week" not "You review proposals."]

## When to Use
- After /[creation skill] (auto-triggered)
- When the user wants a reality check on [output type]
- When [metric] is low and the user needs to understand why

**Invocation:** This sub-agent is auto-triggered by /[skill]. It can also be invoked directly as /review-as-[name].

## Inputs
- The [output] to review
- The [target/context] (if available)
- The user's [relevant context file]

## Process

### Step 1: [First-Pass Scan]
Simulate the audience's actual behavior. [Describe what they look at in the first N seconds. Be specific about what they see and what they miss.]

### Step 2: Score ([N] Dimensions)

**[Dimension 1] (1-10)**
- 9-10: [specific description]
- 7-8: [specific description]
- 5-6: [specific description]
- 3-4: [specific description]
- 1-2: [specific description]

**[Dimension 2] (1-10)**
[same structure]

### Step 3: Flag Issues
Check for these specific problems:
- [Issue category 1]: [what to look for]
- [Issue category 2]: [what to look for]

### Step 4: Suggest Specific Changes
For each issue: what it is, where it is, exactly how to fix it. Prioritize by impact.

## Output Format
[Structured template for the review output]

## Quality Checks
A good review:
- [criterion]
- [criterion]

A bad review:
- [criterion]
- [criterion]

Step 4: Trigger Integration

For each sub-agent, confirm the trigger chain:

## Trigger Map

| Sub-Agent | Triggered After | Auto-Corrects? | Updates State? |
|-----------|----------------|----------------|----------------|
| /review-as-[X] | /[skill] | Yes — rewrite flagged issues | No |
| /review-as-[Y] | /[skill] | No — flags only | Yes — updates [file] |

Decide for each: does the sub-agent auto-correct, or just flag? Auto-correction is appropriate when the fix is mechanical (formatting, keyword density). Flagging is appropriate when the fix requires user judgment (content choices, tone).

Output

Write the complete sub-agent designs to output/designs/sub-agent-designs.md.

Tell the designer:

Sub-agents designed:
- [N] reviewer personas: [list with one-line descriptions]
- Adversarial checks: all [N] confirmed — each reviewer has different priorities than its creation skill
- Auto-correction: [N] auto-correct, [N] flag-only

Trigger chain: /[skill] → /review-as-[X] → [auto-correct / flag] → user review

Next: Run /design-loops to design the compounding feedback loops.

Quality Checks

Good sub-agent design:

• Each sub-agent has a vivid persona, not a generic "reviewer"
• Priority conflicts are explicit — you can see what the reviewer catches that the skill misses
• Scoring dimensions are specific to this reviewer's lens
• Issue flagging includes "where it is" and "how to fix it," not just "what's wrong"
• 2-4 sub-agents total

Bad sub-agent design:

• Sub-agent is a rubber stamp ("looks good, 9/10")
• Priorities align with the creation skill (no adversarial value)
• Scoring is vague ("quality: 7/10" with no dimension breakdown)
• Too many sub-agents (5+) creating review fatigue
• No trigger integration — sub-agent exists but isn't wired into any skill