The team

• Issue ScoutPolls your real GitHub issues with `gh`, reproduces what it can in this workspace's own checkout, and writes up what it found.
• Scout Build ReviewThe whole pattern, saved once — your next repo gets the same team in minutes.
• BuilderFixes one issue, in its own workspace, with a test. Comments the branch back onto the real GitHub issue.
• ReviewerPushes back until it's satisfied, then opens the real pull request and links it from the issue. Nothing merges without you.
• BugfixesWhere the Scout lives. Every issue it reproduces gets its own child workspace and branch, so two fixes in flight never collide.

How it runs

1. The Scout finds a new issue overnight and reproduces it against your actual code.
2. It spins up a fresh workspace just for that fix, with its own branch, and hands it to a Builder.
3. The Reviewer reads the diff, asks for a regression test, and opens the real PR once satisfied.
4. You wake up to a finished pull request and a comment trail on the original issue — read it, merge it, done.

The team

• Jira ScoutCalls the Atlassian MCP server's Jira tools to find new bugs, reproduces what it can against the real repo, and comments progress back onto the real ticket.
• BuilderFixes the bug with a test, in its own branch, and comments the branch back onto the Jira ticket.
• ReviewerReviews the diff, opens the real pull request, and links it from the Jira ticket. Nothing merges without you.
• Jira BugfixesWhere the Scout lives. Every bug it reproduces gets its own child workspace and branch.

How it runs

1. A bug is filed in Jira. The Scout finds it on its next pass and reproduces it against real code.
2. It spins up a dedicated workspace for the fix and comments "in progress" back onto the ticket.
3. The Builder and Reviewer work the fix the same way Issue Triage does, entirely in GitHub.
4. The finished pull request links back to the Jira ticket, so both tools stay honest about where things stand — read it, merge it, done.

The team

• Release DrafterFinds every pull request merged since the last tag and turns real titles and diffs into a real draft — nothing invented.
• Release NotesAttach the real repo here. The draft and its history live in this workspace, not in your head the night before a release.

How it runs

1. The Drafter wakes on its schedule and checks what's merged since the last tag.
2. It groups the real pull requests into Added, Fixed, and Changed, and writes the draft into a file in the repo.
3. It posts the same draft into the workspace thread.
4. You read it, touch up anything that needs a human voice, and cut the release — that's the whole job left.

The team

• Email AccessA read-only IMAP login for the mailbox — the Scout can read it, never send, delete, or move anything.
• Zendesk AccessA Zendesk API token, so Support Triage can file real tickets.
• Inbox ScoutChecks the mailbox for new messages and starts a thread for each one — the same shape as pasting it in yourself.
• Support TriageReads each message and either files a real Zendesk ticket, or drafts an answer ready to send — never both, and never sent without you.
• Support InboxWhere every message lands, one thread each — from the Scout, or pasted in by hand.

How it runs

1. A message lands in the support mailbox.
2. The Inbox Scout finds it on its next pass and starts a thread for it here — no paste required.
3. Support Triage decides: bug, feature request, or answerable question.
4. A bug or request becomes a real Zendesk ticket with the link back to you; a question gets a drafted answer instead — read it, and send.

The team

• Stripe AccessA read-only key, scoped to just two read tools, registered with Stripe's own MCP server — nothing here can move money.
• Billing WatchdogCalls Stripe's MCP tools for new failed payments and disputes, and drafts what to say about each.
• BillingWhere the drafts land — dunning messages and dispute summaries, ready for you to read.

How it runs

1. A charge fails or a dispute opens in Stripe.
2. The Watchdog finds it on its next pass and drafts a direct message for the customer, or a summary if it's a dispute.
3. You read the draft in the workspace, touch up the tone if you want to, and send — that's the whole job.

The team

• Honeycomb AccessA read API key and dataset name, so the Scout can query your real traces.
• Error ScoutQueries production traces for exceptions new or spiking against their baseline, reproduces what it can, and hands each real one to its own fix workspace.
• BuilderFixes one error signature with a test, in its own branch, keeping the original trace link attached to the work.
• ReviewerReviews the diff and opens the real pull request. Nothing merges without you.
• Production ErrorsWhere the Scout lives. Every error it reproduces gets its own child workspace and branch.

How it runs

1. A new exception type starts showing up in production traces, or an existing one spikes.
2. The Error Scout notices it on its next pass, pulls a representative trace, and tries to reproduce it against the real repo.
3. A reproducible error gets its own workspace and branch; the Builder fixes it, the Reviewer checks it and opens the pull request.
4. You read a pull request whose description links straight back to the trace that caused it to exist — merge it, done.

The team

• Honeycomb AccessA read API key and dataset name, so the Monitor can query your real browser traces.
• UX MonitorCompares each route's Core Web Vitals against its own rolling baseline and names the pull requests most likely responsible for a regression.
• UX MonitoringWhere the report lands, one day at a time — the numbers and the suspect pull requests, side by side.

How it runs

