compare

• Use compare when the user already has a known finite set of options to evaluate
• Use /empire-research:explore instead when the solution space is open and options need to be enumerated first
• If user input describes a problem without specific options, suggest /empire-research:explore and confirm before proceeding here

• Read conversation for: option list, use case, constraints, decision criteria
• Required inputs before dispatch:
  • Concrete option names (at least 2; ideally 3–5)
  • Use case / what the chosen option must do well
  • Constraints (stack, scale, budget, license, team familiarity)
  • Decision dimensions (perf, DX, ecosystem, maturity, license, cost, etc.)
• If any required input is missing → ask one clarifying question at a time
• For decision dimensions, suggest a sensible default set if user has no preference (see default-dimensions)
• MUST confirm option list AND dimension list with user before dispatch
• MUST NOT proceed if option list has < 2 options — redirect to /empire-research:explore

When the user does not specify dimensions, suggest the relevant subset of:

• Tech library / framework: performance, DX, ecosystem, maturity, type safety, bundle / runtime size, license, community size, breaking-change history
• Vendor / SaaS: pricing model, free tier, lock-in risk, data residency, SLA, support quality, integration coverage
• Architectural choice: complexity, operational cost, scaling profile, team skill match, reversibility, debuggability

User can add, remove, or reweight dimensions before dispatch.

• After the option list and dimensions are confirmed, dispatch scoring one of two ways

• Preferred — Workflow tool available:

  • Invoke the bundled scoring workflow; it scores each option in isolation (blind to rivals) with structured per-dimension output:

    Workflow({
      scriptPath: "${CLAUDE_PLUGIN_ROOT}/workflows/compare-score.js",
      args: { useCase, constraints, dimensions: [{ name, description }], options: [{ name, description }] },
    })
    

  • Surface the workflow's log() lines as progress

  • Feed the returned options[] into consolidated-matrix; apply dimension weights in the skill so the user can reweight without re-running

  • Skip agent-selection and parallel-dispatch — the workflow owns dispatch

• Fallback — Workflow tool unavailable: use agent-selection then parallel-dispatch below

• Fallback path — only when the Workflow tool is unavailable (see dispatch-mode)
• One agent per option for parallel deep evaluation
• Agent names vary by environment; do not assume a specific agent exists
• Inspect available subagents via the Agent tool's subagent_type parameter
• For each option, identify its dominant signal:
  • Library / framework / language → pick the most specific language or framework expert available; fall back to a general code or research agent
  • Vendor / SaaS / commercial product → pick a comparative-analysis or research-synthesis agent
  • Architectural choice → pick an architecture-review or systems-design agent
• MUST include at least one general research-synthesis agent in the roster to anchor cross-option consistency
• List chosen agent per option (using its actual subagent_type value) + one-line rationale BEFORE dispatch
• If confident in every pick → dispatch immediately
• If uncertain about any pick → confirm roster with user before dispatch; allow swaps
• Skip the shallow-scan phase — options are already known

• Send single message with multiple Agent tool calls (one per option)

• Each agent receives:

  • The specific option assigned to them (one option per agent)
  • The agreed-upon dimension list with descriptions
  • User constraints and use case
  • Output format instruction (see below)
  • "Score the assigned option ONLY against each dimension. Do not compare to other options. Do NOT post findings externally."

• Required per-option output format:

  Option: <name>
  
  Summary: <2-3 sentences>
  
  Per-dimension scoring:
  | Dimension | Score (1-5) | Evidence | Notes |
  |---|---|---|---|
  
  Pros:
  - <point>
  
  Cons:
  - <point>
  
  Key citations:
  - <source>
  

• Cap each agent response under 400 words

• Isolation rationale: each agent scores its option blind to rivals — independent, evidence-based scores with no anchoring bias; head-to-head comparison happens only in consolidation

• After all option-agents return, produce side-by-side matrix

• If the workflow returns stats.scored < stats.requested, MUST name the options that failed and ask whether to re-run them before showing the matrix

• Required output structure:

  ## Comparison Matrix
  
  | Dimension     | Option A | Option B | Option C |
  |---------------|----------|----------|----------|
  | <dimension 1> | 4 — note | 3 — note | 5 — note |
  ...
  | TOTAL         | 22       | 19       | 27       |
  

• Apply user-supplied weights to dimensions if provided; otherwise unweighted sum

• Highlight cells where one option dominates or underperforms by a clear margin

• ## Conflicts section — where agents cite contradicting evidence; state each side

• ## Recommendation — winner + rationale + when the runner-up would be the better pick (decision criteria)

• ## Caveats — known unknowns, sources of uncertainty, freshness of data

• MUST cite sources from agent reports

• MUST present report then stop; ask user whether to proceed with chosen option

• Mark each cell or claim as [Confirmed], [Estimated], or [Inferred]:
  • Confirmed: cited official docs, benchmarks, source code
  • Estimated: derived from indirect evidence (community reports, third-party benchmarks)
  • Inferred: agent's reasoning, no direct citation
• MUST never present [Inferred] data as confirmed fact

• MUST gather option list AND dimension list before any dispatch
• MUST confirm both with user before dispatch
• MUST dispatch scoring via the compare-score workflow when the Workflow tool is available; else dispatch in parallel (single message, multiple tool uses), one agent per option
• MUST keep findings local in chat only
• MUST NOT post to Slack, GitHub, Jira, or any external system unless user explicitly authorizes
• MUST NOT pick a winner without showing the matrix
• MUST NOT begin implementation
• MUST mark inferred data as such — never present speculation as fact
• If zero suitable research/code/architecture agents exist in environment → MUST stop and tell user; never inline-impersonate an evaluator