Reusable team composition templates for common multi-agent workflows. Includes templates for research, review, refinement, implementation, and council teams, plus beads-teams bridge patterns.
Generates multi-agent teams for research, review, implementation, and other collaborative workflows using reusable templates.
npx claudepluginhub rbergman/dark-matter-marketplaceThis skill inherits all available tools. When active, it can use any tool Claude has access to.
Reusable team templates for common multi-agent workflows. Pick a template, adapt the roles, spawn the team.
| Role | Model | Responsibility |
|---|---|---|
| Investigator A | opus | Primary research angle |
| Investigator B | opus | Alternative angle, different sources |
| Devil's Advocate | opus | Challenge findings, look for gaps |
| Lead | — | Synthesize findings into report |
Use for: library evaluation, architecture research, debugging with competing hypotheses.
The value is in the tension between investigators. Investigator A builds the case, Investigator B explores alternatives, and the Devil's Advocate stress-tests both. The lead synthesizes — not by averaging, but by judging which evidence holds up under scrutiny.
| Role | Model | Responsibility |
|---|---|---|
| Architecture Reviewer | opus | SOLID, module boundaries, dependency direction |
| Code Reviewer | opus | Bugs, logic errors, test coverage, conventions |
| Security Reviewer | opus | Vulnerabilities, secrets, injection, auth |
| Lead | opus | Merge findings, resolve conflicts between reviewers |
Use for: PR review, pre-merge review, audit.
See dm-team:review for full implementation.
Reviewers may disagree — the architecture reviewer wants an abstraction layer, the code reviewer says YAGNI. The lead (opus) resolves these tensions with judgment, not compromise.
| Role | Model | Responsibility |
|---|---|---|
| Analyst | haiku | Surface ambiguity, formalize spec |
| Proposer | opus | Suggest simplifications and cuts |
| Advocate | opus | Challenge cuts, defend scope |
| Lead as Judge | opus | Synthesize final spec |
Use for: spec refinement, epic scoping.
See dm-team:refinement for full implementation.
The Analyst finds the holes. The Proposer tries to shrink scope. The Advocate pushes back when cuts go too deep. The lead judges which cuts improve the spec and which gut it.
| Role | Model | Responsibility |
|---|---|---|
| Module Owner A-D | opus | Each owns a distinct set of files |
| Lead | — | Coordinate dependencies, merge shared files, run quality gates |
Use for: parallel feature implementation, cross-layer changes.
CRITICAL: Assign non-overlapping file sets per teammate. File ownership collisions cause merge conflicts and wasted tokens. The lead owns any shared files (interfaces, types, configs) and distributes them after coordinating with owners.
Example file ownership split:
Owner A: src/api/**
Owner B: src/ui/**
Owner C: src/db/**
Lead: src/shared/**, package.json, tsconfig.json
| Role | Model | Responsibility |
|---|---|---|
| Perspective A-E | vary | Different viewpoints on a decision |
| Lead | — | Moderate debate, synthesize recommendation |
Use for: architecture decisions, trade-off analysis, spec review.
See dm-team:council for full implementation.
Use mixed models for epistemic diversity — different models emphasize different trade-offs. A haiku perspective often catches simplicity opportunities that larger models over-engineer.
| Role type | Recommended model | Why |
|---|---|---|
| Research / scouting | haiku | Fast, cheap, good for information gathering |
| Implementation / debate / review | opus | Highest quality for all substantive work |
| Synthesis / judgment | opus | Highest quality for final decisions |
Default to opus for all teammates doing substantive work (implementation, debate, review, analysis). Use haiku only for high-volume, low-stakes roles (scanning, listing, initial triage).
Beads tracks persistent issues across sessions. Agent Teams coordinates within a session. They complement each other.
# Before team creation — load beads into task list
bd ready --json | jq -r '.[] | .id + ": " + .title'
# → Create corresponding team tasks with bead IDs in descriptions
# During team work — teammates reference bead IDs
# Teammate messages: "Completed work for bead dark-matter-marketplace-abc"
# After team cleanup — sync back to beads
bd close <id1> <id2> ... --reason "Completed by team"
bd sync
Pattern: beads = persistent cross-session state, Agent Teams tasks = session-level coordination. Beads survive session boundaries; team tasks do not. Always sync results back to beads before the session ends.
bd ready to identify open beadsbd close completed beads with reasonbd sync to persist stateReusable spawn prompt fragments for composing team definitions. Each profile defines a role that can be dropped into any team template.
role: <role-name>
model: <haiku|sonnet|opus>
skills:
- <skill-1>
- <skill-2>
file_ownership:
- <glob-pattern>
success_criteria:
- <criterion-1>
- <criterion-2>
prompt_fragment: |
You are the <role-name>. Your job is to <responsibility>.
You own these files: <file_ownership>.
You succeed when: <success_criteria>.
Activate these skills: <skills>.
role: architecture-reviewer
model: opus
skills:
- dm-arch:adr
- dm-tool:mise
file_ownership: []
success_criteria:
- All module boundaries are clean
- Dependency direction is correct (inward)
- No SOLID violations in public interfaces
prompt_fragment: |
You are the Architecture Reviewer. Evaluate module boundaries,
dependency direction, and SOLID compliance. Flag violations with
severity (critical/warning/info). Do not review implementation
details — that's the Code Reviewer's job.
role: module-owner
model: opus
skills:
- dm-work:subagent
file_ownership:
- "src/api/**"
success_criteria:
- All owned files compile and pass lint
- Tests pass for owned modules
- No changes outside owned file set
prompt_fragment: |
You are a Module Owner. You own the files matching your assigned
glob patterns. Make changes ONLY within your owned files. If you
need changes to shared files, request them from the Lead. Run
quality gates on your files before reporting completion.
role: devils-advocate
model: opus
skills: []
file_ownership: []
success_criteria:
- At least 3 substantive challenges raised
- Each challenge includes a concrete failure scenario
- No strawman arguments
prompt_fragment: |
You are the Devil's Advocate. Your job is to find weaknesses in
the team's conclusions. For every finding, ask: "What if this is
wrong?" and "What are we missing?" Back challenges with concrete
failure scenarios, not vague concerns.
Compose teams by selecting profiles and wiring them into a team template. Adjust file ownership and success criteria per project.
Creating algorithmic art using p5.js with seeded randomness and interactive parameter exploration. Use this when users request creating art using code, generative art, algorithmic art, flow fields, or particle systems. Create original algorithmic art rather than copying existing artists' work to avoid copyright violations.
Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.
Create beautiful visual art in .png and .pdf documents using design philosophy. You should use this skill when the user asks to create a poster, piece of art, design, or other static piece. Create original visual designs, never copying existing artists' work to avoid copyright violations.