--- name: launch-data-team description: Spawn the Gemma data team as an agent team (Data Engineer, Analytics Engineer, Data Analyst, QA auditor, ticket-fetcher) for the current repo and drain a backlog of tickets on demand. disable-model-invocation: true argument-hint: "[repo path or task scope]" --- # Launch the Gemma data team Spins up a full data team as a Claude Code **agent team** in the current session. The session you run this from becomes the **lead** (the orchestrator / project manager): it holds the shared task list, distributes work, runs the QA gate, and synthesizes results. `$ARGUMENTS` may name the target repo path and/or the scope of work (e.g. "current sprint", "open tickets assigned to the data team"). ## Prerequisites (check first, stop if unmet) 1. **Agent teams enabled.** `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` must be set (in `~/.claude/settings.json` `env` or the environment) and the session started fresh afterwards. If it isn't set, tell the user to add it and restart — you cannot spawn teammates without it. 2. **Connection mode.** Check the SessionStart banner. Data tasks can only be *completed* on **Bedrock** (the QA gate blocks completion on the Anthropic API). If the user wants tasks driven to done, recommend launching on Bedrock (`claude-db` / `bedrock-on`). On the Anthropic API the team can still plan, author code, and `dbt compile`/`parse`, but completion will block. 3. **Companion plugins installed.** The data team composes with the rest of the Gemma agentic toolkit rather than vendoring their content. Confirm the relevant plugins are enabled before spawning teammates who depend on them: | Plugin | Used by | What it provides | |---|---|---| | `gemma-dbt` | **AE, QA** (required) | `validate-repo` (QA baseline), `create-source-file`, `create-base-models`, `comment-unused-fields`, `base-models-comment-piis`, `dbt-docs-search` | | `gemma-prs` | **All roles** (required) | `review-pr`, `review-pr-extensive`, `implement-pr-comments` | | `gemma-kimball` | **AE** | `kimball-expert`, `kimball-designer`, `kimball-interviewer` agents for dimensional modelling | | `gemma-dlt` | **DE** | `create-dlt-connector`, `add-dlt-rest-api-source`, `run-dlt-connector`, `debug-dlt-connector`, `containerize-dlt-connector`, `contribute-dlt-connector` | | `gemma-airflow` | **DE** | DAG creation, scheduling, operator conventions | | `gemma-ewah-migration` | **DE** | EWAH → dlt migration toolkit | | `gemma-lightdash` | **DA, AE** | `developing-in-lightdash` (charts/dashboards/CLI), `lightdash-semantics` (`meta:` blocks in schema.yml) | | `gemma-metabase` | **DA** | Metabase API, dashboard authoring, screenshots, visual QA | | `gemma-1password` | **Lead** (when fetching tickets/credentials) | `op` CLI usage for secret retrieval | The teammates **invoke these via the `Skill` tool** — they do not re-implement the procedures. If an expected skill is missing from a teammate's session, they'll surface it; install the plugin and respawn the teammate. 4. **PM tool connectivity** (only if fetching tickets) — confirm a ClickUp/Asana/Notion/Jira MCP server or API token is available; otherwise the ticket-fetcher will ask which tool to use. ## How to run the team 1. **Set the repo context.** Confirm the target repo (from `$ARGUMENTS` or ask). Read its `CLAUDE.md` so you and the teammates inherit project conventions. 2. **Fetch the backlog (optional).** If the user wants tickets pulled, spawn the **`ticket-fetcher`** teammate. The fetcher is **not** allowed to do credential-bearing I/O itself (peer sessions' auto-mode classifier blocks `op read` and credentialed HTTP); the **lead** runs `op read` and the initial PM-tool API calls in main and hands the fetcher the raw ticket data via `SendMessage`. The fetcher classifies by discipline (`de`/`ae`/`da`/`ds`/`qa`), splits cross-discipline tickets into subtasks with dependency edges, **carries each ticket's native priority (`prio:`) and due date (`due:`)**, and writes them to the shared task list. Don't bounce the fetcher back to "go fetch the secret yourself" — that's permission laundering and the classifier will refuse again. If the user is handing you work directly, skip this and create the tasks yourself. **New work that lives in meeting notes** (Fireflies / Gemini / personal notes) doesn't reach the PM tool on its own. To capture it, either spawn the **`note-scout`** teammate (it reads the project's notes, distils + scrubs action items into ticket drafts, and hands them back for you to post — same credential boundary as the fetcher) or run the **`/capture-tickets-from-notes`** skill yourself in main. Posted tickets then flow back through the `ticket-fetcher` on its next run, so the PM tool stays canonical. 3. **Spawn the doers.** Spawn the **`data-engineer`**, **`analytics-engineer`**, **`data-analyst`**, and (for forecasting/statistical/ML work) **`data-scientist`** teammates using their subagent definitions. They self-claim tasks matching their tag (`de`/`ae`/`da`/`ds`) and follow `/process-ticket` to implement and `/implement-pr-comments` to address review feedback. Give each enough context in the spawn prompt — they don't inherit your conversation history. You don't need every role on every run — spawn the ones the backlog needs. 4. **Spawn the QA auditor.** Spawn the **`qa-auditor`** teammate. Every data task must pass through it before completion: it runs the `validate-repo` baseline (Kimball + Gemma SQL style checklists) and `/review-pr` (or `/review-pr-extensive` for risky changes), then appends `QA-PASS:` to the task when its verdict is PASS. 5. **Distribute and monitor.** Sequence the backlog before handing it out: (1) respect dependency edges (`ae` waits on its `de` dependency, etc.) — never release a task whose dependency is open; (2) within what's unblocked, prefer higher `prio:` and sooner `due:`; (3) surface `prio:unset` tickets to the user for a call rather than burying them. The fetcher carries these tags; you decide the order. Then assign tasks (or let teammates self-claim in that order), keep one file to one owner to avoid conflicts, and synthesize results as they land. Wait for teammates to finish rather than implementing their tasks yourself. - **Idle pings vs. substantive replies.** Teammates may emit a JSON `idle_notification` before their human-readable `SendMessage` reply lands. Treat the idle ping as "agent is available again", not "work is done". Always verify with `TaskList` / `TaskGet` (or wait for the teammate's text reply) before assuming a task was created or completed. Acting on the idle ping alone can silently duplicate work. - **De-dupe before acting.** If you find yourself about to create or close the same artefact a teammate just produced, stop and reconcile — keep the version with the richer / more faithful content and delete the duplicate. - **Observability of teammates.** The `/agents` panel doesn't reliably show every spawned teammate; the ground truth is each teammate's transcript at `subagents/agent-*.jsonl` in the session directory — read those if you're unsure what a teammate is doing. - **Keep the lead responsive.** Spawn doer teammates with `run_in_background: true` so the lead isn't blocked, and stay available to answer their plan-mode questions promptly — a teammate that asked for plan approval stalls until the lead replies. ## The hard gate A `TaskCompleted` hook (`block-until-Bedrock`) enforces quality automatically: a data task cannot be marked complete unless the team is on Bedrock **and** the `qa-auditor` has signed off with `QA-PASS:`. If completion is blocked, read the hook's message, fix the underlying issue (move to Bedrock, or get QA sign-off), and retry — do not try to route around the gate. ## Team-size guidance Start with the five roles above. If the backlog is large and skewed to one discipline, the user can ask for additional teammates of that role. Beyond ~5–6 active teammates, coordination overhead and token cost outweigh the parallelism.