Claude Code Plugin · Automattic · 2026 Brito avatar

Brito.

Lead Systems Architect
& Task Orchestrator.

Give Brito an issue. It brainstorms, writes a spec, dispatches focused agents per repository, monitors completion, and reports back. Works with Linear or Jira. Pushes to GitHub or GitLab.

Multi-repo orchestration Linear & Jira GitHub & GitLab Workspaces Resumable

Concept

What is Brito?

A Claude Code plugin that turns a single issue into a fully orchestrated, multi-repository implementation — without human hand-holding.

🏗️

Orchestrator, not a doer

Brito breaks work down and dispatches focused agents. Each agent receives a precise implementation plan for one repository.

🔌

Bring your own tools

Linear or Jira for project management. GitHub or GitLab for git. Each workspace declares its providers and Brito resolves the right MCP tools at runtime.

🤝

Human-centric handoff

Brito never marks issues as Done. It moves work to "In Review" and stops. A human decides when the work is truly complete.

Named after Saturnino de Brito — a Brazilian pioneer of urban hydraulic engineering who designed infrastructure so reliable that success was the only possible outcome. Brito the plugin engineers the environment so agents can't fail: isolated worktrees, scoped tool permissions, precise plans, and a verification loop before every push.

Architecture

How it works

Five autonomous phases. Always resumable via your PM tool.

📋 Issue (Linear or Jira)

🔍 1. Brainstorm — deep codebase analysis

📝 2. Spec — per-repo plan, posted to issue

🚀 3. Dispatch — create sub-issues per repo

or

🖥️ 4a. Self Agent

local worktree · Claude Code

git push → PR / MR

🌐 4b. Remote Agent

external system · issue_assignment

posts PR/MR URL to sub-issue

🔁 5. Subissue-Worker — polls until all complete

✅ Parent issue → In Review

Multi-Provider

Workspaces

One config, multiple worlds. Each workspace declares its own PM tool, git provider, and projects.

Workspace: work

Linear GitHub 3 repos

Company projects using Linear for issue tracking and GitHub for code. Watcher runs on your work machine.

Workspace: personal

Jira GitLab 1 repo

Side projects using Jira and GitLab. Completely isolated — separate watcher process, PID file, and log.

How it resolves

1

Explicit flag

/brito PARSELY-123 --workspace=work

2

Team prefix auto-detection

/brito PARSELY-123 → scans all workspaces for team "PARSELY" → finds it in "work"

3

Single workspace default

If only one workspace is configured, it's used automatically. No flag needed.

Agent Types

Self & Remote Agents

Two execution models. Same contract: receive a plan, post a PR/MR URL when done.

Self Agent

Dispatch creates sub-issue labeled brito-self-agent

Self-listener claims it, creates an isolated git worktree

Launches a Claude Code session with scoped tool permissions

Session executes the plan, runs tests, pushes code

Creates PR (GitHub) or MR (GitLab) via the workspace's git CLI

Posts completion comment with PR/MR URL on the sub-issue

Config: agent: self

Remote Agent — e.g., agent-sandbox

Dispatch creates sub-issue assigned to agent-sandbox

External system detects the assignment via its own watcher

Reads the full plan from the sub-issue description

Executes autonomously: clone → branch → implement → test

Creates PR/MR and posts URL back on the sub-issue

Brito's subissue-worker detects the PR/MR URL and marks complete

An A8C sandbox agent focused on the wpcom repo. Runs independently, posts back results.

Configuration

Anatomy of brito.local.md

One global config at ~/.claude/brito.local.md — workspaces, providers, projects, repos.

---
workspaces:
  work:                                # workspace ID, used in --workspace flag
    name: "Automattic Work"
    pm:
      provider: linear                 # linear | jira
      mcp_server: "claude_ai_Linear"   # MCP prefix for tool resolution
      status_mapping:
        todo: "Todo"
        in_progress: "In Progress"
        in_review: "In Review"
    git:
      provider: github                 # github | gitlab (CLI auto-detected)
      default_base_branch: "main"
    projects:
      - name: "Parse.ly Platform"
        team: "PARSELY"              # matches issue prefix for auto-detection
        project_url: "https://linear.app/a8c/project/..."
        repositories:
          - name: "dash"
            url: "https://github.com/Parsely/dash"
            local_path: "~/dev/parsely/dash"
            agent: self              # local execution in worktree
          - name: "mage"
            agent:                    # remote execution
              type: "issue_assignment"
              assignee: "agent-sandbox"
              label: "brito-remote-agent"
---
    

Abstraction Layer

The Provider Contract

Skills never call MCP tools directly. They reference abstract operations. The contract resolves the actual tool names at runtime.

PM Tool Resolution

operation: save_comment

mcp_server: "claude_ai_Linear"

suffix: save_comment

→ mcp__claude_ai_Linear__save_comment

operation: save_comment

mcp_server: "jira_mcp"

suffix: add_comment

→ mcp__jira_mcp__add_comment

Git CLI Resolution

Provider	GitHub	GitLab
CLI	gh	glab
PR/MR	gh pr create	glab mr create
URL pattern	github.com/.../pull/	gitlab.com/.../merge_requests/

Adding a new provider means adding a row to the contract. No skill files change.

Design Principle

Your PM tool is the state store

No local JSON files. No SQLite. Everything lives in your issue tracker — which means everything is resumable, inspectable, and human-readable.

Comment signals Brito reads

[ag/Brito] self-agent started Lock — prevents a second session from picking up the same sub-issue

[ag/Brito] self-agent completed Completion signal — always includes the PR/MR URL for the subissue-worker to detect

[ag/Brito] self-agent failed Failure signal — subissue-worker marks the sub-issue failed and continues

approved / lgtm / +1 Human approval of the spec — Brito continues to dispatch phase

PR/MR URL in comment Detected via workspace's pr_url_pattern — completion signal for remote agents

Before you dispatch

The orchestration can't fix your repo.

You must make it agentic first. An agent is only as reliable as the feedback loops you give it.

🧪

Unit Testing

Agents need fast, granular feedback. Unit tests tell the agent exactly which function broke and why — without standing up the full stack. Cover edge cases, not just happy paths.

🔬

End-to-End Testing

Integration and E2E tests catch what unit tests miss: wiring errors, API contract mismatches, database migrations. An agent that can't run E2E tests is working blindfolded.

👁️

Manual Testing Hooks

Give agents a way to spin up a local environment and verify behavior visually. A dev:start script and a clear AGENTS.md tell the agent how to test its own work.

✅

Verification Loop

Before pushing, the agent must run all tests, check for lint errors, and confirm acceptance criteria from the plan. Brito uses the verification-before-completion skill — it refuses to push until checks pass.

The rule: if you can't tell a human how to verify that a change works in under 2 minutes, your agent can't either. Write the verification steps down in AGENTS.md — that file is the agent's operating manual.

Claude Code Plugin · Automattic

Brito.

Give it an issue. Walk away.

Brito is an internal Automattic tool. It is opinionated, always evolving, and built around the principle that the best orchestration is the one you never have to babysit.

claude-code-plugins Linear github.com/djalmaaraujo