Perform multi-perspective analysis and deep-research of a problem to arrive at a well-considered proposed solution
name socratize description Perform multi-perspective analysis and deep-research of a problem to arrive at a well-considered proposed solution Socratize ⚠️ CRITICAL INSTRUCTION : When this command is invoked, you MUST IMMEDIATELY invoke the /orchestrate slash command. DO NOT attempt to do any work yourself. Your ONLY job is to invoke /orchestrate right away. Immediate Action Required Use the Skill tool to invoke /orchestrate : Skill( skill: "orchestrate" ) The /orchestrate command will coordinate the Socratic dialogue process described below. Overview The /socratize command orchestrates a Socratic dialogue process with multiple analyst and architect agents, each with unique personalities and perspectives, to thoroughly analyze complex software problems and build consensus on solutions. Architecture : The orchestrator spawns a product owner who facilitates the dialogue. The product owner CANNOT directly spawn or manage analyst/architect agents - it must request the orchestrator to perform these actions and relay messages between agents. Core Responsibilities CRITICAL: As the orchestrator, you are responsible for: Agent lifecycle management : Only you can spawn analyst and architect agents using the Task tool Message relay : Pass information between product owner and analysts/architects Coordination : Execute the product owner's requests for agent spawning and communication DO NOT read files, grep, or analyze problems yourself - that's for the agents Let the product owner determine when the process is complete CRITICAL: The product owner CANNOT: Use the Task tool to spawn agents directly Communicate with analysts/architects directly Must request all agent operations through you (the orchestrator) Process Workflow Phase 1: Problem Clarification Orchestrator spawns a product owner who then requests the orchestrator to deploy a technical analyst to ensure clarity on: : What needs to be solved? : What background information is relevant? : What does success look like? Message flow : Orchestrator → Product Owner → (requests analyst spawn) → Orchestrator spawns analyst → Analyst works → Orchestrator relays results to Product Owner If any element is unclear or ambiguous, ESCALATE TO USER IMMEDIATELY . Do not assume anything. Phase 2: Determine Agent Counts Product owner analyzes the problem scope and requests the orchestrator to spawn [NUM_ANALYSTS] and [NUM_ARCHITECTS] (range: 3-10 each): Small scope (3-3): Simple feature additions Local code changes Single-module modifications Needs: Local source analysis, git history, maybe wiki docs Medium scope (5-5): Multi-module features Cross-cutting concerns Integration changes Needs: Multiple codebases, API contracts, deployment considerations Large scope (10-10): Application-wide changes Architecture overhauls System-wide refactoring Needs: Comprehensive codebase understanding, extensive documentation review, multiple integration points Phase 3: Deploy Agent Flock Product owner requests and orchestrator spawns [NUM_ANALYSTS] analysts and [NUM_ARCHITECTS] architects, each with: Unique name (e.g., "Marcus", "Elena", "Raj") Personality disposition (ranging from optimistic to skeptical, plus other dimensions like risk-averse/risk-tolerant, detail-oriented/big-picture, pragmatic/idealistic) Message flow : Product Owner designs agent specs → Orchestrator spawns agents → Orchestrator relays outputs back to Product Owner Agent instruction format: You are [NAME] and your style is [PERSONALITY DISPOSITION].
<agent-specific instructions> Analyst agent tasks: Collect information from wiki, Jira, PRs, documentation Use issue-tracker integration for querying issues and reading issue details Use documentation integration for accessing wiki documentation and proposals Provide annotated research with light analysis Focus on understanding [PROBLEM] thoroughly Report if insufficient information found (escalate to user) Architect agent tasks: Review analyst findings Synthesize solutions for [EXPECTED OUTCOME] Ask analysts for additional data if needed Propose and critique peer proposals Vote on solutions Phase 4: Socratic Dialogue (Facilitated by Product Owner via Orchestrator) The product owner facilitates dialogue through the orchestrator : Initial Information Gathering : Product owner requests orchestrator spawn analysts in parallel Synthesis : Product owner requests orchestrator relay analyst findings to architects Clarification Round : Product owner requests orchestrator relay architect questions to analysts (if ambiguous, escalate to user) Proposal Phase : Product owner requests orchestrator collect architect proposals Deliberation Rounds : Up to 5 rounds of peer review and voting (orchestrator relays messages) Between rounds: Product owner organizes architect feedback Orchestrator relays feedback and voting requests to architects Orchestrator relays architect votes back to product owner Continue until 2/3 majority agreement on one solution Message flow example : Product Owner → Orchestrator: "Spawn 5 analysts with these specs..." Orchestrator → Spawns analysts → Relays results to Product Owner Product Owner → Orchestrator: "Share analyst findings with architects..." Orchestrator → Relays to architects → Collects responses → Returns to Product Owner Escalation rules: If analysts report insufficient information → product owner escalates to user for more [CONTEXT] If architects cannot reach 2/3 consensus after 5 rounds → product owner escalates to user with summary of disagreements Phase 5: Completion Process ends when product owner declares consensus reached or escalates deadlock to user. Example Usage Small feature example: User: "We need to add rate limiting to the API endpoints"For analyst agents, include:
Orchestrator workflow:
Orchestrator workflow: