agentleFS
raineraine/consult-llm-mcp/skills/collab/SKILL.md

collab

Skill148 starsChanged 4 months agoMITView on GitHub

Multiple LLMs collaboratively brainstorm solutions, building on each other's ideas across rounds. Agent synthesizes the best ideas into a plan.

4 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions4 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 4

    1. michelhelsdingen/ensemble★ 251same name
    2. dylanroscover/Embody★ 213same name
    3. Hokken/collab-skill★ 2same name
    4. resonatingloop/hmmarium★ 0same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository11 other files it gives its agents.

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. 0 are common, 13 are distinctive, and 0 are very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 13

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

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

    line 30
  2. Distinctive:

    Do not stop at the first plausible file, definition, setting, or example.

    line 37
  3. Distinctive:

    If the task depends on an external product, CLI, API, protocol, file format, or ecosystem convention, verify the relevant behavior using …

    line 40
  4. Distinctive:

    Do not create a separate research artifact unless the evidence materially changes the plan.

    line 42
  5. Distinctive:

    Make evidence-backed assumptions: - do NOT ask clarifying questions

    line 44
  6. Distinctive:

    Use best judgment based on codebase and external context

    line 45
  7. Distinctive:

    Prefer simpler solutions when ambiguous

    line 46
  8. Distinctive:

    Follow existing patterns in the codebase

    line 47
  9. Distinctive:

    Prepare context summary: - create a brief summary of:

    line 49
  10. Distinctive:

    When to stop: All collaborators are refining details rather than introducing new ideas, and a clear approach has emerged.

    line 107
  11. Distinctive:

    After all rounds, synthesize the brainstorm into a plan:

    line 111
  12. Distinctive:

    Exact file paths: - never "somewhere in src/"

    line 155
  13. Distinctive:

    DRY, YAGNI: - only what's needed

    line 158

“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Have multiple LLMs collaboratively brainstorm solutions, then synthesize the best ideas into a plan. The LLMs build on each other's ideas across rounds rather than critiquing positions.

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

Model flags: any --<selector> from the Models block above selects a collaborator (e.g. --gemini, --openai, --deepseek). Repeat for multiple. Need at least two. Translate model flags and defaults according to the loaded consult-llm skill's model-selection rules.

Strip all flags from arguments to get the task description. Use the selector name as the label when presenting per-model output.

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: Initial Ideas

Have all selected LLMs independently brainstorm approaches (in parallel).

Seed prompt:

I need to implement the following task:

[Task description]

Here's what I found in the codebase:
[Context summary - relevant files, patterns, conventions]

Brainstorm implementation ideas:
1. **Ideas**: List 2-3 possible approaches with brief descriptions
2. **Favorite**: Which approach do you lean toward and why?
3. **Open questions**: What aspects are you unsure about or would benefit from another perspective?
4. **Risks**: What could go wrong or be tricky?

Think creatively. Share rough ideas — we're exploring, not committing.

Invoke consult-llm with -f <path> for each relevant source file, sending the seed prompt per the consult-llm invocation contract. If explicit collaborator flags were supplied, pass one -m <selector> per collaborator. Otherwise omit -m so consult-llm applies configured defaults. All models are queried in parallel in a single call.

Extract per-model thread IDs from the response — needed for Phase 3 since each model receives a different prompt.

Present each set of ideas to the user, labeled by selector.

Phase 3: Build On Each Other

Each round, share every other LLM's ideas with each model and ask them to build on them (in parallel). Pass each LLM's thread ID via -t <id> to continue its conversation. Continue until the ideas converge into a clear approach — typically 2-3 rounds, but use as many as needed.

Build-on prompt (same template for each model; embed every other model's previous-round response, labeled by selector):

Your collaborator(s) shared these ideas:

[Other LLMs' responses from the previous round, each labeled with the selector name]

Build on their thinking:
1. **What resonates**: Which ideas are strong? Why?
2. **Combinations**: Can any ideas be combined into something better?
3. **New ideas**: Did their thinking spark any new approaches?
4. **Refinements**: How would you improve the most promising ideas so far?
5. **Concerns resolved**: Did their ideas address any open questions?

Keep building — don't tear down. Refine toward the best solution.

Each model receives a different prompt (the other models' responses embedded). Invoke consult-llm once with one --run flag per collaborator, continuing each model's thread.

Present every response to the user after each round, labeled by selector.

When to stop: All collaborators are refining details rather than introducing new ideas, and a clear approach has emerged. Don't stop while there are still unresolved open questions or competing directions.

Phase 4: Synthesize

After all rounds, synthesize the brainstorm into a plan:

  1. Identify the strongest ideas — which approaches gained momentum across rounds?
  2. Note convergence — where did the LLMs naturally align?
  3. Pick the best combination — merge the strongest elements into one coherent approach
  4. Write the plan:
# [Feature Name] Implementation Plan

**Goal:** [One sentence describing what this builds]

## Brainstorm Summary

**Key ideas** (one block per collaborator, labeled with the selector):
- **<selector>:** [2-3 bullet points]

**Convergence:** [Where they naturally agreed]
**Synthesis:** [How the final approach combines the best ideas]

---

### Task 1: [Short description]

**Files:**
- Create: `exact/path/to/file.py`
- Modify: `exact/path/to/existing.py` (lines 123-145)

**Steps:**
1. [Specific action]
2. [Specific action]

**Code:**
```language
// Include actual code, not placeholders
```

---

Guidelines:

  • Exact file paths - never "somewhere in src/"
  • Complete code - show the actual code
  • Small tasks - 2-5 minutes of work each
  • DRY, YAGNI - only what's needed

Save the plan to history/plan-<feature-name>.md.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.