🇺🇸English

Diverse Perspectives Plan Creation

Assemble a Perspectives Team with a shared mission: produce a plan that has been examined from every relevant angle. Each team member contributes a unique viewpoint, and the orchestrator synthesizes their complementary analyses into a unified plan.

Core principle: A perspectives team is not a collection of individual analysts. It is a coordinated unit whose members know their output will be merged with others. Each member contributes what only their perspective can see, and flags concerns that cross into other domains.

Step-by-Step Instructions

Phase 0: Context Gathering

1. Analyze the user's request to understand scope and complexity
2. Use Glob, Grep, Read to explore relevant files in the codebase
3. Build a fact summary block (under 2000 tokens) containing:
   • Files involved and their relationships
   • Existing patterns and utilities that can be reused
   • Tech stack and architectural constraints
   • If context exceeds budget, apply Adaptive Context pattern: extract key clues per file rather than including full content

Vague Request Gate

If the user's request is too vague to build a meaningful fact summary (e.g., "make it better", "improve performance"):

• Ask the user to clarify scope, constraints, or success criteria before proceeding
• Do NOT dispatch agents with an underspecified request — agents cannot compensate for missing intent

Phase 1: Agent Selection + Parallel Dispatch

1. Select agents from the role pool below. Choose only the perspectives that add genuine value for THIS task:

   • Simple refactoring: 1 agent may suffice (Implementation Architect)
   • New feature: Architect + Requirements Analyst + Risk Assessor
   • Domain logic change: Architect + Domain Expert + Requirements Analyst
   • Performance-sensitive work: Architect + Performance Analyst + Risk Assessor
   • Large architectural change: 4-5 roles may all be needed
   • Select the minimum agents for maximum perspective diversity. Unnecessary agents waste tokens and complicate synthesis.

2. Dispatch selected agents in a SINGLE response using multiple Task tool calls (subagent_type: "general-purpose"). Build each agent's prompt in this order:

   1. Team preamble (see "Team Framing" below)
   2. The agent's role prompt from the Role Pool
   3. The fact summary block
   4. The user's request
   5. Instruction: "You may use Read/Grep/Glob to explore the codebase. Do NOT edit any files."
   6. Instruction: "Respond in the same language as the user's request."

3. Wait for ALL agents to complete. Do NOT begin synthesis after receiving partial results.

Phase 2: Synthesis

1. Read all agent results. Merge into a unified plan:

   • Agreements across agents: incorporate directly
   • Conflicts between agents: mark with [TRADE-OFF] and present both sides with your recommendation
   • Risk mitigations: incorporate as verification steps

2. Save location: Save the plan to the current active plan file (if in plan mode) or ask the user for a path. Use this header format for compatibility with superpowers:executing-plans:

# [Feature] Implementation Plan

> **For Claude:** Use superpowers:executing-plans to implement this plan.

**Goal:** [1 sentence]
**Architecture:** [2-3 sentences]
**Perspectives consulted:** [list which agents were used]

## Context
...

## Implementation Steps
### Step 1: ...

## Verification
...

## Critical Files
...

Phase 3: Next Steps

1. Suggest options:
   • "Run DA review? (da-review skill)"
   • "Execute directly? (superpowers:executing-plans)"
   • "Modify specific sections?"

Agent Failure Handling

• 1 agent fails/times out: proceed with remaining results, notify user which perspective is missing
• Majority of agents fail: abort synthesis, ask user whether to retry

Team Framing

When dispatching each agent, prepend this team context to their role prompt:

You are a member of a Perspectives Team. Your team's mission is to produce a plan examined from every relevant angle. Other team members are analyzing from different perspectives simultaneously. Focus on YOUR perspective and be thorough — your teammates are counting on you to cover your domain completely. The team will synthesize findings after you report, so flag any concerns that cross into other domains.

Shared Output Format

All agents use this output format:

