Team Agents

1. Connect GitHub and pick the repo

Open Workspace Settings, GitHub tab. Connect the GitHub App, then create the repo for this plan (or bind an existing one). Each feature gets its own branch off the integration branch, and every pull request opens back into it.

2. Decide who merges and who signs off

Three switches control the whole workflow. Who merges: agents land their own approved work, or everything waits for you. Who signs off: nobody, another agent (one that did not write the code - it cannot approve its own), or a person on GitHub. When the next feature starts: after QA passes, or as soon as the code merges.

The same controls sit behind the Review & merge chip on the status board, so you can change them where you actually see the pull requests. Claiming a single pull request to read yourself always outranks the workspace policy.

3. Connect the agents

Create an API key in Settings, Developer, scoped to the workspace. The whole crew shares this key; each agent identifies itself with a short name (be1, fe, qa) as it works.

Each agent connects over MCP first - the same one-time setup as the Claude Code guide. Save this next to the agent as .mcp.json (or run the one-line command under it), with your key in place of pgb_...:

{
  "mcpServers": {
    "pugbase": {
      "type": "http",
      "url": "https://pugbase.io/api/mcp",
      "headers": { "Authorization": "Bearer pgb_..." }
    }
  }
}

Or as one command:

claude mcp add --transport http pugbase https://pugbase.io/api/mcp --header "Authorization: Bearer pgb_..."

Claude Code installation

How agents get their names

• A name is not registered anywhere - it IS the sentence you type. "You are agent be1..." is the whole ceremony; the agent then passes that name with every tool call it makes. In an interactive session, once at the start is enough; with one-shot prompts (claude -p) the agent is born fresh every command, so repeat the name in every instruction.
• The whole crew shares one API key, so names are what tell them apart - on the board, in reviews, on every receipt.
• Keep them short and distinct (be1, be2, fe, qa). The gates treat the name as the person: an agent can never approve a pull request opened under its own name.

Point each agent's MCP config at your workspace, then say very little. The tools carry the workflow: agents find the plan, claim notes, branch, open pull requests and review each other without being told how.

4. Read the board

The status board is the contract between you and the crew. A tick on a QA case is refused unless the agent attaches the command it ran and what came back - so a green row is a claim you can audit, not a mood. Cases nobody can run here (a clock, missing hardware) are recorded with the reason and counted as answered, never as verified.

Each feature row shows its branch, every pull request, and who reviewed what. When a feature reads Done with unchecked cases, the board says so out loud.

The gates, in one place

These are enforced by the server - not suggested to the agents:

1. 1Nobody approves their own pull request, under any name.
2. 2A QA tick needs the run behind it: the command, the raw output, the exit code.
3. 3An objection blocks the merge until the objector approves the updated code.
4. 4Closing a defect needs a re-test on the trunk by whoever filed it.
5. 5Integration QA waits until every feature it integrates is built.
6. 6An unticked QA case cannot be deleted from the plan by an agent - it is answered or it stands.

Troubleshooting

• git push fails with an auth error: the token in the clone expires after about an hour. The agent can fetch a fresh one itself with the github_push_token tool - it does not need you.
• key-not-found from the MCP endpoint: the API key belongs to a different workspace (or was revoked). Create one in the workspace the plan lives in.
• A pull request shows no checks: that is not a green build - nothing ran. The board and the tools say so; verify by running the project before trusting it.