Agent team skills for Claude Code: multi-agent research and implementation workflows

README.md

Agent Team Skills for Claude Code

Two slash-command skills that spin up multi-agent teams in Claude Code.

Skills

/team-research

Spawns a read-only research team (3 agents) to investigate a question from multiple angles. No code changes. Agents cite file:line, cross-check each other's findings, and the lead synthesizes agreements/contradictions into options with trade-offs.

/team-implement

Spawns an implementation team (3 agents) following a PRAR workflow: Perceive > Reason > Act > Refine. Lead splits work into parallel-safe pieces, assigns file ownership per teammate, reviews plans before any code is written, and runs the full test suite at the end.

Usage

Drop the .md files into your .claude/commands/ directory, then invoke with:

/team-research how does the caching layer interact with the database connection pool?
/team-implement add rate limiting to the public API endpoints

Requirements

• Claude Code with agent team support (TeamCreate, TaskCreate, etc.)

team-implement.md

description	Spin up an agent team for a task with structured workflow. Provide a Jira ticket, task description, or both.
argument-hint	<FIS-XXXX or task description>

Create an agent team for the following task:

$ARGUMENTS

Workflow (PRAR)

The team follows a phased workflow. Do NOT skip phases.

Phase 1: PERCEIVE (Lead only)

1. If a Jira ticket is provided, fetch it for full context
2. Read CLAUDE.md, AGENTS.md at repo root and in relevant directories
3. Identify the scope of work and split into parallel-safe pieces
4. If requirements are vague, ask the user for clarity before proceeding

Phase 2: SCAFFOLD (Lead only)

1. Use TeamCreate to create the team
2. Use TaskCreate to create all tasks (5-6 per planned teammate)
3. Use TaskUpdate to set up dependencies (addBlockedBy) for tasks with ordering constraints
4. Spawn teammates using the Agent tool with team_name, name, and mode: plan parameters
5. Use subagent_type: general-purpose for all code-modifying teammates
6. Each teammate's spawn prompt must include:
   • Their assigned task numbers
   • File paths they own (no overlap between teammates)
   • Architecture context and interfaces they need to implement or consume
   • Existing files they MUST read before planning
   • Instructions to present plan, then wait for approval before coding

Phase 3: REASON (Lead + Teammates)

1. Teammates investigate their area and submit plans to the lead
2. Lead reviews plans:
   • Approve plans that include test coverage and stay within file scope
   • Reject plans that touch files outside the teammate's scope
3. If a teammate raises a blocking question, lead investigates (reads code, checks APIs) before answering. Do NOT guess
4. Lead presents the combined plan to the user and waits for approval before proceeding
5. After user approval, approve teammate plans so they exit plan mode

Phase 4: ACT (Teammates)

1. Each teammate writes tests alongside their implementation (never separately)
2. Each teammate runs tests on their own work before marking tasks complete
3. If a teammate gets stuck after 2-3 attempts, it messages the lead instead of guessing
4. Lead monitors progress and redirects as needed. Lead does NOT implement tasks itself
5. Teammates message each other when their work produces interfaces or contracts the other needs
6. Spawn additional teammates for blocked tasks as their dependencies complete

Phase 5: REFINE (Lead)

1. Wait for ALL teammates to finish. Do NOT proceed until every teammate is idle
2. Verify no file conflicts between teammates
3. Run the full test suite
4. Present a summary to the user of what was done and what to verify
5. User then runs their own pipeline: /cm:code-review, /simplify, /cm:git-commits, /gf-github:pr-create

Phase 6: CLEANUP (Lead)

1. Send shutdown_request to each teammate individually
2. Wait for each shutdown to be approved
3. Use TeamDelete to clean up team resources

Team structure

• Default to 3 teammates unless the task clearly needs more or fewer
• Assign 5-6 tasks per teammate
• Each teammate gets a clear role name (e.g., "backend", "frontend", "tests")
• Use task dependencies when work has ordering constraints

Rules

• Do NOT push, create PRs, or run git operations beyond what's needed for implementation
• Do NOT modify files outside the teammate's assigned scope
• Minimal changes only. No refactoring beyond what the task requires
• Stick to the repo's existing stack and patterns

team-research.md

description	Spin up a research agent team to explore a topic from multiple angles. No code changes.
argument-hint	<question or topic to investigate>

Create an agent team to research the following:

$ARGUMENTS

Workflow

Phase 1: FRAME (Lead only)

1. Read CLAUDE.md at repo root for project context
2. Break the question into 2-4 independent research angles
3. If the question is too vague, ask the user for clarity before spawning

Phase 2: SCAFFOLD (Lead only)

1. Use TeamCreate to create the team
2. Use TaskCreate to create one task per research angle
3. Spawn teammates using the Agent tool with team_name and name parameters
4. Use subagent_type: general-purpose (NOT Explore, which lacks SendMessage)
5. Each teammate's spawn prompt must include:
   • Their specific research questions
   • File paths and module names to investigate
   • Instruction: read-only, no code changes, cite file:line for all claims
   • Instruction: send findings to team-lead via SendMessage when done

Phase 3: INVESTIGATE (Teammates)

1. Teammates explore code, read docs, run queries, but change nothing
2. Teammates message each other to share findings that affect other angles
3. If a teammate finds something that contradicts another's assumptions, they message that teammate directly
4. Lead can redirect teammates mid-investigation if user provides new context (via SendMessage)

Phase 4: SYNTHESIZE (Lead)

1. Wait for ALL teammates to report back
2. Collect findings, identify agreements and contradictions
3. Present to the user:
   • Key findings per angle
   • Where teammates agreed
   • Where they disagreed and why
   • 2-3 concrete options with trade-offs and a lean (state which option you'd pick and why, but let user decide)

Phase 5: CLEANUP (Lead)

1. Send shutdown_request to each teammate individually
2. Wait for each shutdown to be approved
3. Use TeamDelete to clean up team resources

Team structure

• Default to 3 teammates
• Each gets a clear research role (e.g., "architecture", "performance", "existing-patterns")
• One teammate can play devil's advocate if the question has obvious "right" answers

Rules

• NO code changes. Read-only exploration only
• NO git operations
• Teammates must cite file:line when stating facts about the codebase
• If a teammate is unsure about something, say so instead of guessing