swarm-meeting

Inputs

• topic
• need
• profile name
• optional artifacts, constraints, decision owner, and timebox

swarm-research-pack

Ambiguous Input Assist

1. Infer

   balanced

   as the default profile unless the user clearly asks for stronger conflict or a deeper architecture review.
2. Infer a default

   need

   of

   options, objections, and recommendation

   when the user does not specify one.
3. Rephrase the likely topic from the active conversation or nearest artifact.
4. Show a short kickoff block before the meeting if key inputs are missing.

I can run this as a `balanced` swarm meeting.

- Topic: <inferred topic or "please provide one sentence">
- Need: options, objections, and recommendation
- Other profiles: `architecture-debate`, `extreme-diversity`

Examples:
- `Use the swarm-meeting skill. Topic: ... Need: ...`
- `Use swarm-meeting with profile: architecture-debate ...`

Workflow

1. Load exactly one profile from

   profiles/

   .
2. Load only the role prompts needed for that profile from

   prompts/

   .
3. Rephrase the decision in 1-2 sentences and define the agenda.
4. Collect independent role memos before synthesis. Keep each memo short: 3-7 bullets or short paragraphs.
5. Run the objection round if the profile requires it.
6. Force a recommendation, open questions, and concrete next actions.
7. Separate facts from inferences. Mark assumptions explicitly.

Guardrails

• Treat roles as evaluation biases, not personalities.
• Keep

  max_agents

  between 4 and 6 unless the user explicitly asks for a larger meeting.
• Prefer local role emulation by default. Only spawn subagents when the user explicitly asks for delegation or parallel agents, or when the environment clearly allows it.
• Do not let any single role dominate the summary.
• Avoid unbounded brainstorming. End with a decision or a clearly framed fork.
• If the user input is underspecified, provide the short assist block above, make one reasonable default assumption, and continue.

Output Contract

# Design Review
## Problem Statement
## Agenda
## Role Memos
## Options Considered
## Recommended Architecture
## MVP Plan
## Risks and Failure Modes
## Open Questions
## Concrete Next Actions

Resources

• profiles/balanced.yaml

  : default 5-role review for most implementation decisions.

• profiles/architecture-debate.yaml

  : stronger architecture pressure with semantics and platform concerns.

• profiles/extreme-diversity.yaml

  : intentionally conflicting evaluation axes for high-stakes tradeoffs.

• prompts/*.md

  : short role cards. Load only selected roles.

• references/prompt-examples.md

  : ready-to-copy invocation examples for common meeting intents.

• references/operating-rules.md

  : explicit rules for when to stay local versus when to spawn subagents.

• references/task-scoped-context-review.md

  : migrated example from the original one-off prompt.

• scripts/select_profile.py

  : recommend or inspect a profile without external dependencies.

• scripts/render_meeting_context.py

  : render a meeting brief from a profile plus topic, need, and artifacts.

Role Selection Rules

• Always include

  moderator

  .
• Include

  skeptic

  unless the user explicitly wants a fast, low-friction pass.
• Prefer

  pragmatist

  when delivery pressure is real.
• Prefer

  minimalist

  for MVP, operational simplicity, or "ship this week".
• Prefer

  maximalist

  for platform or long-horizon design.
• Prefer

  retrieval-architect

  when the topic involves search, indexing, code selection, Tree-sitter, LSP, or semantics.
• Prefer

  granary-workflow-lead

  when the topic involves task hubs, handoff, checkpointing, CLI flow, or session lifecycle.
• Prefer

  semantic-purist

  when correctness depends on type, symbol, or compiler information.
• Prefer

  lightweight-contrarian

  when a simple

  rg

  /diff/docs index may beat a heavy platform.
• Prefer

  context-economist

  when token budget, context pollution, or fresh-session strategy matters.
• Prefer

  workflow-conservative

  when tool sprawl is the main risk.