/do-competitively

name: do-competitively
description: 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:

Phase 1: Competitive Generation with Self-Critique + Meta-Judge (IN PARALLEL)
         ┌─ Meta-Judge → Evaluation Specification YAML ───────────┐
Task ────┼─ Agent 2 → Draft → Critique → Revise → Solution B ───┐ │ 
         ├─ Agent 3 → Draft → Critique → Revise → Solution C ───┼─┤ 
         └─ Agent 1 → Draft → Critique → Revise → Solution A ───┘ │
                                                                  │
Phase 2: Multi-Judge Evaluation with Verification                 │
         ┌─ Judge 1 → Evaluate → Verify → Revise → Report A ─┐    │
         ├─ Judge 2 → Evaluate → Verify → Revise → Report B ─┼────┤
         └─ Judge 3 → Evaluate → Verify → Revise → Report C ─┘    │
                                                                  │
Phase 2.5: Adaptive Strategy Selection                            │
         Analyze Consensus ───────────────────────────────────────┤
                ├─ Clear Winner? → SELECT_AND_POLISH              │
                ├─ All Flawed (<3.0)? → REDESIGN (return Phase 1) │
                └─ Split Decision? → FULL_SYNTHESIS               │
                                          │                       │
Phase 3: Evidence-Based Synthesis         │                       │
         (Only if FULL_SYNTHESIS)         │                       │
         Synthesizer ─────────────────────┴───────────────────────┴─→ Final Solution

Process

Setup: Create Reports Directory

Before starting, ensure the reports directory exists:

mkdir -p .specs/reports

**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:**

## Task

Generate an evaluation specification yaml for the following task. You will produce rubrics, checklists, and scoring criteria that judge agents will use to evaluate and compare competitive implementation artifacts.

CLAUDE_PLUGIN_ROOT=`${CLAUDE_PLUGIN_ROOT}`

## User Prompt
{Original task description from user}

## Context
{Any relevant codebase context, file paths, constraints}

## Artifact Type
{code | documentation | configuration | etc.}

## Number of Solutions
3 (competitive implementations to be compared)

## Instructions
Return only the final evaluation specification YAML in your response.
The specification should support comparative evaluation across multiple solutions.

**Dispatch:**

Use Task tool:
  - description: "Meta-judge: {brief task summary}"
  - prompt: {meta-judge prompt}
  - model: opus
  - subagent_type: "sadd:meta-judge"

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