1. A route's p75 largest-contentful-paint (or another vital) creeps past its own baseline.
2. The Monitor notices on its daily pass and lists what merged into that route's code in the same window.
3. It posts a ranked report in the workspace and opens a real GitHub issue tagged "performance" with the same findings.
4. You read a short list of suspects instead of starting a performance investigation from zero.

The team

• CuratorPeriodically rereads the mission, the finished work, and the feedback — and proposes what belongs on the list next.
• DispatcherWakes on its interval, finds the topmost untouched item, and hands it to the lead engineer workspace. Caps how much is in flight at once, and nudges stalled threads instead of piling on new ones.
• VerifierRuns the finished work, and only then checks the item off the roadmap and archives it.
• Lead EngineerScopes each item into a plan, then breaks it into child workspaces — one per deliverable, each with its own thread and worktree.
• MissionThe plain-language mission at the top, then the roadmap as a checklist. Items carry status tags as they move — untouched, in flight with a link to their thread, done.

How it runs

1. You add a line to the checklist and go to your meetings.
2. The Dispatcher hands it off and tags it with its thread, so anyone can see where it stands.
3. The lead engineer scopes it; child workspaces build it; the Verifier proves it works and checks it off.
4. The Curator notices what the finished work makes possible and drafts the next three items for your review.

The team

• Review CycleOn a cadence you choose, fans a review pass out to every persona workspace: walk the product's main journeys as this person, and say what grated.
• Product LeadWhere the findings converge — one thread per cycle, duplicates merged, the sharpest complaints on top.
• VoicesThe parent room: who your users are, and one child workspace per persona beneath it, each prompt a character study — their goals, their patience, their deal-breakers.

How it runs

1. The Review Cycle fires on Friday and hands each persona the same assignment.
2. The skeptic gets lost on step two; the power user wants a shortcut; the hurried one gives up at the signup form.
3. Their findings land with the product lead, synthesized into a ranked list.
4. Monday's roadmap conversation starts from evidence instead of instinct.

The team

• Email AccessA read-only IMAP login for the sales mailbox — the Scout can read it, never send, delete, or move anything.
• PricingWhat you charge for what — line items, ranges, and the caveats worth stating up front, so drafts stay consistent with each other.
• Follow-UpChecks threads with a sent quote and no reply after a few days, and drafts a short nudge instead of leaving it to go cold.
• Inbox ScoutChecks the mailbox for new messages and starts a thread for each request that looks like a job.
• EstimatorDrafts the quote from the real request and the Pricing domain — ready to review and send, never sent for you.
• QuotesWhere every request lands, one thread each — from the Scout, or pasted in by hand.

How it runs

1. A "how much would it cost to..." email lands in the sales inbox.
2. The Inbox Scout finds it on its next pass and starts a thread here — no paste required.
3. The Estimator drafts a quote from the real request and your stated pricing; you read it, adjust anything that needs a human touch, and send.
4. No reply after a few days? Follow-Up drafts a short nudge for that thread instead of the request quietly dying in your sent folder.

The team

• Stripe AccessA read-only key, scoped to just the invoice-read tools, registered with Stripe's own MCP server — nothing here can move money.
• Invoice WatchdogCalls Stripe's MCP tools for invoices past due and drafts a reminder for each, tuned to how overdue it is.
• InvoicingWhere the drafts land — one thread per overdue invoice, with the amount and the client attached.

How it runs

1. An invoice passes its due date unpaid in Stripe.
2. The Watchdog finds it on its next pass and drafts a reminder — polite the first week, more direct if it's been a month.
3. You read the draft in the workspace, touch up the tone if you want to, and send — that's the whole job.

The team

• Email AccessA read-only IMAP login for the booking mailbox — the Scout can read it, never send, delete, or move anything.
• Inbox ScoutChecks the mailbox for new messages and starts a thread for each one.
• Reschedule DeskReads each thread; a cancellation or reschedule request gets a drafted reply pointing back to your booking link, ready to send.
• BookingsWhere every booking-related message lands, one thread each.

How it runs

1. A customer emails to say they can't make their appointment.
2. The Inbox Scout finds it on its next pass and starts a thread here.
3. The Reschedule Desk recognizes the request and drafts a short reply with your booking link, so they can pick a new time themselves.
4. You read the draft, send it, and the slot gets rebooked without a phone call.

The team

• Email AccessA read-only IMAP login for the leads mailbox — the Scout can read it, never send, delete, or move anything.
• Service AreaWhat you actually take on — service area, job types, minimums — so triage can tell a real lead from a bad fit.
• Inbox ScoutChecks the mailbox for new messages and starts a thread for each inquiry.
• Lead TriageReads each inquiry against the Service Area domain and drafts a personal reply for a real lead, or a short decline for a bad fit — never sent without you.
• LeadsWhere every inquiry lands, one thread each, sorted as triage decides.

How it runs

1. Someone fills out the contact form, or emails in directly.
2. The Inbox Scout finds it on its next pass and starts a thread here.
3. Lead Triage checks it against what you actually take on and drafts a fast, specific reply — or a polite decline if it's not a fit.
4. You read the draft and send it, often before the lead has finished checking other options.