---
name: multi-pov
description: "Use when analyzing artifacts through multiple expert POVs."
version: 1.0.0
author: Hermes Agent
license: MIT
metadata:
  hermes:
    tags: [multi-perspective, analysis, synthesis, audit, subagent, impact-effort, blind-spots, recommendations]
    related_skills: [multi-pov-decision-framework, landing-page-audit, subagent-driven-development, research-agent]
---

# Multi-POV Analysis

## Overview

Multi-POV eliminates blind spots by forcing analysis through multiple independent senior-expert perspectives before any recommendation is made. Each POV sees what the others can't. The orchestrator (acting as Senior Project Manager) synthesizes all perspectives into a single impact-vs-effort prioritized document.

The number of POVs is dynamic — a simple hero section might need 3 perspectives; a full product launch might need 12. The skill selects POVs based on what the subject actually requires, not a fixed roster.

**Key distinction from `multi-pov-decision-framework`:** That skill evaluates *binary decisions* (buy/build/pass) with go/no-go gates. This skill *analyzes and improves artifacts* with impact-vs-effort prioritization. Use the decision framework when choosing between options; use this skill when improving something that exists or is being designed.

## When to Use

- Analyzing or improving a landing page, website, or web app
- Reviewing a product spec, PRD, or feature design before implementation
- Evaluating a marketing strategy, campaign, or content plan
- Auditing a business plan or pitch deck
- Improving a user onboarding flow or customer journey
- Reviewing code architecture or technical documentation
- Any task where "it depends on who you ask" is the honest answer

**Don't use for:**
- Binary decisions (buy/build/pass) → use `multi-pov-decision-framework`
- Simple implementation tasks with one obvious approach → just do it
- Debugging → use `systematic-debugging`

## Core Principle

> A single perspective is a single blind spot. Multiple independent perspectives, synthesized honestly, produce recommendations that no single expert could produce alone.

The PM/Synthesizer role is ALWAYS present and ALWAYS runs last. Every other POV is selected based on what the subject demands.

## Workflow

### Phase 1: Frame the Subject

Define precisely what is being analyzed and what success looks like.

Collect or verify access to:
- The artifact itself (URL, repo path, document, description)
- Context the POVs need (brand guidelines, target audience, metrics, constraints)
- Any known problems or goals the user has stated

**Gate:** You can state the subject in one sentence AND the artifact is accessible (URL loads, repo cloned, document read, or description is detailed enough to analyze).

### Phase 2: Select POVs

Choose perspectives that collectively cover every relevant domain for this subject. The right number is however many it takes to cover the surface — not fewer for speed, not more for completeness theater.

