Multi-Perspective Review

A structured panel review framework for any architecture, vendor, strategy, or design decision. Embeds 5-7 expert perspectives, attaches industry-precedent evidence to every assertion, and uses a weighted scoring model so the user can influence outcomes by adjusting how much emphasis each advisor receives.

Companion rules:

• 100-core.mdc - core engineering principles
• 015-context-engineering.mdc - prompt packing, retrieval, compaction

When to invoke

Use when the user asks for:

• "Panel review" / "stakeholder perspectives" / "advisory panel"
• "Pro/con analysis across multiple lenses"
• "Weighted recommendation" / "strategic review"
• "What would my CTO / Security / Finance say about this?"
• Re-weighting an existing review with a different emphasis
• A structured architecture / vendor / strategy decision that has multiple valid framings

Do not use for:

• Single-lens reviews (just call the right specialist skill)
• Creating or technically reviewing a production architecture; use the system design skill (${HANDBOOK_ROOT}/skills/system-design/SKILL.md), then use this skill only when stakeholder weighting is needed
• Decisions where one perspective dominates by mandate (compliance verdict, security veto)
• Independent assurance or required human approval; one model simulating multiple advisors is not independent verification. Use the independent verification skill (${HANDBOOK_ROOT}/skills/independent-verification/SKILL.md)
• Quick judgement calls that do not need a structured trade-off

The Six Golden Rules

1. Every advisor has a coherent lens. Not "what should we do" but "what is this decision as seen through this lens".
2. Every assertion carries an industry-precedent pair. What worked elsewhere; what blew up elsewhere.
3. Weights always sum to 100%. Force the user to make trade-offs explicit.
4. Votes are bounded (typically -2..+2). No infinite scales; no abstentions.
5. Contested decisions (within ~0.15 of a band boundary) are flagged - the outcome is sensitive to re-weighting.
6. Never silently use the default profile. Always prompt; defaulting to balanced hides bias.

The advisor roster (default)

A 6-advisor roster works for most technology decisions. Adjust per domain - mortgage decisions might add a LEGAL advisor; AI/ML decisions might add a MODEL_RISK advisor.

For each advisor, the panel emits:

• Vote in {-2, -1, 0, +1, +2}
• One-sentence pro (why this advisor would back the decision)
• One-sentence con (why this advisor would resist)
• Sharp question the advisor would ask before approving

Industry-precedent pairs

Every assertion (per product, per cross-cutting decision, per architecture choice) carries:

These are item-level (not per-advisor) - industry precedents apply to the decision as a whole. They live next to the per-advisor pro/con, not interleaved with them.

Why both, always: sales decks show only what_worked; risk reports show only horror_story. A real review needs both, side by side, on every claim. If you cannot supply both, mark the missing one as REVIEW.

Weight profiles

Seven presets plus Custom. Always sum to 100. Reweight as needed for a 5- or 7-advisor roster.

Scoring

For each item, each advisor has a vote v in {-2, +2}. Weighted score:

S = sum( (weight_percent / 100) * vote_advisor )

Decision bands:

A score within +/-0.15 of a band boundary is flagged contested - the outcome is sensitive to re-weighting. Surface this prominently; offer to run the same review under another profile to test.

Workflow

1. Determine the weight profile. Use AskQuestion. Do not silently default. Accept:
   • One of the preset names
   • Custom: ask for the percentages in DS,ARCH,BV,OPS,RISK,EXEC order
   • Reject anything that does not sum to 100
2. Enumerate items. Decisions, products, architecture choices - whatever the user is deciding among.
3. For each item, populate the panel:
   • Industry-precedent pair (what_worked + horror_story)
   • Per advisor: vote, pro, con, sharp question
4. Score. Compute S per item. Compare against any baseline; flag contested ones.
5. Report. Structured response with the precedent pair on top, per-advisor rows below, weighted outcome at the bottom. If multiple items, end with a summary table sorted by score.
6. Offer to re-weight. If a decision is contested or the user signals dissatisfaction, suggest running again with a different profile (typically the opposite of whatever was chosen first).

Output format

## <Item>: <one-line decision>

**EVIDENCE**
- WHAT WORKED: <one-sentence positive industry precedent>
- HORROR STORY: <one-sentence cautionary precedent>