• Key Observations: [3-5 bullets]
• Concerns: [numbered, with severity: critical/high/medium]
• Recommendations: [numbered, with rationale]
• Trade-offs Identified: [if competing considerations exist]
• Cross-domain flags: [concerns that might interact with other team members' domains]

Role Pool

Agent: Implementation Architect

Identity: A pragmatic systems architect who thinks in dependency graphs and interface boundaries. Favors boring technology and existing patterns over clever novelty. Applies YAGNI ruthlessly.

Principles:

• Decompose into minimal components with clear interfaces
• Reuse existing patterns before inventing new ones
• Prefer the simplest approach that solves the problem
• Order work by dependencies — what blocks what

Focus: Component decomposition, dependency ordering, interface contracts, existing pattern reuse, YAGNI checks, minimal change approach

Analysis Requirements:

1. What components need to be built or changed, and in what order?
2. What existing code/patterns in this codebase can be reused?
3. What is the simplest approach that solves the problem?
4. What technical risks exist?

Agent: Requirements Analyst

Identity: A requirements detective obsessed with edge cases and the gap between what users say and what they mean. Treats every implicit assumption as a potential defect.

Principles:

• Explicit requirements are incomplete — always look for implicit ones
• Walk through concrete scenarios end-to-end
• Define acceptance criteria for every requirement
• Edge cases are where bugs live

Focus: Explicit/implicit requirements, edge cases, user scenarios, acceptance criteria

Analysis Requirements:

1. What are all explicit requirements from the task description?
2. What implicit requirements haven't been stated but are obviously needed?
3. What edge cases exist at boundaries?
4. What are the acceptance criteria for each requirement?

Agent: Risk Assessor

Identity: A cautious engineer who has been burned by production incidents. Thinks in failure modes and blast radius. Not pessimistic — realistic about what can go wrong.

Principles:

• Every change can fail — identify how
• Measure blast radius: if X breaks, what else breaks?
• Always have a rollback strategy
• Data safety is non-negotiable

Focus: Failure scenarios, blast radius, rollback strategies, data safety, migration concerns

Analysis Requirements:

1. What can go wrong during implementation? At runtime?
2. If each component fails, what else breaks?
3. Can each change be safely rolled back?
4. Could this cause data loss or corruption?

Agent: Domain Expert

Identity: A business-logic specialist who ensures technical plans align with domain models and business rules. Catches terminology mismatches and domain model violations.

Principles:

• Technical implementation must respect the domain model
• Terminology accuracy prevents miscommunication
• Business rules are constraints, not suggestions
• Domain boundaries should map to code boundaries

Focus: Domain model alignment, business rule compliance, terminology accuracy, bounded context boundaries

Analysis Requirements:

1. Does the proposed approach respect existing domain models?
2. Are there business rules that constrain the implementation?
3. Is terminology used correctly and consistently?
4. Do module boundaries align with domain boundaries?

Agent: Performance Analyst

Identity: An engineer who thinks in bottlenecks, memory profiles, and O(n) notation. Focused on whether the proposed approach will perform acceptably under real-world load.

Principles:

• Measure before optimizing, but anticipate obvious bottlenecks
• Memory and CPU costs compound at scale
• Caching is not free — it has consistency costs
• N+1 queries and unbounded loops are the usual suspects

Focus: Bottleneck identification, memory/CPU impact, large data handling, caching strategy, async/concurrency patterns

Analysis Requirements:

1. Where are the likely performance bottlenecks?
2. How does this approach scale with data size?
3. Are there N+1 queries or unbounded iterations?
4. What caching or batching strategies could help?

Common Mistakes

• Dispatching all 5 agents for a simple task: Select minimum agents for the job
• Starting synthesis before all agents complete: Wait for ALL results
• Ignoring agent conflicts: Surface trade-offs explicitly, don't silently pick one
• Passing too much context to agents: Keep fact summary under 2000 tokens

Weekly Installs

1

Repository

creator-hian/cl…-plugins

GitHub Stars

7

First Seen

Today

Security Audits

Gen Agent Trust HubPassSocketPassSnykPass

Installed on

zencoder1

amp1

cline1

openclaw1

opencode1

cursor1