**Minimum: 3 POVs** (below this, you don't have multi-perspective analysis).
**No maximum.** If the subject demands 12 perspectives, use 12.

One POV is always the **Synthesizer (Senior Project Manager)** — this is the orchestrator itself, not a subagent. The PM synthesizes after all other POVs complete.

For every other POV, ask: *What domain does this subject touch?* Each domain gets a POV. See `references/pov-roster.md` for a comprehensive catalog.

Selection logic:
1. List every domain the subject touches.
2. For each domain, assign the most relevant senior expert.
3. Check cross-cutting concerns (security, accessibility, legal, data) — add POVs.
4. Merge any POVs with >70% focus overlap.
5. The PM is always last and always the orchestrator.

**Gate:** Every domain the subject touches has at least one POV assigned. No two POVs overlap >70% in focus. PM role assigned.

### Phase 3: Dispatch (Parallel Subagents)

Spawn each non-PM POV as a subagent via `delegate_task`. Each subagent receives:

1. **Role identity** — specific senior title + years of experience + their core question
2. **The subject** — what they're analyzing, with full context (screenshots, code, metrics, user description)
3. **Focus areas** — 3-6 specific domains within their expertise to examine
4. **The output contract** — the structured format they must return (see below)
5. **Blind-spot mandate** — they must explicitly state what they CANNOT assess

**Batching:** `delegate_task` runs up to 3 subagents concurrently per batch. For >3 POVs, dispatch in sequential batches. All batches must complete before synthesis.

**Independence is non-negotiable.** Each subagent must NOT know what other POVs are analyzing. They analyze from their own expertise only. Do not share other POVs' findings during dispatch.

**Gate:** Every non-PM POV has returned a complete analysis following the output contract. No subagent returned a partial or generic response.

### Phase 4: Quality-Check

Read every POV output. Verify:

- **Substance** — if a POV returned advice that could apply to any subject, re-dispatch with sharper context.
- **Evidence** — every finding needs supporting evidence (data, code reference, principle, heuristic). Flag unsupported claims.
- **Blind-spot honesty** — each POV must state what they CANNOT assess. If they claim universal expertise, their analysis is suspect.
- **Contradictions** — note where POVs disagree. These are the most valuable data points for synthesis.

Re-dispatch any POV whose output is too thin to be useful.

**Gate:** Every POV output passes quality checks. Thin outputs have been re-dispatched and replaced.

### Phase 5: Synthesize (Impact × Effort)

The orchestrator takes the PM/Synthesizer role. Do NOT dispatch this as a subagent — synthesis requires judgment that benefits from seeing all POVs simultaneously.

Produce the synthesis document with these sections:

1. **Executive Summary** — 3-5 sentences covering the most important findings and the top 3 recommendations.
2. **Consensus Zone** — where ≥3 POVs agree independently. These are bedrock findings.
3. **Constructive Tension** — where POVs conflict. State both sides and the resolution.
4. **Hidden Risks** — findings visible to only 1-2 POVs. These are the blind spots the process was designed to surface.
5. **Impact × Effort Matrix** — every recommendation scored on two axes, sorted into priority quadrants.
6. **Sequenced Action Plan** — P0 quick wins first, then P1 major projects, etc.

**Impact (1-5):** How much does this move the subject's stated goal?
**Effort (1-5):** How much work/resources to implement?

| Priority | Impact | Effort | Action |
|----------|--------|--------|--------|
| **P0 — Quick Wins** | ≥4 | ≤2 | Do immediately |
| **P1 — Major Projects** | ≥4 | ≥3 | Plan and schedule |
| **P2 — Fill-ins** | 2-3 | ≤2 | Do when time allows |
| **P3 — Thankless** | ≤2 | ≥3 | Skip unless mandatory |

**Gate:** Synthesis contains all 6 sections. Every recommendation has Impact, Effort, and Priority. At least one hidden risk surfaced.

### Phase 6: Deliver

Present the synthesis document to the user. Flag recommendations that touch brand voice, copy, or visual identity for explicit approval before any implementation.

If the user wants implementation, hand off to the appropriate skill (`landing-page-audit` for web, `coding-agent` for code, etc.). Multi-POV produces the analysis; other skills execute it.

**Gate:** User has received the document. Brand-sensitive changes are flagged for approval.

## POV Output Contract

Every non-PM POV subagent must return analysis in this structure:

```
## [Role Name] — Analysis

### Assessment
[2-4 paragraphs of substantive analysis from this expert's perspective.
Specific to THIS subject — not generic advice.]

### Findings
| # | Finding | Severity | Evidence |
|---|---------|----------|----------|
| 1 | [Specific issue or opportunity] | Critical/High/Medium/Low | [Data, code ref, principle] |

### Recommendations
| Recommendation | Impact (1-5) | Effort (1-5) | Rationale |
|----------------|-------------|-------------|-----------|
| [Specific, actionable change] | [score] | [score] | [Why this matters from this POV] |

### Blind Spots
[What this perspective CANNOT assess — domains outside this role's expertise.]

### Non-Negotiables
[Any hard constraints: "Must fix before launch" / "Legal requirement" / etc.]
```

## POV Selection Guide

The right POVs depend entirely on the subject:

1. **What domains does this subject touch?** List them.
2. **For each domain, who is the senior expert?** That's a POV.
3. **Cross-cutting concerns?** (security, accessibility, legal, data) Add a POV for each.
4. **Any domain under-represented?** Add more POVs there.
5. **Any POVs redundant?** (<70% overlap required) Merge them.

For a comprehensive catalog of POVs by domain, see `references/pov-roster.md`.

**Typical POV counts by complexity:**
- Simple (hero section, single component): 3-4 POVs
- Medium (full landing page, feature spec): 6-8 POVs
- Complex (product launch, full strategy): 10-15 POVs

## Behavioral Rules

- **Independence first.** POVs must not see each other's analysis during dispatch. Cross-pollination happens only in synthesis.
- **Evidence over opinion.** Every finding needs supporting evidence — a contrast ratio, a code reference, a heuristic, a data point. "Feels wrong" is not evidence.
- **The PM synthesizes, doesn't analyze.** The orchestrator's synthesis role is to integrate, prioritize, and resolve tensions — NOT to add new findings. New findings require a new POV dispatch.
- **No implementation without approval.** The multi-POV skill produces recommendations. Implementation requires user sign-off, especially for brand-sensitive changes.
- **Named frameworks welcome.** When a POV applies a recognized framework (Cialdini's principles, Fogg Behavior Model, WCAG, PAS, AIDA, Nielsen's heuristics), name it explicitly. Frameworks anchor analysis to established knowledge.
- **Re-dispatch thin outputs.** If a POV returns generic advice, re-dispatch with more specific context. Do not accept "be more responsive" when you need "add a max-width: 768px media query at line 47."

## Epistemology Rules

- Tag every claim: **verified** (data/code/source confirmed), **single-source** (one POV's assessment), **inferred** (reasonable deduction), or **uncertain** (needs validation).
- Distinguish what was *observed* (from the actual artifact) from what was *assumed* (from general expertise).
- If POVs contradict each other, surface the contradiction explicitly. Do NOT smooth it over — tension is data.
- A recommendation counts as "consensus" only when ≥3 POVs independently arrived at it.

## Output Formatting

- Prose for analysis paragraphs. Tables for structured data (findings, recommendations, matrices).
- Ban AI-isms: "Furthermore," "Moreover," "It's worth noting," "In today's landscape," "Let's dive into."
- Match depth to subject complexity. A 3-POV analysis doesn't need a 20-page document.
- Executive summary first, then the matrix, then detail. Make it scannable.
- Use the user's communication style (emoji conventions, box-drawing trees) if established.

## Common Pitfalls

| Pitfall | Symptom | Fix |
|---------|---------|-----|
| **POV echo chamber** | All POVs say the same thing | POVs overlap >70%. Re-select with more diverse domains. |
| **Generic analysis** | Findings apply to any subject | Context wasn't specific enough. Re-dispatch with actual screenshots/code/data. |
| **Consensus theater** | No tensions or conflicts surfaced | Add a designated red-team POV (Risk Manager / Devil's Advocate). |
| **PM overreach** | Synthesizer adds new findings not from any POV | PM's job is synthesis only. New findings require a new POV dispatch. |
| **POV under-dispatch** | Critical domain missed because "it's obvious" | If a domain touches the subject, it gets a POV. |
| **Analysis paralysis** | 15 POVs for a simple task | Right-size: 3-4 for simple, 6-8 for medium, 10-15 for complex. |
| **Evidence laundering** | Marketing claims or assumptions treated as facts | Tag all claims with evidence quality. Verify where possible. |
| **Context starvation** | Subagents produce shallow analysis because they lack data | Pre-collect all available data (screenshots, code, metrics) and include in every dispatch. |

## Verification Checklist

- [ ] Subject precisely defined and accessible
- [ ] ≥3 non-PM POVs dispatched, each with distinct domain focus
- [ ] Every POV returned complete output following the contract
- [ ] Each POV states its blind spots explicitly
- [ ] All findings tagged with evidence quality
- [ ] Synthesis includes: Executive Summary, Consensus Zone, Constructive Tension, Hidden Risks, Impact × Effort Matrix, Sequenced Action Plan
- [ ] Every recommendation has Impact score, Effort score, and Priority
- [ ] At least one hidden risk surfaced
- [ ] Brand-sensitive changes flagged for user approval
- [ ] Document delivered to user