metaswarm Documentation

repository·main·Indexed 18 days ago

https://github.com/dsifry/metaswarm

A self-improving multi-agent orchestration framework for Claude Code, Gemini CLI, and Codex CLI. metaswarm automates the software development lifecycle using 18 specialized agent personas, a hierarchical orchestration model, and the BEADS JSONL-based knowledge base for selective retrieval and learning. It includes tools for cost estimation, PR comment verification, and cross-platform installation via npx.

Tokens
135.1K
Snippets
309
Records
561
Agent score
62%

What's inside metaswarm

  1. Overview of the Plugin Migration Plan

    main

    The plugin migration plan for metaswarm involves transitioning to a new plugin infrastructure. This migration includes the introduction of plugin.json manifests, a hooks infrastructure, and a restructuring of skills.

    Key changes include:

    • New Skills: setup, migrate, and status are added. The start skill is restructured (moved from ORCHESTRATION.md).
    • New Commands: brainstorm, external-tools-health, setup, update, and status.
    • Directory Changes: Skill directories are being renamed from beads/ to start/. Note that the .beads/ project-local directory remains unchanged.
    • Infrastructure: Implementation of plugin.json manifests and a hooks system (e.g., hooks.json).
  2. What is the pr-shepherd skill?

    main

    The pr-shepherd skill is used to monitor a Pull Request (PR) from creation through to merge. It is designed to be run by an agent working in a worktree, rather than the orchestrator, allowing the agent to autonomously handle CI failures, review comments, and thread resolution.

    It supports two coordination modes:

    • Task Mode (default): Runs as a single long-running Task() with run_in_background: true. The orchestrator monitors progress via TaskOutput(block: false).
    • Team Mode: Runs as a persistent shepherd teammate in the issue-{number} team, sending async status updates (e.g., CI failure, review comments, PR merged) via SendMessage.
  3. Overview of metaswarm Agents

    main

    metaswarm utilizes 18 specialized agents categorized by their role in the software development lifecycle. These agents can be used to automate everything from high-level orchestration to specific tasks like security auditing or PR management.

    Agent Categories

    • Orchestration Agents: Manage parallel work and issue decomposition (e.g., Swarm Coordinator, Issue Orchestrator).
    • Research & Planning Agents: Handle codebase exploration and design (e.g., Researcher, Architect, Product Manager, Designer, Security Design, CTO).
    • Implementation Agents: Execute code changes and testing (e.g., Coder, Test Automator).
    • Review Agents: Perform quality and security checks (e.g., Code Reviewer, Security Auditor).
    • PR & Delivery Agents: Manage the pull request lifecycle (e.g., PR Shepherd).
    • Support Agents: Handle auxiliary tasks like knowledge management, metrics, Slack notifications, SRE, and customer service.
  4. Enforce Adversarial Reviewer Isolation

    main

    This is the most important invariant in the coordination system.

    Adversarial reviewers MUST be fresh Task() instances on EVERY review pass, regardless of whether you are using Task Mode or Team Mode.

    The Rule

    • ALWAYS use a fresh Task() instance.
    • NEVER use a teammate as a reviewer.
    • NEVER resume a previous agent for a review.
    • NEVER provide previous review findings or prior context to the reviewer.
    • A new reviewer must see ONLY: the spec, DoD (Definition of Done) items, and the git diff.

    Why

    This prevents anchoring bias, where a reviewer unconsciously checks for previously-found issues instead of reviewing the work independently. After a FAIL $\rightarrow$ fix $\rightarrow$ re-validate cycle, the next reviewer must have zero memory of prior reviews.

  5. Apply MC/DC for compound boolean logic

    main

    When a function uses compound boolean expressions (e.g., A && B || C), standard branch coverage is insufficient. Use Modified Condition/Decision Coverage (MC/DC) to ensure each individual condition independently affects the outcome.

    When to use MC/DC:

    • Authorization/RBAC guards
    • Eligibility/business rules (status, feature flags, tiers)
    • Validation logic (multi-field validation)
    • State machine transitions

    The Pattern: Baseline + Toggle Each Condition

    1. Baseline: Test where all conditions are true (result is expected to be true).
    2. Toggles: Create one test for each condition where that specific condition is changed to make the expression false, while keeping all other conditions true.
    describe("canPerformAction -- MC/DC", () => {
      // Baseline: all conditions true -> allowed
      it("allows when all conditions met", () => {
        const result = canPerformAction(
          createMockUser({ role: "ADMIN" }),
          createMockOrganization({ tier: "PRO", suspended: false })
        );
        expect(result).toBe(true);
      });
    
      // Toggle role alone -> denied
      it("denies when non-admin (other conditions true)", () => {
        const result = canPerformAction(
          createMockUser({ role: "MEMBER" }),
          createMockOrganization({ tier: "PRO", suspended: false })
        );
        expect(result).toBe(false);
      });
    
      // Toggle tier alone -> denied
      it("denies when free tier (other conditions true)", () => {
        const result = canPerformAction(
          createMockUser({ role: "ADMIN" }),
          createMockOrganization({ tier: "FREE", suspended: false })
        );
        expect(result).toBe(false);
      });
    
      // Toggle suspended alone -> denied
      it("denies when suspended (other conditions true)", () => {
        const result = canPerformAction(
          createMockUser({ role: "ADMIN" }),
          createMockOrganization({ tier: "PRO", suspended: true })
        );
        expect(result).toBe(false);
      });
    });
  6. Use Task Mode for baseline coordination

    main

    Task Mode is the default coordination mechanism. It uses fire-and-forget Task() subagents. It is always available and requires no special tooling.

    Workflow

    1. The Orchestrator spawns a subagent via Task() with full context in the prompt.
    2. The Subagent executes independently with no cross-agent communication.
    3. The Subagent returns the result to the orchestrator.
    4. The Orchestrator proceeds to the next step.

    Characteristics

    • Cold Starts: No persistent state between subagent invocations; every call is a fresh start.
    • Sequential Handoffs: All communication must go through the orchestrator (e.g., Researcher $\rightarrow$ Orchestrator $\rightarrow$ Architect).
    • Parallelism: Parallel work is achieved using multiple parallel Task() calls.

    When to use Task Mode

    Task Mode is sufficient for most workflows unless you encounter high overhead from frequent cold starts, such as:

    • An agent working across many sequential work units.
    • Design reviews requiring many iteration cycles.
    • A PR shepherd needing to persist through a long lifecycle.
  7. Classify issues as BLOCKING or WARNING

    main

    Issues identified during an adversarial review are classified into two categories that determine the final verdict:

    • BLOCKING: Represents a contract violation (e.g., the spec requires X, but the code does Y). A single BLOCKING issue results in a FAIL verdict.
    • WARNING: Represents a quality concern that does not violate the specification. WARNINGS do NOT cause a FAIL verdict.

    Rule of thumb: When in doubt, classify the issue as BLOCKING. The threshold for a PASS should be high.

  8. Use the Orchestrated Execution skill

    main

    Orchestrated Execution is a 4-phase execution loop designed for rigorous, spec-driven implementation. It follows the pattern: IMPLEMENTVALIDATEADVERSARIAL REVIEWCOMMIT.

    Key features include:

    • Plan validation (pre-flight): Uses a checklist to catch structural issues (architecture, dependencies, API contracts, etc.) before design review.
    • Work unit decomposition: Breaks plans into discrete units with DoD items, file scopes, and dependency graphs.
    • Independent validation: The Orchestrator runs tsc, eslint, and vitest directly rather than trusting subagent self-reports.
    • Quality gate enforcement: Gates are blocking; a FAIL requires a retry or escalation.
    • Coverage enforcement: Reads .coverage-thresholds.json and runs enforcement commands as a blocking gate.
    • Adversarial review: A fresh reviewer checks each DoD item using adversarial-review-rubric.md with file:line evidence.
    • Human checkpoints: Planned pauses at critical boundaries (schema, security, etc.).
    • Project context document: Maintained by the orchestrator and passed to subagents to prevent context loss.
    • Service inventory tracking: Updates SERVICE-INVENTORY.md after each commit.
    • Recovery protocol: DIAGNOSECLASSIFYRETRY (max 3) → ESCALATE.
  9. Compare Task Mode and Team Mode for agent coordination

    main

    Metaswarm provides two primary modes for agent coordination: Task Mode and Team Mode. Choosing between them depends on the complexity of the work item (WU) and the required level of context retention.

    Task Mode (Default)

    Task Mode is a 'fire-and-forget' approach where agents are instantiated for a specific task and then discarded.

    • Availability: Always available.
    • Context: No context retention; every task is a 'cold start'.
    • Communication: Agents communicate only via the orchestrator.
    • Best for: Simple issues or single work items (WU).
    • Overhead: Zero (uses existing behavior).

    Team Mode (Enhanced)

    Team Mode creates persistent teammates that maintain context across multiple work items.

    • Availability: Requires TeamCreate and SendMessage capabilities to be available.
    • Context: Context is retained across different work items.
    • Communication: Supports direct SendMessage between agents.
    • Best for: Multi-WU tasks or iterative review processes.
    • Overhead: Requires team setup and teardown procedures.
    FeatureTask ModeTeam Mode
    Agent lifecycleFire-and-forgetPersistent teammates
    Context retentionNone (cold start)Retained across work items
    CommunicationVia orchestrator onlyDirect SendMessage
    Adversarial reviewerFresh Task() (natural)Fresh Task() (enforced)
    BEADS updatesSubagent directOrchestrator only
    Team TaskList bridgingNot neededRequired
    OverheadZeroTeam setup/teardown
    +---------------------------+----------------------------+----------------------------+
    |                           |       TASK MODE            |       TEAM MODE            |
    +---------------------------+----------------------------+----------------------------+
    | Availability              | Always                     | When TeamCreate +          |
    |                           |                            | SendMessage available      |
    +---------------------------+----------------------------+----------------------------+
    | Agent lifecycle           | Fire-and-forget            | Persistent teammates       |
    +---------------------------+----------------------------+----------------------------+
    | Context retention         | None (cold start each)     | Retained across work items |
    +---------------------------+----------------------------+----------------------------+
    | Communication             | Via orchestrator only      | Direct SendMessage         |
    +---------------------------+----------------------------+----------------------------+
    | Adversarial reviewer      | Fresh Task() (natural)      | Fresh Task() (enforced)    |
    +---------------------------+----------------------------+----------------------------+
    | BEADS updates             | Subagent direct            | Orchestrator only          |
    +---------------------------+----------------------------+----------------------------+
    | Team TaskList bridging    | Not needed                 | Required (see Section 5)  |
    +---------------------------+----------------------------+----------------------------+
    | Overhead                  | Zero (existing behavior)   | Team setup/teardown        |
    +---------------------------+----------------------------+----------------------------+
    | Best for                  | Simple issues, single WU   | Multi-WU, iterative review |
    +---------------------------+----------------------------+----------------------------+
  10. How context packaging handles token budgets

    main

    To prevent issues like the Codex 10KB file truncation, the package_context() helper manages token budgets using the following logic:

    • Estimation: Uses a chars/4 heuristic to estimate token counts per file.
    • Prioritization: Prioritizes content in this order: changed files > test files > imports > surrounding context.
    • Truncation: Truncates content to the model's specific context budget (which is configurable per adapter).
    • Retry Logic: On a retry, it includes a summary of the review feedback rather than the full prior output.
    • Escalation Logic: On escalation, it includes a summary of the prior branch diff rather than the full branch.
  11. Use Orchestrated Execution for complex tasks

    main

    When a task has a written specification with Definition of Done (DoD) items, use orchestrated execution instead of simple task flows. This mode is designed for multi-unit features, risky changes, or tasks requiring high verification.

    The orchestrator breaks the plan into work units and executes a 4-phase loop:

    1. IMPLEMENT
    2. VALIDATE (Independent validation via tests and type checks)
    3. ADVERSARIAL REVIEW (A fresh reviewer checks DoD items with file:line evidence using binary PASS/FAIL criteria)
    4. COMMIT

    Key Features:

    • Independent validation: The orchestrator runs its own tests and does not trust the coding agent's self-report.
    • Fresh reviewers: If a review fails, a new reviewer is spawned with zero memory of the previous review.
    • Human checkpoints: The process pauses at critical boundaries (e.g., schema changes, security code) for manual review.

    When NOT to use: Single-file fixes, quick prototypes, or tasks without a clear spec.

  12. Understand the BEADS Agent Roster

    main

    The BEADS orchestration skill uses a swarm of specialized agents. Each agent is spawned at specific lifecycle stages of a GitHub issue:

    AgentRoleSpawned When
    Issue OrchestratorMain coordinatorIssue receives agent-ready label
    Researcher AgentCodebase explorationOrchestrator creates research task
    Architect AgentImplementation planningResearch complete
    Product Manager AgentUse case & benefit reviewDesign review gate (parallel)
    Designer AgentUX/API design reviewDesign review gate (parallel)
    Security Design AgentSecurity threat modelingDesign review gate (parallel)
    CTO AgentTDD readiness & plan reviewDesign review gate (parallel)
    Coder AgentTDD implementationDesign review approved
    Code Review AgentInternal code reviewImplementation complete
    Security AuditorSecurity review (code)Implementation complete
    Release Engineer AgentSafe delivery/productionQA approves PR, PR reaches merge readiness
    PR ShepherdPR lifecycle managementPR created