Multi Perspective

Multi-Perspective Exploration

Spawn 3-5 parallel agents, each with a distinct disciplinary lens and epistemic prior, to independently investigate a research question. Then synthesise their findings into a structured comparison that surfaces agreements, tensions, and blind spots.

The core insight: a single-perspective analysis inherits the biases of that perspective. Deliberately introducing cognitive diversity — grounded in real disciplinary traditions — produces more robust research designs.

Output Path

Per rules/review-artefact-routing.md (auto-loads in research projects (path-scoped to paper-*/ and paper/)):

• Source slug: multi-perspective
• Write reports to: reviews/<scope>/multi-perspective/YYYY-MM-DD-HHMM.md inside the project, where <scope> is the paper slug (e.g., paper-jtp, paper-philtech) for paper-level reviews or _project for project-level reviews. Path is relative to the research project root, not the Task-Management repo.
• Never at project root (./CRITIC-REPORT.md-style filenames are forbidden — pre-rule layout).
• Idempotency: the timestamp includes minutes (YYYY-MM-DD-HHMM), so same-day runs are naturally separated. If multiple reports are generated in the same minute, append a descriptor ({timestamp}-r2.md, {timestamp}-revision.md) — never overwrite.
• Index update: if reviews/INDEX.md exists, write a one-line entry under "Latest per source" pointing at the new file. Otherwise review-recap will rebuild the index next time it runs.
• Infrastructure repos (Task-Management, atlas-workspace, etc.): this section does not apply — the path-scoped rule won't load there.

When to Use

• Early-stage research design: "Is this the right question? Is this the right method?"
• When choosing between competing identification strategies
• When a paper needs to convince reviewers from different traditions
• Before committing to a theoretical framework
• When you suspect your approach has blind spots

When NOT to Use

• Quick feedback — use devils-advocate (single-perspective adversarial)
• Literature search — use an installed scholarly-search workflow (discovery, not deliberation)
• Generating new questions — use a dedicated discovery workflow (this skill evaluates, not generates)
• Paper proofreading — use proofread or paper-critic agent

Workflow

Phase 1: Frame the Question

Read $ARGUMENTS and any referenced files. Formulate a clear, debatable research question or design choice. Good inputs:

• "Should I use DiD or synthetic control for this policy evaluation?"
• "Is bounded rationality or information asymmetry the better theoretical lens for this phenomenon?"
• "What are the threats to my identification strategy for [paper X]?"
• "How would different disciplines approach [phenomenon Y]?"

If the input is vague, ask one clarifying question before proceeding.

Phase 2: Generate Perspectives

Generate 3-5 distinct perspectives. Each perspective is defined by:

For rules and templates, see references/perspective-templates.md.

Present the generated perspectives to the user and get approval before proceeding. The user may want to add, remove, or adjust perspectives.

Phase 3: Investigate

Three sub-steps — parallel investigation, then user check-in, then anonymised cross-evaluation. The check-in is what differentiates this skill from a passive multi-perspective analysis.

3.1 Parallel investigation

Spawn one sub-agent per perspective using the fresh-context sub-agent mechanism. Each agent receives:

You are a [LABEL] investigating this research question:

[QUESTION]

Your disciplinary background: [DISCIPLINE]
Your epistemic prior: [EPISTEMIC PRIOR]
Your methodological preference: [METHODOLOGICAL PREFERENCE]
Your primary concern: [LIKELY CONCERN]

Context about the project:
[Relevant project context — CLAUDE.md summary, paper abstract if available]

TASK: Analyse this question from your perspective. Address:
1. How would you frame this question in your discipline?
2. What theoretical framework would you apply?
3. What empirical strategy would you recommend, and why?
4. What are the main threats to validity from your perspective?
5. What would you find most/least convincing in the current approach?
6. What is the one thing the researcher is probably overlooking?

Be specific and grounded. Cite real methodological traditions and papers where relevant.
Write 300-500 words. Do not hedge — commit to your perspective's position.

Agent configuration:

• Use subagent_type: general-purpose for each
• Run all agents in parallel (up to 5 concurrent, per orchestration convention)
• Each agent writes to a temp file; collect results after all complete

3.2 User check-in (interactive mode)

After collecting all perspective outputs, present them to the user as a structured summary and run an interactive check-in. This is the key differentiator from a passive multi-perspective analysis — the user participates as an active contributor, not a spectator.

What to present:

• Each perspective's key position (2-3 sentences, not the full output)
• The main disagreements visible so far
• Any assumptions the perspectives made about the research context

Then ask (via the available structured-question mechanism):

"Here's where the perspectives stand so far. Before they peer-review each other, I want to check in:

1. Reveal constraints: Is there anything these perspectives don't know that would change their analysis? (e.g., data limitations, institutional constraints, supervisor preferences, timeline)
2. Redirect: Is any perspective completely off-base or exploring an irrelevant direction?
3. Challenge: Do you want to push back on any specific claim before cross-evaluation?"

How the user's input feeds forward:

• Constraints revealed here are injected into the cross-evaluation prompt as "Additional context from the researcher" — each evaluator sees them
• If a perspective is marked as off-base, it is still included in cross-evaluation (for completeness) but flagged: "The researcher considers this direction less relevant because [reason]"
• Challenges are posed directly to the relevant perspective in the cross-evaluation round as an additional evaluation criterion

When to skip: If the user says "skip check-in", "just run it", or "non-interactive", proceed directly to 3.3. The default is interactive.