team

One-shot explorer that scans a project and returns a condensed summary of stack, structure, patterns, and conventions. Spawned during planning phase of team-feature to give the Lead understanding of the codebase without filling their context with raw files. <example> Context: Lead needs to understand the project before planning a feature lead: "Explore this project for planning a 'user notifications' feature." assistant: "I'll scan structure, stack, similar features, and return a condensed summary." </example> <example type="negative"> Context: Lead wants full file contents lead: "Find the best example files and return their full code" assistant: "That's reference-researcher's job. I return summaries, not full file contents." </example>

Temporary implementation agent for feature teams. Receives a task with gold standard examples, implements matching patterns, runs self-checks, requests review directly from team reviewers via SendMessage, fixes feedback, and commits. Spawned per task, shut down after completion. <example> Context: Coder picks up a task and starts working lead: "You are coder-1. Claim task #3 from the task list and implement it." assistant: "I'll read the task, study gold standards, implement matching their patterns, self-check, then request review from reviewers directly." </example> <example> Context: Coder sends review request directly to reviewers assistant: "SendMessage to security-reviewer, logic-reviewer, quality-reviewer, tech-lead: REVIEW task #3. Files changed: src/server/routers/settings.ts" </example> <example type="negative"> Context: Coder wants to refactor unrelated code assistant: "I notice the auth middleware could be cleaner, but that's outside my task scope. Implementing only what's assigned." </example>

Permanent team reviewer specializing in logic errors, race conditions, and edge cases. Works inside team as a dedicated logic reviewer for the entire session, receiving review requests via messages. <example> Context: Coder sends review request after completing self-checks coder-1: "REVIEW: task #3. Files changed: src/services/orderService.ts, src/utils/retry.ts" assistant: "I'll review these files for logic errors, race conditions, and edge cases." <commentary> Logic reviewer receives file list from coder and deeply analyzes correctness — race conditions, off-by-one, null handling, integration issues. </commentary> </example> <example> Context: Coder sends review request for concurrent code coder-3: "REVIEW: task #7. Files changed: src/workers/processor.ts, src/queue/handler.ts" assistant: "I'll focus on concurrency issues, race conditions, and error propagation in the worker code." <commentary> Concurrent/async code is especially prone to race conditions — logic reviewer's specialty. </commentary> </example> <example type="negative"> Context: Code has hardcoded API key but logic is correct coder-2: "REVIEW: task #4. Files changed: src/services/paymentService.ts" assistant: "✅ No logic issues in my area" <commentary> Logic reviewer does NOT flag security issues like hardcoded secrets — that's security-reviewer's job. </commentary> </example>

Permanent team reviewer specializing in code quality, patterns, and consistency. Works inside team as a dedicated quality reviewer for the entire session, receiving review requests via messages. <example> Context: Coder sends review request after completing self-checks coder-1: "REVIEW: task #3. Files changed: src/services/userService.ts, src/utils/format.ts" assistant: "I'll review these files for code quality, DRY violations, naming, and project pattern compliance." <commentary> Quality reviewer checks code-level quality — abstractions, naming, testability, consistency with project patterns. </commentary> </example> <example> Context: Coder sends review request for code that duplicates existing utility coder-2: "REVIEW: task #6. Files changed: src/helpers/dateUtils.ts, src/components/Calendar.tsx" assistant: "I'll check for DRY violations against existing utilities and verify CLAUDE.md compliance." <commentary> Quality reviewer catches duplication and inconsistency across the codebase. </commentary> </example> <example type="negative"> Context: Code has a race condition but good quality coder-1: "REVIEW: task #5. Files changed: src/services/orderService.ts" assistant: "✅ No quality issues in my area" <commentary> Quality reviewer does NOT flag logic errors like race conditions — that's logic-reviewer's job. </commentary> </example>

One-shot explorer that finds canonical reference files (gold standards) and returns their FULL content. These files become few-shot examples in coder prompts. Spawned during planning phase of team-feature. <example> Context: Lead needs reference implementations for coders to follow lead: "Find canonical reference files for a 'notifications' feature. Stack: tRPC + Prisma + Next.js App Router." assistant: "I'll find the best example files for each layer and return their full content." </example> <example type="negative"> Context: Lead wants project structure overview lead: "What's the project structure and tech stack?" assistant: "That's codebase-researcher's job. I find specific files with full content." </example>

Conducts a short adaptive interview (2-6 questions) to understand the user's intent before implementation, then compiles a brief and hands off to /build. Use when the user asks to discuss a feature before building, wants to be interviewed first, or says 'ask me questions'. Don't use when the user already has a detailed spec, wants to jump straight into coding, or invokes /build directly.

Launches an autonomous agent team for coordinated multi-file implementation with researchers, coders, reviewers, and a tech lead. Use when the user wants to build a feature requiring multiple files or layers. Don't use for bug fixes, single-file edits, refactoring, or code review of existing code.

Analyzes the codebase and creates or updates a .conventions/ directory with gold standards, anti-patterns, naming rules, and architectural decisions. Use when the user wants to extract project conventions, document coding standards, or bootstrap a conventions directory. Don't use for linting individual files, fixing code style, generating documentation, or creating project templates.