Agent skill

Team Orchestration

by NoobyGains in NoobyGains/godmode

A skill your agent uses when a task benefits from multiple Claude instances collaborating with peer-to-peer messaging - parallel research, multi-module features, cross-layer changes, or competing…

MITAuto-check passedDevelopment

Install Team Orchestration

skills CLI
$ npx skills add NoobyGains/godmode --skill team-orchestration -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install NoobyGains/godmode team-orchestration --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/NoobyGains/godmode.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/team-orchestration .claude/skills/team-orchestration && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
team-orchestration
GitHub stars
107
Token cost
~5.1k tokens
SKILL.md length
1,383 words
Files
2
Skills in repo
34
Repo updated
First seen
Licence
MIT

At a glance

A skill your agent uses when a task benefits from multiple Claude instances collaborating with peer-to-peer messaging - parallel research, multi-module features, cross-layer changes, or competing…

  • Works in 5 steps: Evaluate Task-Team Fit → Architect the Team → Define Tasks with Clear Boundaries → …
  • A task benefits from multiple Claude instances collaborating with peer-to-peer messaging - parallel research
  • SKILL.md covers Overview, The Prime Directive, When to Use and Prerequisites, plus 9 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Team Orchestration is an agent skill from NoobyGains/godmode. Use when a task benefits from multiple Claude instances collaborating with peer-to-peer messaging - parallel research, multi-module features, cross-layer changes, or competing hypothesis debugging. Not for simple independent tasks (use parallel-execution) or sequential tasks (use delegated-execution).

Its SKILL.md is about 5.1k tokens, which your agent loads only when the skill is triggered. The skill folder holds 1 other file (for example `team-patterns.md`).

It sits in Development. The repository describes itself as: The AI development framework that thinks before it builds. 36 composable skills for Claude Code, Cursor, Codex, and OpenCode. The licence is MIT.

When your agent uses it

  • A task benefits from multiple Claude instances collaborating with peer-to-peer messaging - parallel research
  • Multi-module features
  • Cross-layer changes
  • Competing hypothesis debugging

Example prompts

  • “/team-orchestration”

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. Evaluate Task-Team Fit
  2. Architect the Team
  3. Define Tasks with Clear Boundaries
  4. Coordinate as Team Lead
  5. Integrate Results

What it can do on your machine

Read from SKILL.md and the folder at commit 441103a. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are json and dot).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Team Orchestration loads about 5.1k tokens when it runs. Until then it costs about 80 tokens; SKILL.md has 1,383 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~80
When it runs · the whole SKILL.md, loaded when a task matches
~5.1k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from NoobyGains/godmode at commit 441103a, republished under its MIT licence (© NoobyGains). 1,383 words, ~5,149 tokens.

