Perspectives

Perspectives: Divergent Problem-Solving

Break out of single-solution thinking by delegating a problem to multiple sub-agents in parallel. Each sub-agent approaches the problem from a distinct angle, independently and without seeing each other's work. A final adversarial agent synthesizes and stress-tests the proposals into a recommendation.

The main agent frames the problem and assigns perspectives. Sub-agents solve independently. The main agent synthesizes at the end.

Arguments

• $ARGUMENTS — Optional problem description or focus area. If omitted, infer from the conversation.

Step 1: Frame the Problem

Review the conversation history and distill the problem into a structured brief. The brief must be self-contained — sub-agents receive no conversation history.

Produce a problem brief containing:

• Problem statement: What is happening and what is the impact. Include error messages, metrics, observed behavior where applicable.
• Current state: How the system works today. Relevant architecture, components, file paths, technology stack.
• Constraints: What cannot change (budget, timeline, backwards compatibility, team size, existing infrastructure).
• What has been tried or considered: Solutions already discussed and why they were insufficient. Prevents sub-agents from re-proposing rejected ideas.
• Success criteria: What a good solution looks like — performance targets, reliability requirements, acceptable tradeoffs.

Step 2: Determine Perspectives

Based on the nature of the problem, decide:

1. How many perspectives — 2-3 for well-scoped problems with clear boundaries, 4-5 for ambiguous or cross-cutting challenges. Prefer fewer, high-quality perspectives over exhaustive coverage.
2. What each perspective is. Each must be a genuinely distinct lens — not a variation of the same approach. The goal is divergence.

Perspective types (inspiration, not a fixed menu):

Announce the perspectives before spawning:

Problem: <concise statement>

Spawning N perspectives:
  1. <Name> — <focus areas>
  2. <Name> — <focus areas>
  ...

Step 3: Spawn Sub-Agents in Parallel

Launch one Opus-class sub-agent per perspective, each receiving:

• The problem brief from Step 1 (identical for all)
• Their assigned perspective and a directive to solve the problem only through that lens
• Access to the project codebase for investigation
• Access to external research tools: WebSearch, WebFetch, and any MCP tools available in the environment (e.g., context7 for library/framework docs). Use whatever is relevant to the problem.

Each sub-agent must:

• Investigate the codebase through their assigned lens. Read relevant files, configs, logs.
• Research externally when the lens demands it. Pull in current library behavior, API changes, benchmarks, known issues, industry patterns, or prior art. Prefer context7 (or equivalent MCP) for library and framework documentation — training data may lag real releases. Use WebSearch/WebFetch for industry patterns, blog posts, standards, and non-library knowledge.
• Diagnose what they believe is happening, from their perspective.
• Propose a solution with:
  • Concrete implementation approach (specific changes to specific files — not abstract advice)
  • Tradeoffs: what this approach gains, costs, and risks
  • Effort estimate: 1-hour fix or multi-day refactor?
  • Limitations: what this approach does NOT solve
• Cite external sources (URLs, MCP source names) in proposals so the Skeptic can verify.
• Do not fabricate citations. If a search is empty or a tool unavailable, say so — no hallucinated sources.
• Not collaborate with other sub-agents. Each works independently.

Do not pass conversation history to sub-agents. They work from the problem brief, the codebase, and external research tools.

Step 4: Collect and Present Proposals

Gather all sub-agent proposals and present them in a structured comparison:

## Perspective 1: <Name>
Diagnosis: <what they found>
Proposal: <their solution>
Tradeoffs: <gains vs costs>
Effort: <estimate>

## Perspective 2: <Name>
...

Do not editorialize or rank at this stage. Present each proposal on its own merits.

Step 5: Adversarial Synthesis

Spawn one final Opus-class sub-agent — the Skeptic — with the problem brief, all proposals from Step 4, codebase access, and the same external research tools available to perspective sub-agents (WebSearch, WebFetch, MCPs). The Skeptic needs these to verify claims and cited sources in proposals independently.

The Skeptic must:

• Stress-test each proposal: What breaks? What edge cases are missed? What assumptions are wrong? Challenge the premise: Is the proposal solving the real problem, or just the stated one?
• Identify complementary elements: Are there proposals that solve different facets and could be combined?
• Rank the proposals by: effectiveness (does it solve the problem?), risk (what could go wrong?), effort (cost to implement), and durability (fix or band-aid?).
• Produce a final recommendation: Endorse one proposal, propose a hybrid combining the strongest elements, or recommend a phased approach (quick fix now, proper solution later).

Step 6: Present Final Recommendation

Present the Skeptic's analysis and recommendation. Include:

• The recommended approach and why
• What was rejected and why
• Open questions or decisions requiring user input
• Suggested next step (continue discussing, proceed directly through the appropriate workflow, or plan when package shaping/risk requires it)

All findings remain in the conversation context for downstream skills to consume.

Optional file output: If the analysis is substantial (5+ perspectives or very detailed proposals), offer to write the recommendation to docs/perspectives-<topic>.md so the plan skill can reference it from disk rather than relying solely on conversation context.

Rules

• Divergence is the point. If perspectives produce similar solutions, the perspectives were poorly chosen. Each lens must be meaningfully different.
• Sub-agents investigate the codebase. They read code, configs, and infrastructure definitions to ground their proposals in reality — not just theorize.
• No premature convergence. State the problem neutrally in the brief. Include what has been tried, but do not indicate a preferred direction.
• The Skeptic is adversarial, not diplomatic. Its job is to find flaws, not validate. A proposal that survives the Skeptic has earned its recommendation.
• This skill does not produce implementation artifacts. Its output is a recommendation for the next appropriate route; analysis alone does not require a plan.

Pipeline Continuation

If this stage failed or requires user intervention, STOP. Otherwise route the user's next request by the accepted recommendation and current risk—do not treat confirmation as automatic planning authorization.

• Continue discussion when the user asks follow-up questions or decisions remain open.
• Invoke implementation-plan only when the user asks for a plan or execution needs package shaping, unresolved design decisions, material risk acceptance, or a durable multi-package contract.
• For an accepted narrow, low-risk change with no unresolved scope/risk decision, route directly to the task-appropriate implementation workflow. Do not create planned-feature artifacts merely because Perspectives ran.

When planning is selected, invoke the implementation-plan skill rather than executing plan logic inline.