| 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:
- It maps to a real audience (not an invented one)
- It triggers after a specific creation skill
- 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