Download SKILL.mdSave it as .claude/skills/team-orchestration/SKILL.md (or your agent's skills folder). This skill also uses 1 other file; get the full folder from GitHub.
name
team-orchestration
description
Use when a task benefits from multiple Claude instances collaborating with peer-to-peer messaging - parallel research, multi-module features, cross-layer changes, or competing hypothesis debugging. Not for simple independent tasks (use parallel-execution) or sequential tasks (use delegated-execution).

Team Orchestration

Overview

Agent Teams enable multiple Claude Code sessions to collaborate on a shared project with direct peer-to-peer messaging and shared task lists. Unlike subagents, teammates can communicate with each other, claim tasks dynamically, and coordinate on shared problems.

Core principle: Deploy teams when tasks benefit from collaboration, not merely parallelism. If teammates will never need to message each other, use parallel subagents instead.

No exceptions. No workarounds. No shortcuts.

The Prime Directive

NO TEAM WITHOUT A COLLABORATION REQUIREMENT

If teammates will never exchange messages, you do not need a team.

When to Use

dot
digraph when_teams {
    "Multiple tasks?" [shape=diamond];
    "Need peer-to-peer collaboration?" [shape=diamond];
    "Tasks independent?" [shape=diamond];
    "Agent Teams" [shape=box style=filled fillcolor=lightgreen];
    "parallel-execution" [shape=box];
    "delegated-execution" [shape=box];
    "Single agent" [shape=box];

    "Multiple tasks?" -> "Need peer-to-peer collaboration?" [label="yes"];
    "Multiple tasks?" -> "Single agent" [label="no"];
    "Need peer-to-peer collaboration?" -> "Agent Teams" [label="yes - teammates must share discoveries"];
    "Need peer-to-peer collaboration?" -> "Tasks independent?" [label="no"];
    "Tasks independent?" -> "parallel-execution" [label="yes - fire and forget"];
    "Tasks independent?" -> "delegated-execution" [label="no - sequential"];
}

Deploy Teams when:

  • Parallel research where discoveries from one investigation redirect another
  • Multi-module features where frontend/backend/tests must coordinate
  • Cross-layer changes requiring interface negotiation
  • Debugging with competing hypotheses that need to share evidence
  • Large refactoring across multiple subsystems with shared conventions

Do not use when:

  • Simple independent tasks (use godmode:parallel-execution)
  • Sequential dependent tasks (use godmode:delegated-execution)
  • Single-file or single-module changes
  • Agent Teams feature not enabled
  • Fewer than 2 genuinely collaborative tasks

Prerequisites

Agent Teams is an experimental feature. It must be enabled:

CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=true

Without this, TeamCreate, TaskCreate, and SendMessage tools are unavailable.

Deferred tools: TeamCreate, TaskCreate, TaskUpdate, TaskGet, TaskList, SendMessage, and EnterWorktree are deferred tools. They must be loaded via ToolSearch before first use:

json
// Load all team tools at once
ToolSearch: { "query": "select:SendMessage,TaskCreate,TaskUpdate,TaskList,TaskGet,EnterWorktree" }

The Entry Protocol

BEFORE forming a team:

1. ENUMERATE: What are all the tasks?
2. MAP: Which tasks need information from other tasks?
3. COUNT: How many task pairs require shared discoveries?
4. DECIDE:
   - 0 pairs need collaboration -> Use parallel-execution
   - 1 pair needs collaboration -> Consider single agent or subagents
   - 2+ pairs need collaboration -> Use Agent Teams
5. ONLY THEN: Form the team

Skip any step = unnecessary team overhead

The Workflow

Step 1: Evaluate Task-Team Fit

Before reaching for TeamCreate, answer these:

QuestionIf YesIf No
Can a single agent handle this?Do that insteadContinue
Can parallel subagents handle this?Use parallel-executionContinue
Do agents need to share discoveries mid-work?TeamsSubagents
Do agents need to negotiate interfaces?TeamsSubagents
Is coordination overhead justified?TeamsSimpler approach
Step 2: Architect the Team

Create the team, then spawn teammates using the Agent tool:

json
// 1. Create the team
TeamCreate: {
  "team_name": "auth-refactor-team",
  "description": "Refactor authentication across API and frontend modules"
}

// 2. Spawn each teammate (2-5 max)
Agent: {
  "name": "backend-eng",
  "team_name": "auth-refactor-team",
  "prompt": "You are the backend engineer. Own all files in src/api/auth/. Implement the new token refresh flow. Coordinate with frontend-eng on the session interface.",
  "description": "Backend auth implementation",
  "mode": "bypassPermissions"
}

Agent: {
  "name": "frontend-eng",
  "team_name": "auth-refactor-team",
  "prompt": "You are the frontend engineer. Own all files in src/ui/auth/. Update login flow to use new token refresh. Coordinate with backend-eng on the session interface.",
  "description": "Frontend auth implementation",
  "mode": "bypassPermissions"
}

Teammate count guidance:

CountWhenCoordination Cost
2Two distinct modules that must agree on interfaceLow
3Frontend + backend + tests, or 3 independent subsystemsMedium
4Cross-cutting refactor with 4 modulesHigh
5Maximum — only for genuinely large effortsVery High
Step 2b: Isolate Workspaces

Each teammate should work in an isolated git worktree to prevent merge conflicts at the filesystem level:

json
// Called by each teammate at the start of their work
EnterWorktree: { "name": "auth-backend" }

EnterWorktree creates a separate git worktree so teammates edit files in parallel without stepping on each other. The team lead runs godmode:merge-protocol to integrate worktrees at the end.

Step 3: Define Tasks with Clear Boundaries
json
// Create tasks with clear scope and success criteria
TaskCreate: {
  "subject": "Implement token refresh endpoint",
  "description": "Build POST /api/auth/refresh that validates expired access tokens against refresh tokens. Return new access+refresh token pair. Files: src/api/auth/refresh.ts, src/api/auth/refresh.test.ts",
  "activeForm": "Implementing token refresh endpoint"
}

TaskCreate: {
  "subject": "Update login UI for token refresh",
  "description": "Update login flow to store refresh token and auto-refresh on 401. Files: src/ui/auth/login.tsx, src/ui/auth/session.ts",
  "activeForm": "Updating login UI for token refresh"
}

// Set up dependencies and assign owners
TaskUpdate: { "taskId": "2", "addBlockedBy": ["1"] }
TaskUpdate: { "taskId": "1", "owner": "backend-eng" }
TaskUpdate: { "taskId": "2", "owner": "frontend-eng" }

Task design rules:

  • Clear scope: exactly which files/modules this teammate owns
  • Dependencies: use addBlockedBy for tasks that must complete first
  • Success criteria: what "done" looks like in the description
  • File ownership: NO overlap between teammates (prevents merge conflicts)

File ownership is non-negotiable. Two teammates editing the same file guarantees merge conflicts. If a shared file needs changes from multiple perspectives, assign it to ONE teammate who coordinates with others via messaging.

Step 4: Coordinate as Team Lead
dot
digraph team_lead_loop {
    "Check TaskList" [shape=box];
    "All tasks completed?" [shape=diamond];
    "Any teammate blocked?" [shape=diamond];
    "Send clarifying message" [shape=box];
    "Resolve dependency" [shape=box];
    "Integrate results" [shape=box style=filled fillcolor=lightgreen];

    "Check TaskList" -> "All tasks completed?";
    "All tasks completed?" -> "Integrate results" [label="yes"];
    "All tasks completed?" -> "Any teammate blocked?" [label="no"];
    "Any teammate blocked?" -> "Send clarifying message" [label="needs info"];
    "Any teammate blocked?" -> "Resolve dependency" [label="blocked by task"];
    "Any teammate blocked?" -> "Check TaskList" [label="no - working"];
    "Send clarifying message" -> "Check TaskList";
    "Resolve dependency" -> "Check TaskList";
}

As team lead:

  • Track task completion via TaskList (no parameters needed — just call it)
  • Relay discoveries between teammates using direct messages:
json
// Direct message to relay a discovery
SendMessage: {
  "type": "message",
  "recipient": "frontend-eng",
  "content": "backend-eng finished the refresh endpoint. The response shape is { accessToken, refreshToken, expiresIn }. You can unblock now.",
  "summary": "Refresh endpoint contract ready"
}
  • Unblock dependencies by marking prerequisite tasks complete:
json
TaskUpdate: { "taskId": "1", "status": "completed" }
  • Arbitrate conflicts if teammates disagree on approach
  • Use broadcast ONLY for team-wide critical issues (expensive — sends N messages):
json
// Broadcast — use sparingly, sends N separate messages
SendMessage: {
  "type": "broadcast",
  "content": "Convention change: all auth endpoints now return camelCase keys",
  "summary": "Auth API convention change"
}
Step 5: Integrate Results

When all tasks complete:

  1. Review all changes together for consistency
  2. Confirm no file conflicts between teammates
  3. Run full test suite
  4. Verify that cross-module interfaces agree
  5. REQUIRED SUB-PROTOCOL: Use godmode:merge-protocol

Team Patterns

See team-patterns.md in this directory for five documented team patterns:

  1. Exploration Team — Parallel investigation of different dimensions
  2. Feature Team — Multi-module development (frontend + backend + tests)
  3. Diagnosis Team — Competing hypotheses tested concurrently
  4. Inspection Team — Multi-perspective code review
  5. Migration Team — Cross-cutting convention changes across codebase

Each pattern includes: when to use, team structure, task design, coordination flow, and example.

Tools at a Glance

ToolPurposeKey ParametersWhen
TeamCreateForm teamteam_name, descriptionOnce at start
AgentSpawn teammatename, team_name, prompt, description, modeOnce per teammate
EnterWorktreeIsolate workspacenameEach teammate at start
TaskCreateAdd tasksubject, description, activeFormDuring setup
TaskListView all tasks(none)Monitoring
TaskGetGet task detailstaskIdBefore starting work
TaskUpdateClaim/complete/updatetaskId, status, owner, addBlockedByThroughout
SendMessageDirect messagetype: "message", recipient, content, summaryCoordination
SendMessageBroadcasttype: "broadcast", content, summaryCritical issues only
SendMessageShutdowntype: "shutdown_request", recipient, contentWinding down

Teammate Behavior: What to Expect

Teammates are independent Claude sessions. Key behaviors:

  • Idle between turns — This is normal. Teammates go idle when waiting for messages or tasks. They reactivate when messaged or when tasks become available.
  • Claim tasks — Teammates use TaskUpdate to assign themselves before starting work.
  • Message each other — Teammates can and should message each other directly, not just the team lead.
  • Self-directed — Once given a task, teammates work autonomously. Avoid micromanagement.

Cognitive Traps

RationalizationTruth
"Teams are always superior to subagents"Teams add coordination overhead. Deploy only when collaboration is necessary.
"More teammates = faster delivery"More teammates = more coordination. 3 focused teammates outperform 6 scattered ones.
"I'll form the team and figure out tasks later"Tasks MUST be designed before team formation. No tasks = idle teammates burning tokens.
"Teammates can share files"Shared files = merge conflicts. Assign clear ownership.
"Broadcast is fine for routine updates"Broadcast sends N messages. Use SendMessage to specific teammates.
"Dependencies are implied"Undefined dependencies = teammates stepping on each other.
Show full SKILL.md (526 more words)Show less

Guardrails

Prohibited:

  • Forming teams for simple tasks (overhead not justified)
  • Allowing teammates to edit the same files (merge conflicts)
  • Skipping integration review after team completion
  • Ignoring teammate messages (they contain discoveries)
  • Forming teams with more than 5 teammates (coordination explodes)
  • Using broadcast for routine updates (use direct messages)
  • Starting a team without clearly designed tasks
  • Leaving dependencies undefined between tasks

Mandatory:

  • Define clear file ownership boundaries
  • Set up task dependencies with blockedBy
  • Review all changes together after completion
  • Run full test suite after integration
  • Use SendMessage for teammate-to-teammate coordination
  • Mark tasks complete when done (teammates check TaskList for available work)

Tool Invocation Reference

Complete parameter specifications for every Agent Teams tool. Copy these directly — parameter names are exact.

TeamCreate

Creates a named team. Call once before spawning teammates.

json
{
  "team_name": "feature-billing-team",
  "description": "Build subscription billing feature"
}
ParameterTypeRequiredNotes
team_namestringyesKebab-case identifier
descriptionstringyesWhat the team is working on
Agent (spawn teammate)

Spawns a teammate into an existing team. Each teammate is an independent Claude session.

json
{
  "name": "backend-eng",
  "team_name": "feature-billing-team",
  "prompt": "You are the backend engineer on this team. Own src/api/billing/. Build the Stripe webhook handler and subscription CRUD endpoints. Use godmode:test-first for implementation. Coordinate with frontend-eng on API contracts via SendMessage.",
  "description": "Backend billing implementation",
  "mode": "bypassPermissions"
}
ParameterTypeRequiredNotes
namestringyesTeammate identifier (used in SendMessage recipient)
team_namestringyesMust match TeamCreate team_name
promptstringyesFull instructions — include file ownership, scope, coordination rules
descriptionstringyesShort description shown in UI
modestringno"bypassPermissions" lets teammate work without permission prompts
EnterWorktree

Creates an isolated git worktree for a teammate. Prevents filesystem conflicts when multiple teammates edit files in parallel.

json
{
  "name": "billing-feature"
}
ParameterTypeRequiredNotes
namestringyesWorktree identifier — becomes the branch/directory name
TaskCreate

Adds a task to the shared task list visible to all teammates.

json
{
  "subject": "Implement Stripe webhook handler",
  "description": "Build POST /webhooks/stripe endpoint that handles subscription.created, subscription.updated, and subscription.deleted events. Files: src/api/billing/webhooks.ts, src/api/billing/webhooks.test.ts",
  "activeForm": "Implementing Stripe webhook handler"
}
ParameterTypeRequiredNotes
subjectstringyesImperative form title (e.g., "Fix auth bug")
descriptionstringyesFull scope, file list, acceptance criteria
activeFormstringnoPresent continuous form for spinner (e.g., "Fixing auth bug")
TaskUpdate

Updates a task's status, owner, or dependencies. Use for claiming, completing, and wiring up blocked-by relationships.

json
// Assign owner
{ "taskId": "1", "owner": "backend-eng" }

// Set dependency — task 3 cannot start until tasks 1 and 2 complete
{ "taskId": "3", "addBlockedBy": ["1", "2"] }

// Mark in progress
{ "taskId": "1", "status": "in_progress" }

// Mark complete
{ "taskId": "1", "status": "completed" }
ParameterTypeRequiredNotes
taskIdstringyesTask ID from TaskCreate/TaskList
statusstringno"pending", "in_progress", "completed", or "deleted"
ownerstringnoTeammate name to assign
addBlockedBystring[]noTask IDs that must complete before this task
addBlocksstring[]noTask IDs that this task blocks
subjectstringnoUpdated title
descriptionstringnoUpdated description
activeFormstringnoUpdated spinner text
TaskList

Returns all tasks with their status, owner, and blocked-by info. No parameters.

json
// No parameters — just call it
TaskList: {}
TaskGet

Retrieves full details of a specific task.

json
{ "taskId": "1" }
ParameterTypeRequiredNotes
taskIdstringyesTask ID to retrieve
SendMessage

Three message types for team communication.

Direct message (default — use this for most communication):

json
{
  "type": "message",
  "recipient": "backend-eng",
  "content": "The profile API needs a PUT /profile/preferences endpoint. Frontend needs to update preferences without replacing the full profile.",
  "summary": "API contract update request"
}

Broadcast (sends to ALL teammates — use sparingly):

json
{
  "type": "broadcast",
  "content": "Convention change: all API responses now use camelCase keys",
  "summary": "API convention change"
}

Shutdown request (graceful teammate shutdown):

json
{
  "type": "shutdown_request",
  "recipient": "backend-eng",
  "content": "All tasks complete, wrapping up"
}
ParameterTypeRequiredNotes
typestringyes"message", "broadcast", or "shutdown_request"
recipientstringfor message/shutdownTeammate name
contentstringyesMessage body
summarystringfor message/broadcast5-10 word preview shown in UI
Complete Team Setup Example

End-to-end example wiring up a 2-person feature team:

json
// 1. Create team
TeamCreate: { "team_name": "billing-team", "description": "Build subscription billing" }

// 2. Create tasks
TaskCreate: {
  "subject": "Build Stripe webhook handler",
  "description": "POST /webhooks/stripe handling subscription events. Files: src/api/billing/webhooks.ts",
  "activeForm": "Building Stripe webhook handler"
}
TaskCreate: {
  "subject": "Build billing dashboard UI",
  "description": "Subscription management page showing plan, usage, invoices. Files: src/ui/billing/",
  "activeForm": "Building billing dashboard"
}

// 3. Wire dependencies and assign owners
TaskUpdate: { "taskId": "2", "addBlockedBy": ["1"] }
TaskUpdate: { "taskId": "1", "owner": "backend-eng" }
TaskUpdate: { "taskId": "2", "owner": "frontend-eng" }

// 4. Spawn teammates (they auto-claim their assigned tasks)
Agent: {
  "name": "backend-eng",
  "team_name": "billing-team",
  "prompt": "You are the backend engineer. Own src/api/billing/. Start with task #1. Use EnterWorktree to isolate your workspace. Use godmode:test-first. Message frontend-eng with the API contract when done.",
  "description": "Backend billing implementation",
  "mode": "bypassPermissions"
}
Agent: {
  "name": "frontend-eng",
  "team_name": "billing-team",
  "prompt": "You are the frontend engineer. Own src/ui/billing/. Task #2 is blocked by #1. Wait for backend-eng to share the API contract, then implement. Use EnterWorktree to isolate your workspace.",
  "description": "Frontend billing implementation",
  "mode": "bypassPermissions"
}

// 5. Monitor as team lead
TaskList: {}

// 6. When all tasks complete, shutdown teammates
SendMessage: { "type": "shutdown_request", "recipient": "backend-eng", "content": "All done, wrapping up" }
SendMessage: { "type": "shutdown_request", "recipient": "frontend-eng", "content": "All done, wrapping up" }

Integration

Related orchestration protocols:

  • godmode:parallel-execution — For independent tasks without collaboration requirement
  • godmode:delegated-execution — For sequential tasks with review checkpoints
  • godmode:task-runner — For plan execution in a separate session

Teammates should use:

  • godmode:test-first — For implementation tasks
  • godmode:fault-diagnosis — For diagnosis team investigations
  • godmode:completion-gate — Before marking tasks complete

Required for completion:

  • godmode:merge-protocol — After all team tasks complete

© NoobyGains, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 1 other file in skills/team-orchestration of NoobyGains/godmode.

  • SKILL.md
  • team-patterns.md

Open the folder on GitHubat commit 441103a

Compare with similar skills

Team Orchestration next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Team Orchestration compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Team Orchestration this skillNoobyGains/godmode107—~5.1kAutomated safety check: PassMIT
Vercel Composition Patternssupabase/supabase111k58 repos~726Automated safety check: PassMIT
Finishing a Development Branchobra/superpowers297k5 repos~1.9kAutomated safety check: PassMIT
Typescript Advanced Typesrolling-scopes/rsschool-app10k25 repos~4.2kAutomated safety check: PassMPL-2.0
PR Babysitteropeninterpreter/openinterpreter69k3 repos~4.2kAutomated safety check: PassApache-2.0
Code Review ChecklistshareAI-lab/learn-claude-code78k5 repos~1.1kAutomated safety check: PassMIT

Similar skills

  • Official

    React composition patterns that scale. An agent skill from supabase/supabase.

    111k GitHub starsUsed in 58 repos~726 tokens
    DevelopmentAuto-check passed
  • Walks the last step of a branch: confirm tests pass, detect the git environment, ask how to integrate, carry out your choice and clean up the worktree.

    297k GitHub starsUsed in 5 repos~1.9k tokens
    DevelopmentAuto-check passed
  • Typescript Advanced Types

    rolling-scopes/rsschool-app

    Master TypeScript's advanced type system including generics, conditional types, mapped types, template literals, and utility types for building type-safe applications.

    10k GitHub starsUsed in 25 repos~4.2k tokens
    DevelopmentAuto-check passed
  • PR Babysitter

    openinterpreter/openinterpreter

    Watches an open GitHub pull request until it merges, handling review comments, diagnosing CI failures and retrying flaky checks along the way.

    69k GitHub starsUsed in 3 repos~4.2k tokens
    DevelopmentAuto-check passed
  • Code Review Checklist

    shareAI-lab/learn-claude-code

    Reviews code against a five-part checklist covering security, correctness, performance, maintainability and testing, and reports findings in a fixed format.

    78k GitHub starsUsed in 5 repos~1.1k tokens
    DevelopmentAuto-check passed
  • Greploop

    onyx-dot-app/onyx

    Iteratively improves a PR (GitHub), MR (GitLab), or shelved changelist (Perforce) until Greptile gives it a 5/5 confidence score with zero unresolved comments.

    32k GitHub starsUsed in 4 repos~3.3k tokens
    DevelopmentAuto-check passed

More from NoobyGains/godmode

All 34 skills in this repo
  • Activation

    NoobyGains/godmode

    A skill your agent uses when starting any conversation - establishes how to locate and invoke skills, mandating Skill tool usage before ANY response including clarifying questions

    107 GitHub stars~2.4k tokensUpdated 7 mo ago
    Auto-check passed
  • Agent Messaging

    NoobyGains/godmode

    A skill your agent uses when dispatching subagents, composing prompts for teammates, structuring handoff reports, or managing context boundaries between agents.

    107 GitHub stars~3k tokensUpdated 7 mo ago
    Auto-check passed
  • Codebase Research

    NoobyGains/godmode

    A skill your agent uses when building ANY feature within an existing project - search the current codebase for existing patterns, conventions, similar implementations, and established approaches…

    107 GitHub stars~3.2k tokensUpdated 7 mo ago
    Auto-check: notes
  • Completion Gate

    NoobyGains/godmode

    A skill your agent uses when about to declare work done, fixed, or passing, before committing or opening PRs - demands executing verification commands and reading their output before making any…

    107 GitHub stars~1.6k tokensUpdated 7 mo ago
    Auto-check passed
  • Comprehension Check

    NoobyGains/godmode

    A skill your agent uses when implementing any substantial feature, multi-file modification, or architectural change - produces a plain-language walkthrough of every alteration so the developer can…

    107 GitHub stars~1.5k tokensUpdated 7 mo ago
    Auto-check passed
  • Delegated Execution

    NoobyGains/godmode

    A skill your agent uses when executing implementation plans with independent tasks in the current session

    107 GitHub stars~2.4k tokensUpdated 7 mo ago
    Auto-check passed

Categories

Questions about Team Orchestration

What does Team Orchestration do?

A skill your agent uses when a task benefits from multiple Claude instances collaborating with peer-to-peer messaging - parallel research, multi-module features, cross-layer changes, or competing…. Team Orchestration is an agent skill from NoobyGains/godmode. Use when a task benefits from multiple Claude instances collaborating with peer-to-peer messaging - parallel research, multi-module features, cross-layer changes, or competing hypothesis debugging.

When should I use Team Orchestration?

Team Orchestration fits situations like: A task benefits from multiple Claude instances collaborating with peer-to-peer messaging - parallel research; multi-module features; cross-layer changes; competing hypothesis debugging.

How do I install Team Orchestration in Claude Code?

Run `npx skills add NoobyGains/godmode --skill team-orchestration -a claude-code`. Or copy the skill folder (skills/team-orchestration in NoobyGains/godmode) into .claude/skills/team-orchestration in your project. Claude Code loads it when a task matches its description.

How do I install Team Orchestration in Codex?

Run `npx skills add NoobyGains/godmode --skill team-orchestration -a codex`. Or copy the skill folder (skills/team-orchestration in NoobyGains/godmode) into .agents/skills/team-orchestration in your project. Codex loads it when a task matches its description.

Can I use Team Orchestration in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add NoobyGains/godmode --skill team-orchestration -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/team-orchestration, .gemini/skills/team-orchestration, .github/skills/team-orchestration and .opencode/skills/team-orchestration in your project.

What does Team Orchestration need to run?

SKILL.md names no scripts, command-line tools or credentials: Team Orchestration is instructions for the agent only.

Does Team Orchestration access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Team Orchestration safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Team Orchestration use?

Team Orchestration is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Team Orchestration use?

About 5.1k tokens (SKILL.md is roughly 21k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Team Orchestration?

Skills that share tags, products or a category with Team Orchestration: Vercel Composition Patterns (supabase/supabase, 111k stars), Finishing a Development Branch (obra/superpowers, 297k stars), Typescript Advanced Types (rolling-scopes/rsschool-app, 10k stars) and PR Babysitter (openinterpreter/openinterpreter, 69k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Team Orchestration?

NoobyGains (a GitHub user) maintains it in NoobyGains/godmode, which has 107 GitHub stars. The repository holds 34 skills in this directory. The repository was last updated on March 9, 2026.

Source: NoobyGains/godmode on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.