Collab Vs

Brainstorm collaboratively with a partner LLM, building on each other's ideas in alternating turns, then synthesize the best ideas into a plan.

Load the consult-llm skill before proceeding — it defines the invocation contract (stdin heredoc, flags, output format, multi-turn). Do not call the CLI without loading it first.

Available models

Selectors resolvable in this environment (depends on configured API keys):

!`consult-llm models`

Arguments: $ARGUMENTS

Check the arguments for flags:

Partner flag (exactly one required): any --<selector> from the Models block above (e.g. --gemini, --openai, --deepseek). Translates to -m <selector> for the CLI.

Strip all flags from arguments to get the task description.

Set variables from the partner flag:

• MODEL: the selector (e.g. gemini, openai)
• PARTNER: the same selector, used as the display label

If no --<selector> flag is provided, ask the user which partner to use, listing the selectors from the Models block.

Phase 0: Load consult-llm Skill

Load it now. Follow its invocation contract for all CLI calls in this workflow.

Phase 1: Understand the Task (No Questions)

1. Explore the codebase - use Glob, Grep, Read to understand:

   • Relevant files and their structure
   • Existing patterns and conventions
   • Dependencies and interfaces

   Before planning or consulting, do enough research to understand how the requested behavior actually works. Before starting, think about what resources would be useful to obtain first: relevant source files, tests, logs, generated files, config, examples, command output, external docs, or authoritative upstream source. Gather the cheapest useful evidence before forming a plan.

   Do not stop at the first plausible file, definition, setting, or example. Follow references, callers, related tests, and runtime usage until you can explain the current behavior and the likely impact of changing it.

2. Ground external semantics before planning - understand the requested behavior in the real system, not just this repo

   • If the task depends on an external product, CLI, API, protocol, file format, or ecosystem convention, verify the relevant behavior using the cheapest authoritative evidence available: local binaries/flags, generated files, official docs, public source, package/library code, or web search.
   • Capture only decision-relevant facts that affect scope, acceptance criteria, compatibility, or implementation constraints.
   • Do not create a separate research artifact unless the evidence materially changes the plan.

3. Make evidence-backed assumptions - do NOT ask clarifying questions

   • Use best judgment based on codebase and external context
   • Prefer simpler solutions when ambiguous
   • Follow existing patterns in the codebase

4. Prepare context summary - create a brief summary of:

   • The task to be implemented
   • Relevant files discovered
   • Key patterns and conventions in the codebase
   • Any constraints or considerations

Phase 2: Seed (agent starts)

You kick off the brainstorm with initial ideas based on what you found in Phase 1. Write them out in full:

## Agent's Ideas

1. **Ideas**: [2-3 possible approaches with brief descriptions]
2. **Favorite**: [which approach you lean toward and why]
3. **Open questions**: [aspects you're unsure about or would benefit from another perspective]
4. **Risks**: [what could go wrong or be tricky]

Present this to the user.