Build a coordinated team of AI agents as a single, installable MyClaude product.

A squad is the most powerful product type on the marketplace. Where a skill gives Claude one capability and an agent gives Claude one persona, a squad gives Claude an entire team — multiple agents with distinct roles, coordinated by routing logic and connected by handoff protocols. Buyers install the squad and get the whole team in one command.

This tutorial walks through building a real, useful squad: a 3-agent code review team. By the end you will have a published product that buyers can install and invoke immediately.

What is a squad?

A squad is a SQUAD.md file that defines multiple agents, how they coordinate, and when each agent takes over. When a buyer invokes a squad, Claude reads the SQUAD.md and understands it as a team briefing — here are the roles, here is the workflow, here is how agents hand off to each other.

Think of it this way: if a skill is a specialist you hire for one task, a squad is a consultancy you bring in for a complete engagement. The squad handles coordination internally — the buyer just describes what they need.

Squad file structure

A squad at its simplest is two files:

my-squad/
  SQUAD.md       # Coordination logic, roles, handoffs
  vault.yaml     # Product manifest

Larger squads can include supplementary files:

my-squad/
  SQUAD.md              # Main coordination file
  vault.yaml            # Product manifest
  README.md             # Usage documentation
  agents/               # Optional: detailed agent definitions
    reviewer.md
    security-auditor.md
    style-checker.md

The supplementary agent files are optional. For squads with 2-4 agents, defining everything in SQUAD.md is cleaner. For squads with 5+ agents, splitting agent definitions into separate files keeps SQUAD.md focused on coordination.

Build a code review squad

Let's build a 3-agent code review squad. The agents: a general reviewer who catches bugs and logic errors, a security auditor who finds vulnerabilities, and a style checker who enforces consistency. They work in sequence — security first, then correctness, then style.

Step 1 — Scaffold the project

$ myclaude init code-review-squad --category squad
$ cd code-review-squad

This creates SQUAD.md and vault.yaml. Open both.

Step 2 — Define the roles

Open SQUAD.md and replace the scaffolded content with your squad definition. Start with the roles section.

# Code Review Squad

A three-agent team for production-grade code review. Security vulnerabilities
first, correctness second, style third. Sequential execution with structured
handoff between agents.

## Roles

### Agent 1: Security Auditor

**Trigger:** Always runs first on any code review request.

**Responsibilities:**
- Identify authentication and authorization vulnerabilities
- Flag injection risks (SQL, XSS, command injection, path traversal)
- Check for data exposure (secrets in code, sensitive data in logs, PII leaks)
- Verify input validation and sanitization
- Check dependency versions for known CVEs

**Output format:**
For each finding:
- Severity: CRITICAL / HIGH / MEDIUM / LOW
- Location: file:line
- Vulnerability: one sentence
- Fix: concrete code suggestion
- Reference: CWE or OWASP identifier if applicable

If no security issues found, output: "Security audit passed. No vulnerabilities detected."

**Constraints:**
- Do NOT comment on style, naming, or non-security code quality
- Do NOT suggest security improvements that are not addressing an actual risk
- When in doubt about severity, err toward higher severity

---

### Agent 2: Correctness Reviewer

**Trigger:** Runs after Security Auditor completes.

**Responsibilities:**
- Identify logic errors, off-by-one mistakes, null/undefined handling gaps
- Check error handling: are errors caught, logged, and reported appropriately?
- Identify performance issues: O(n^2) patterns, unnecessary allocations, missing
  memoization, N+1 queries
- Verify edge cases: empty inputs, boundary values, concurrent access
- Check that functions do what their names and docs claim

**Output format:**
For each finding:
- Severity: CRITICAL / HIGH / MEDIUM / LOW
- Location: file:line
- Issue: one sentence
- Fix: concrete code suggestion

If no issues found, output: "Correctness review passed. Logic looks sound."

**Constraints:**
- Do NOT re-flag issues already identified by the Security Auditor
- Do NOT comment on style or naming conventions
- Focus on correctness, not cleverness

---

### Agent 3: Style Checker

**Trigger:** Runs after Correctness Reviewer completes.

**Responsibilities:**
- Check naming consistency (casing conventions, descriptive names)
- Verify code formatting matches project conventions
- Identify dead code, unused imports, commented-out blocks
- Check documentation: do public functions have adequate comments?
- Verify consistent patterns: if the codebase uses pattern X, new code should too

**Output format:**
For each finding:
- Severity: MEDIUM / LOW / SUGGESTION
- Location: file:line
- Issue: one sentence
- Fix: concrete suggestion

If no issues found, output: "Style check passed. Code is consistent."

**Constraints:**
- Do NOT flag style choices that are merely different from your preference
- Only flag patterns that are inconsistent with the existing codebase
- Keep severity realistic: style issues are never CRITICAL

Notice the pattern: each role has a clear trigger, defined responsibilities, a specified output format, and constraints that prevent overlap. The constraints are critical — without them, agents step on each other's work and produce redundant output.

Step 3 — Write coordination logic

After the roles, add the coordination section that tells Claude how to route work and pass context between agents.

## Coordination

### Execution model: Sequential

Agents execute in fixed order: Security Auditor -> Correctness Reviewer -> Style Checker.
This order is non-negotiable. Security must be evaluated before anything else.

### Handoff protocol

When one agent completes, it passes the following to the next agent:

1. **Its complete output** (all findings or the "passed" message)
2. **A summary line:** "Security Auditor found N issues (X critical, Y high, Z medium, W low)"
3. **Files reviewed:** list of files and line ranges examined