| Advisor | Vote | Pro | Con | Sharp question |
|---|---|---|---|---|
| DS  | +1 | ... | ... | ... |
| ARCH | +2 | ... | ... | ... |
| BV  | -1 | ... | ... | ... |
| OPS | 0  | ... | ... | ... |
| RISK | +1 | ... | ... | ... |
| EXEC | +2 | ... | ... | ... |

**Weighted score (profile: <name>):** S = +0.83 -> **RETAIN / PROCEED**
**Contested?** No (band boundary at +0.40 / +1.20; nearest is 0.37 away)

Integration with downstream skills

This skill composes well with:

• An analysis skill (e.g., technology-consolidation-analysis) - the analysis skill auto-detects this skill and adds Advisory Panel + Weighted Recommendations tabs to its workbook output.
• A dashboard skill - the dashboard renders per-item advisor views with green "what worked" and red "horror story" callouts under the item selector.
• A decision-record skill (ADRs) - the panel review becomes the "alternatives considered + rationale" section of the ADR.

When composing, see skills/skills-composition for HITL gates between phases and graceful degradation when an optional sibling is absent.

Authoring guidance

Writing the per-advisor view for a decision

The trap: writing the pro/con as "this advisor would say <generic argument>". The point is the specific argument this advisor cares about.

Bad (OPS for "adopt managed Postgres"):

• Pro: "Reduces infrastructure burden."

Good:

• Pro: "Patching, replication, and PITR move from the SRE rotation to the cloud provider; SRE time freed up for app reliability work."

Writing the precedent pair

Be specific. Vague precedents read as filler.

Bad: "Most companies have done this successfully."

Good: "Spotify migrated 1,200 services to managed Postgres in 18 months with zero data loss; the SRE rotation shrank by 30%."

If you do not have a specific precedent, mark REVIEW. Do not invent.

Writing the sharp question

The question the advisor would ask before approving. Forces clarity in the design.

Examples:

• DS: "What is the data quality SLO and who owns the dead-letter queue?"
• ARCH: "What is the exit path if the vendor doubles their price next year?"
• RISK: "Where does the audit log live and how long is retention?"
• EXEC: "What is the headline result the board will hear in 12 months?"

Anti-patterns

1. Default to balanced silently. Always prompt; defaulting hides bias.
2. Generic pro/con. Each advisor must speak from their lens, not produce a general argument.
3. Missing precedent. Drops the discipline that distinguishes this skill from a feel-good panel.
4. Single source for what_worked / horror_story. At least one industry-public reference; mark REVIEW if not available.
5. Hidden weight changes. If you re-run with different weights, surface that explicitly.
6. Skipping contested-flag annotations. Contested decisions are the most useful output of the framework.
7. Voting +/-3 or beyond. Bounded scale; out-of-bounds votes are noise.
8. Letting one advisor dominate via vote magnitude. All votes are bounded; influence comes from weights, not vote inflation.

When NOT to use

• Single-lens decisions - if only one perspective matters, do not pretend.
• Compliance / safety vetoes - if RISK has a hard veto, the panel is theatre. Surface the veto first.
• Personal-preference decisions (which IDE? which font?) - the framework adds friction without adding signal.
• Quick exploratory choices - reserve for decisions worth 30+ minutes.

Extending the skill

• Add an advisor - update the roster table and redistribute weights to sum to 100. Default new advisor to the lowest weight in balanced.
• Domain-specific roster (e.g., for FinTech: LEGAL, COMPLIANCE, MARKET_RISK) - swap or supplement the default 6.
• Domain-specific profile (e.g., regulated-financial-services) - new preset summing to 100.
• Voting scale - the default is integer [-2, +2]. For finer-grained reviews, allow halves; for binary calls, restrict to {-1, +1}. Document the scale in the report header.

Related

• Rule: 100-core.mdc - SOLID / DRY / KISS
• Rule: 015-context-engineering.mdc - prompt packing
• Skill: skills-composition - patterns for chaining this with analysis skills
• Skill: agent-workflow - workflow patterns for complex multi-step tasks

Attribution

Pattern adapted from a six-advisor consulting-toolkit framework that combines per-advisor pro/con/question views with industry-precedent pairs and weighted scoring. The discipline of "every assertion carries both what_worked and horror_story" cuts through analysis paralysis and over-confidence in equal measure.