Execute tasks through competitive multi-agent generation, meta-judge evaluation specification, multi-judge evaluation, and evidence-based synthesis

do competitively <task Execute tasks through competitive multi agent generation, meta judge evaluation specification, multi judge evaluation, and evidence based synthesis to produce superior results by combining the best elements from parallel implementations. </task <context This command implements the Generate Critique Synthesize (GCS) pattern with adaptive strategy selection for high stakes tasks where quality matters more than speed. It combines competitive generation with meta judge evaluation specification and multi perspective evaluation, then intelligently selects the optimal synthesis strategy based on results. Key features: Self critique loops in generation (Constitutional AI) Structured evaluation Meta judge produces tailored rubrics before judging Verification loops in evaluation (Chain of Verification) Adaptive strategy: polish clear winners, synthesize split decisions, redesign failures Average 15 20% cost savings through intelligent strategy selection </context CRITICAL: You are not implementation agent or judge, you shoudn't read files that provided as context for sub agent or task. You shouldn't read reports, you shouldn't overwhelm your context with unneccesary information. You MUST follow process step by step. Any diviations will be considered as failure and you will be killed! Pattern: Generate Critique Synthesize (GCS) This command implements a multi phase adaptive competitive orchestration pattern: Process Setup: Create Reports Directory Before starting, ensure the reports directory exists: Report naming convention: .specs/reports/{solution name} {YYYY MM DD}.[1 2 3].md Where: {solution name} Derived from output path (e.g., users api from output specs/api/users.md ) {YYYY MM DD} Current date [1 2 3] Judge number Note: Solutions remain in their specified output locations; only evaluation reports go to .specs/reports/ Phase 1: Competitive Generation + Meta Judge (IN PARALLEL) Launch 3 independent generator agents AND 1 meta judge agent in parallel (4 agents total, all recommended: Opus for quality): The meta judge runs in parallel with the 3 generators because it does not need their output — it only needs the task description to generate evaluation criteria. CRITICAL: Dispatch all 4 agents in a single message using 4 Task tool calls as foreground agents. The meta judge MUST be the first tool call in the dispatch order, because he should have time to collect context from codebase, before it was modified by generators. Meta Judge Agent (1 agent) The meta judge generates an evaluation specification YAML (rubrics, checklists, scoring criteria) tailored to this specific task. It returns the evaluation specification YAML that all 3 judges will use. Prompt template for meta judge: Dispatch: Generator Agents (3 agents) 1. Each agent receives identical task description and context 2. Agents work independently without seeing each other's work 3. Each produces a complete solution to the same problem 4. Solutions are saved to distinct files (e.g., {solution file}.[a b c].[ext] ) Solution naming convention: {solution file}.[a b c].[ext] Where: {solution file} Derived from task (e.g., create users.ts result in users as solution file) [a b c] Unique identifier per sub agent [ext] File extension (e.g., md , ts and etc.) Key principle: Diversity through independence agents explore different approaches. CRITICAL: You MUST provide filename with [a b c] identifier to agents and judges!!! Missing it, will result in your TERMINATION imidiatly! Prompt template for generators: Parallel Dispatch Example Send ALL 4 Task tool calls in a single message. Meta judge first, then generators: Wait for ALL 4 to return before proceeding to Phase 2. Phase 2: Multi Judge Evaluation Launch 3 independent judges in parallel (recommended: Opus for rigor): CRITICAL: Wait for ALL Phase 1 agents (meta judge + 3 generators) to complete before dispatching judges. CRITICAL: Provide to each judge the EXACT meta judge evaluation specification YAML. Do not skip or add anything, do not modify it in any way, do not shorten or summarize any text in it! 1. Each judge receives the meta judge evaluation specification YAML and paths to ALL candidate solutions (A, B, C) 2. Judges evaluate against the meta judge's criteria (not hardcoded criteria) 3. Each judge produces: Comparative analysis (which solution excels where) Evidence based ratings (with specific quotes/examples) Final vote (which solution they prefer and why) 4. Reports saved to distinct files (e.g., .specs/reports/{solution name} {date}.[1 2 3].md ) Key principle: Multiple independent evaluations reduce bias and catch different issues. Prompt template for judges: yaml {meta judge's evaluation specification YAML} CRITICAL: NEVER provide score threshold to judges. Judge MUST not know what threshold for score is, in order to not be biased!!! Dispatch: Phase 2.5: Adaptive Strategy Selection (Early Return) The orchestrator (not a subagent) analyzes judge outputs to determine the optimal strategy. Decision Logic Step 1: Parse structured headers from judge reply Parse the judges reply. CRITICAL: Do not read reports files itself, it can overflow your context. Step 2: Check for unanimous winner Compare all three VOTE values: If Judge 1 VOTE = Judge 2 VOTE = Judge 3 VOTE (same solution): Strategy: SELECT AND POLISH Reason: Clear consensus all three judges prefer same solution Step 3: Check if all solutions are fundamentally flawed If no unanimous vote, calculate average scores: 1. Average Solution A scores: (Judge1 A + Judge2 A + Judge3 A) / 3 2. Average Solution B scores: (Judge1 B + Judge2 B + Judge3 B) / 3 3. Average Solution C scores: (Judge1 C + Judge2 C + Judge3 C) / 3 If (avg A < 3.0) AND (avg B < 3.0) AND (avg C < 3.0): Strategy: REDESIGN Reason: All solutions below quality threshold, fundamental approach issues Step 5: Default to full synthesis If none of the above conditions met: Strategy: FULL SYNTHESIS Reason: Split decision with merit, synthesis needed to combine best elements Strategy 1: SELECT AND POLISH When: Clear winner (unanimous votes) Process: 1. Select the winning solution as the base 2. Launch subagent to apply specific improvements from judge feedback 3. Cherry pick 1 2 best elements from runner up solutions 4. Document what was added and why Benefits: Saves synthesis cost (simpler than full synthesis) Preserves proven quality of winning solution Focused improvements rather than full reconstruction Prompt template: Strategy 2: REDESIGN When: All solutions scored <3.0/5.0 (fundamental issues across the board) Process: 1. Launch new agent to analyze the failure modes and lessons learned. Ask the agent to: Think through step by step: what went wrong with each solution? Analyze common failure modes across all solutions Extract lessons learned (what NOT to do) Identify the root causes of why all approaches failed Generate new task decomposition or constraints based on these insights 2. Return to Phase 1 , provide to new implementation agents the lessons learned and new constraints. Prompt template for new implementation: Strategy 3: FULL SYNTHESIS (Default) When: No clear winner AND solutions have merit (scores =3.0) Process: Proceed to Phase 3 (Evidence Based Synthesis) Phase 3: Evidence Based Synthesis Only executed when Strategy 3 (FULL SYNTHESIS) selected in Phase 2.5 Launch 1 synthesis agent (recommended: Opus for quality): 1. Agent receives: All candidate solutions (A, B, C) All evaluation reports (1, 2, 3) 2. Agent analyzes: Which elements each judge praised (consensus on strengths) Which issues each judge identified (consensus on weaknesses) Where solutions differed in approach 3. Agent produces final solution by: Copying superior sections when one solution clearly wins Combining approaches when hybrid is better Fixing identified issues that all judges caught Documenting decisions (what was taken from where and why) Key principle: Evidence based synthesis leverages collective intelligence. Prompt template for synthesizer: <output The command produces different outputs depending on the adaptive strategy selected: Outputs (All Strategies) 1. Candidate solutions: {solution file}.[a b c].[ext] (in specified output location) 2. Evaluation reports: .specs/reports/{solution name} {date}.[1 2 3].md 3. Resulting solution: {output path} Strategy Specific Outputs SELECT AND POLISH: Polished solution based on winning solution REDESIGN: Do not stop, return to phase 1 and eventiualy should result in finish at SELECT AND POLISH or FULL SYNTHESIS strategies FULL SYNTHESIS: Synthesized solution combined best from all Orcestrator Reply Once command execution is complete, reply to user with following structure: </output Best Practices Meta Judge + Judge Verification Never skip meta judge Tailored evaluation criteria produce better judgments than generic ones Meta judge runs once Same specification for all 3 judges Include CLAUDE PLUGIN ROOT Both meta judge and judges need the resolved plugin root path Meta judge YAML Pass only the meta judge YAML to judges, do not add any additional text or comments to it! Common Pitfalls Using for trivial tasks Overhead not justified Vague task descriptions Leads to incomparable solutions Insufficient context Agents can't produce quality work Forcing synthesis when clear winner exists Wastes cost and risks degrading quality Synthesizing fundamentally flawed solutions Better to redesign than polish garbage Skipping meta judge Hardcoded criteria are less effective than tailored ones Modifying meta judge YAML before passing to judges Judges must receive exact specification Do: Well defined task with clear constraints Rich context for informed decisions Trust adaptive strategy selection Polish clear winners, synthesize split decisions, redesign failures Dispatch meta judge in parallel with generators for speed Examples Example 1: API Design (Clear Winner SELECT AND POLISH) Phase 1 outputs (4 parallel agents): Meta judge: evaluation specification YAML with 5 criteria dimensions, comparative rubrics specs/api/users.a.md Resource based design with nested routes specs/api/users.b.md Action based design with RPC style endpoints specs/api/users.c.md Minimal design, missing auth consideration Phase 2 outputs (assuming date 2025 01 15, 3 judges using meta judge specification): .specs/reports/users api 2025 01 15.1.md : "Most RESTful, good security" .specs/reports/users api 2025 01 15.2.md : "Clean resource design, scalable" .specs/reports/users api 2025 01 15.3.md : "Best practices, clear structure" Phase 2.5 decision (orchestrator parses headers): Unanimous vote: A, A, A Average scores: A=4.5, B=3.2, C=2.8 Strategy: SELECT AND POLISH Reason: Unanimous winner with 1.0 point gap Phase 3 output: specs/api/users.md Solution A polished with: Added rate limiting documentation (from B) Simplified nested routes (judge feedback) Total cost: 8 agents (4 Phase 1 + 3 judges + 1 polish) Example 2: Algorithm Selection (Split Decision FULL SYNTHESIS) Phase 1 outputs (4 parallel agents): Meta judge: evaluation specification YAML with 4 criteria dimensions, comparative rubrics specs/caching.a.md Redis with LRU eviction specs/caching.b.md Multi tier cache (memory + Redis) specs/caching.c.md CDN + application cache Phase 2 outputs (assuming da

do-competitively