The next agent MUST:
- Read the previous agent's output before starting
- NOT duplicate findings from previous agents
- Reference previous findings if building on them ("Security Auditor flagged
  the input at line 42 — additionally, the parsing logic here has an off-by-one error")

### Aggregate report

After all three agents have run, produce a combined report:

============================================ CODE REVIEW SQUAD — Aggregate Report

Files reviewed: [list] Total findings: N

CRITICAL (N): [security and correctness findings]

HIGH (N): [security and correctness findings]

MEDIUM (N): [all agent findings]

LOW / SUGGESTION (N): [correctness and style findings]

Summary: [1-2 sentence overall assessment]

### When the squad should NOT be used

- For generating new code (this squad reviews, it does not write)
- For explaining code to someone (invoke a teaching-focused product instead)
- For reviewing non-code files (documentation, configuration, design)

### Escalation rules

If the Security Auditor finds a CRITICAL vulnerability:
- Flag it immediately in the aggregate report header as "CRITICAL — Requires immediate attention"
- The Correctness Reviewer and Style Checker still run, but the aggregate report
  leads with the critical security finding

Step 4 — Configure vault.yaml

Open vault.yaml:

name: code-review-squad
version: "1.0.0"
category: squad
description: "3-agent code review: security audit, correctness check, and style enforcement in sequence."
author: your-username
license: MIT
price: 0
tags: [code-review, security, quality, multi-agent]

A few notes on squad-specific decisions:

Pricing. Squads are inherently higher-value than skills because they coordinate multiple capabilities. A free v1 makes sense to gather downloads and feedback. Price the v2 after you know what users value. For reference, well-reviewed squads on the marketplace price between $19 and $79 depending on complexity and domain.

Tags. Include multi-agent or a similar tag so buyers searching for team-based products find yours. Also include the domain tags (code-review, security) for category-specific searches.

Description. Keep it under 160 characters. Mention the agent count and the primary value. Buyers scanning search results need to immediately understand what the squad does.

Step 5 — Test locally

Install your squad locally and test it on real code:

$ myclaude install --local .

Open a Claude Code session and invoke the squad on a real file or diff:

/code-review-squad

Review the changes in the current git diff.

Watch what happens. Evaluate:

• Does the sequential order work? Security should report first, then correctness, then style.
• Is there overlap? If the correctness reviewer re-flags security issues, tighten the constraints.
• Is the aggregate report clear? The combined output should be scannable — a developer should find the critical issues in seconds.
• Does the handoff protocol work? Each agent should acknowledge what the previous agent found.

Iterate on SQUAD.md until the output is something you would trust to review your own production code.

Step 6 — Publish

$ myclaude publish

Validating vault.yaml... OK
Scanning content... OK
Uploading files... OK
Creating listing... OK

Published: myclaude.sh/p/your-username-code-review-squad

Buyers install with:

$ myclaude install @your-username/code-review-squad

SQUAD.md anatomy

Every SQUAD.md should have these sections. All of them matter.

Roles section

Define each agent as a distinct role with:

• Trigger condition: When does this agent activate?
• Responsibilities: What exactly does this agent do? Be exhaustive.
• Output format: What does the agent's output look like? Specify the structure.
• Constraints: What should this agent NOT do? This prevents overlap.

The most common squad problem is agent overlap — two agents flagging the same issue differently. Constraints are your primary tool for preventing this. Write them explicitly: "Do NOT comment on style" in the correctness reviewer, "Do NOT re-flag security issues" in the style checker.

Coordination section

Define how agents work together:

• Execution model: Sequential (one after another), parallel (all at once), or conditional (route based on input).
• Handoff protocol: What information passes between agents? Be specific about format.
• Aggregate report: How are individual agent outputs combined into one deliverable?

Sequential execution is the simplest and most reliable. Parallel works for agents with zero overlap (e.g., a frontend reviewer and a backend reviewer operating on different files). Conditional routing is the most complex — use it when different inputs require entirely different agent combinations.

Exclusion section

When should the squad NOT be used? This is as important for squads as it is for skills. A squad invoked on the wrong task produces confusing multi-agent output that wastes the buyer's time.

Escalation rules

What happens when an agent finds something critical? Does the squad stop and report immediately? Does it continue and flag the critical finding prominently? Define this explicitly — the default behavior without guidance is unpredictable.

Best practices

Keep squads focused. A 3-agent squad that does code review well outsells a 10-agent squad that does everything vaguely. The value of a squad is coordination quality, not agent count.

Define clear handoff points. The handoff protocol is the most important part of SQUAD.md. If agents cannot reference what previous agents found, the squad is just three skills running in sequence — and the buyer could do that without your product.

Test with real-world inputs. The difference between a good squad and a great one is how it handles messy, real-world code — not clean examples. Test with large diffs, mixed languages, legacy code with no comments, and code that is actually fine (the squad should say so).

Start sequential, move to parallel. Sequential execution is easier to debug and produces more coherent output. Only introduce parallel execution when you have proven the agents do not need each other's context.

Version your coordination model. When you update a squad, the coordination logic is the most fragile part. A new agent role can break existing handoff protocols. Test the full pipeline after every change.

Pricing guidance

Start free. Get feedback. Price the v2 based on what users actually tell you is valuable — it is often not what you expect.

Related pages

• Writing Skills Guide — if your squad would be simpler as a single skill, start there
• Building Agents — understand agents before combining them into squads
• vault.yaml Specification — squad-specific vault.yaml fields
• MCS Certification — squad MCS requirements by tier
• Product Categories — all product types and their file structures