Ari’s Space*   est. 2026
Skip to content
ari*s space[ a. ]
← Libraryworkflows / 2026-08-02

Brainstorming swarm: design under parallel pressure

A multi-lens design skill that fans work out of the main chat, returns digests not dumps, and stops at a written design you can defend. Dispatch-first when you can. Serial when you must.

7 parts / Hover to explore. Click to read.

A multi-lens design skill that fans work out of the main chat, returns digests not dumps, and stops at a written design you can defend. Dispatch-first when you can. Serial when you must.

Goal + fixed constraints
          |
      Discovery
          |
   Human Gate A: agree
          |
  Approaches + critique
          |
   Human Gate B: choose
    -> design; STOP before build
Independent discovery and competing approaches support two human gates. The method ends at an approved design; implementation needs its own brief and authority.
Agent context pack

Sometimes you need another way of looking at the problem before you need anyone to build it.

A solo brainstorm gives you one seat and a conversation. A build swarm gives you more hands once the design is settled. This skill puts several seats on the design itself, then stops at an approved written design.

It is a folder of Markdown, role cards and schemas that you load into an agent workspace. It supplies a method. Your host supplies the actual agents, tools and permissions.

The job it does

The conductor starts with the goal and the things that must hold. Discovery workers look through different lenses: failure, stakeholder, constraint, temporal and experiential by default. You review what they found at Gate A.

Then separate workers propose approaches under different assumptions. Critics decide what to kill, keep or salvage. You choose a winner or a combination at Gate B. The conductor presents the design, writes the approved version and stops.

The result is a design you can explain and defend. Implementation needs its own brief and authority.

+--------+     +-----------+     +--------+     +------------+
|  S0    | --> |  S1       | --> | Gate A | --> |  S2        |
| Frame  |     | Discovery |     | human  |     | Approaches |
+--------+     +-----------+     +--------+     +------------+
                                                      |
                                                      v
+--------+     +-----------+     +--------+     +------------+
|  S5    | <-- |  S4       | <-- | Gate B | <-- |  S3        |
| Spec   |     | Present   |     | human  |     | Critique   |
| HALT   |     +-----------+     +--------+     +------------+
+--------+

Each worker receives a bounded brief: goal, fixed constraints, required fields and word limits. Each returns a digest. The main seat should be able to compare the findings without reading every tool call that produced them.

A return with the wrong structure, or a dump of raw material, gets one retry. If it still does not meet the contract, the conductor escalates to you.

  DUMP (rejected)              DIGEST (accepted)
  ----------------             -----------------
  full tool logs               named fields only
  recursive tree paste         hard word caps
  "here's everything I saw"    one retry on bad shape
  floods the window            protects the window

Be accurate about how the work ran:

ModeWhat actually happened
dispatchIndependent seats performed the legs.
serial_fallbackOne seat performed the roles in sequence, using the same schemas.
partialSome legs ran in parallel and others serially; name which.

One seat can still use the method. Its self-critique is not independent peer review. A working fallback matters; it does not make that fallback the preferred route when independent seats are available.

Keep the main conversation usable

The design came from sessions that had become too full to think in. Bulk reads and logs used the space that should have held decisions.

A digest gives that space a boundary. It has named fields and a size limit. You can reject it. The supporting work can be substantial without making the main conversation substantial in the same way.

The main seat advises, routes and brings the results together. Workers carry out their briefs. They do not take over your conversation, change the process or own the choices about taste and direction. This is the conductor-and-orchestra split applied to design work.

Dispatch is the default when the host supports it. Keep a small, local task inline. Send work out when it involves a large read set, long output, sustained execution, a different capability or approaches that must stay separate while they develop.

The practical question is: will this leg fill the main window with material that belongs somewhere else?

  DISPATCH-FIRST (default)          SERIAL FALLBACK (floor)
  ------------------------          -----------------------
  multi-seat / multi-tab            one seat, stages in order
  same-turn spawn when ready        same digests, same gates
  true peer critique possible       mode: serial_fallback
  mode: dispatch                    never fake peer quality

If the host cannot run multiple seats, use the serial route and label it honestly. The same digests and human gates still apply. Portability means the method has a usable floor, not that every host can provide the same execution.

Choose the method for the problem

These three skills have different stopping points:

                 +----------------------+
                 |  brainstorming swarm |
                 |  many seats on DESIGN|
                 |  stop at written spec|
                 +----------+-----------+
                            |
           +----------------+----------------+
           |                                 |
           v                                 v
  +------------------+              +------------------+
  | solo brainstorm  |              | build swarm      |
  | one seat, design |              | many seats on    |
  | until approval   |              | IMPLEMENTATION   |
  +------------------+              +------------------+

Use solo brainstorm when one seat and one pass are enough. Use brainstorming swarm when the design needs competing frames. Use build swarm when the design is already agreed and implementation can be divided.

Starting code while the design is still being negotiated defeats the reason for this pack. Stop and finish the design decision first.

How I made it

I already had a solo discipline: one question at a time, no code before the gate and a written design at the end. It helped stop an agent confidently building the wrong thing. What it did not provide was several competing frames at once.

I wanted discovery from different angles, approaches that did not copy one another mid-flight, and critique that could reject an approach without derailing the whole conversation. The conductor needed the findings in a form it could use.

That became five parts:

  • Stages and gates: a sequence, with Gate A and Gate B held by the human.
  • Roles: conduct, gather, draft, judge and synth, described independently of a vendor harness.
  • Lenses and axioms: replaceable cards, so the method can fit the domain.
  • Digest schemas: named fields and word caps for the returned work.
  • Dispatch rules: parallel work by default where available, with an explicit serial fallback.

The pack itself is plain Markdown. It needs no package manager and contains no telemetry mechanism. The host you run it in has its own data handling and capabilities.

The August V1 distribution was a versioned member zip. You load the skill and keep the resulting design in your repository. The site delivers the pack; the files carry the method. The later public V2 account describes a separate revision of the method.

Run a first design

1. Load the pack

Members can use the download at the end of this page, or the community skill surface when available. Unzip it and put the brainstorming-swarm folder where your agent loads skills.

2. Give it a bounded problem

Read SKILL.md and run brainstorming-swarm on: <goal>.
Prefer dispatch-first. Use serial fallback only if multi-seat is impossible.
Stop at a written design. Do not build.

3. Follow the stages

  1. S0, frame: state the goal and hard constraints. Bound the context; use digests for large read sets.
  2. S1, discover: send the separate lenses out, collect their digests and make a short summary.
  3. Gate A: redirect or approve the discovery before approaches start.
  4. S2, propose: develop competing approaches under different axioms. Defaults are mvp-first, risk-first and portability-first.
  5. S3, critique: kill, keep or salvage each approach.
  6. Gate B: you select a winner or a hybrid.
  7. S4, present: review the resulting design for approval.
  8. S5, write: save the approved design and halt. This skill does not begin implementation.

4. Hand the design to the next job

The written design can become the contract for a solo build or a build swarm. Save For Later, or another continuity tool, can retain the decisions and rejected options around it. Those records support the gate; they do not replace your decision.

If the problem is small, use the smaller method. If the design is settled, start the build process. Use this pack when several independent views could change what you decide to make.

Get the skill pack

[ comments ]

guests welcome. members show first in the list

no comments yet. start the thread_

1 / 9