Communitygithub.com

Team (チーム)

Claude Codeの暗黙のエージェントチーム機能を使用して、共有タスクリスト上で協調動作するN個のエージェントを起動します。

Team (チーム) とは？

このスキルは、Claude Codeのネイティブエージェントチーム機能（CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1が必要）を活用し、複数のエージェントが協調してタスクを実行するためのフレームワークを提供します。ユーザーが指定した高レベルタスクを、Orchestrator（リーダー）が分析・分解し、複数のサブタスクとしてエージェントチームメンバーに割り当てます。各エージェントは `name` パラメータで識別され、`Agent/Task` ツールを介して直接起動されます。パイプライン処理（team-plan → team-prd → team-exec → team-verify → team-fix）に従い、各ステージで適切な専門エージェント（executor, debugger, designer, 検証担当など）が自動的にルーティングされます。また、外部CLIワーカー（Codex CLI, Gemini CLI, Antigravity CLI）の起動もサポートしており、マルチプラットフォーム（macOS, Linux, Windows (psmux)）で動作します。Ralphの永続化ループと組み合わせることで、失敗時の再試行やアーキテクト検証を含む堅牢な実行が可能です。

対応✓Claude Code✓Codex CLI✓Cursor✓Antigravity✓Gemini CLI
npx skills add https://github.com/Yeachan-Heo/oh-my-claudecode/tree/main/skills/team
オリジナルを見る→すべてのスキルを見る

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

ドキュメント

Team Skill

Claude Codeの暗黙のエージェントチームを使用して、共有タスクリスト上で協調動作するN個のエージェントを起動します。Claude Code 2.1.178+ ではネイティブの TeamCreate/TeamDelete が削除されました。CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 を設定すると、各セッションは1つの暗黙のチームを持ち、Agent/Task ツールで異なる name 値を用いてチームメイトが直接起動されます。このスキルは、文書化されている箇所（omc team / /omc-teams）では、OMCの従来のtmux/CLIワーカーオーケストレーションも引き続き保持しています。

swarm 互換エイリアスは #1131 で削除されました。

使用方法

/oh-my-claudecode:team N:agent-type "task description"
/oh-my-claudecode:team "task description"
/oh-my-claudecode:team ralph "task description"

パラメータ

  • N - チームメイトエージェントの数（1〜20）。省略可能。デフォルトはタスクの分解に基づく自動サイジング。
  • agent-type - team-exec ステージで起動するOMCエージェント（例: executor, debugger, designer, codex, gemini, antigravity）。省略可能。デフォルトはステージ認識ルーティング。codex を指定するとCodex CLIワーカーを起動、gemini でGemini CLIワーカー（エンタープライズ/APIキーティア）、antigravity でAntigravity CLI (agy) ワーカー（GoogleによるGemini CLIの後継）を起動します。それぞれ対応するCLIがインストールされている必要があります。下記の「ステージエージェントルーティング」を参照。
  • task - チームメイト間で分解・分散する高レベルタスク
  • ralph - オプションの修飾子。指定すると、チームパイプラインをRalphの永続化ループ（失敗時に再試行、完了前にアーキテクト検証）でラップします。「Team + Ralph 構成」を参照。

例

/team 5:executor "fix all TypeScript errors across the project"
/team 3:debugger "fix build errors in src/"
/team 4:designer "implement responsive layouts for all page components"
/team "refactor the auth module with security review"
/team ralph "build a complete REST API for user management"
# Codex CLIワーカーを使用する場合（npm install -g @openai/codex が必要）
/team 2:codex "review architecture and suggest improvements"
# Gemini CLIワーカーを使用する場合（npm install -g @google/gemini-cli が必要）
/team 2:gemini "redesign the UI components"
# Antigravity CLIワーカーを使用する場合（https://antigravity.google に従ってインストールが必要）
/team 2:antigravity "redesign the UI components"
# 混合: Codexでバックエンド分析、Gemini/Antigravityでフロントエンド（/oh-my-claudecode:ask でタスクごとに委任）

アーキテクチャ

User: "/team 3:executor fix all TypeScript errors"
              |
              v
      [TEAM ORCHESTRATOR (Lead)]
              |
              +-- セッションの暗黙のClaude Codeチームを使用
              |       -> TeamCreate呼び出しなし。リードは現在のセッションのまま
              |
              +-- タスクを分析・分解
              |       -> explore/architectがサブタスクリストを生成
              |
              +-- 実装計画からタスクリストエントリを作成
              |       -> 依存関係を持つTODO/タスクエントリ #1, #2, #3
              |
              +-- タスクリストエントリを更新（所有者を事前割り当て）
              |       -> タスク #1 所有者=worker-1, など
              |
              +-- Task(name="worker-1") x 3
              |       -> チームメイトをチームに起動
              |
              +-- 監視ループ
              |       <- チームメイトからのメッセージ（アクティブなチームサーフェスで自動配信）
              |       -> 進捗確認のためのtask-list/TodoWriteレビュー
              |       -> アクティブなチームサーフェスを通じてチームメイトにメッセージを送信（ブロック解除/調整）
              |
              +-- 完了
                      -> アクティブなチームサーフェスを通じて各チームメイトにシャットダウンを要求
                      <- チームメイトからのシャットダウン確認
                      -> OMCチーム状態をクリア（TeamDelete呼び出しなし）
                      -> rm .omc/state/team-state.json

ネイティブClaude Codeチームモデル（2.1.178+）:

- このスキルによって、チームごとの ~/.claude/teams/<name>/ ディレクトリは作成されません。
- TeamCreate/TeamDelete 呼び出しは利用できません。
- `team_name` はネイティブClaude Codeでは無視されるレガシーメタデータとしてのみ受け入れられます。ルーティングに依存しないでください。
- Agent/Task で `name="worker-N"` を指定してチームメイトを直接起動します。

目標ワークフロー関係

Teamは、並列・ステージ実行におけるOMCの権限です。非決定論的な警告処理ではなく、決定論的な競合ポリシー refuse、adopt_existing、artifact_only を使用してください。タスクがClaude Codeの /goal、Ralph、またはアーティファクト専用Ultragoalに言及している場合でも、リーダーが明示的にハンドオフしない限り、Teamを主要なループ権限として維持してください。/goal は、文書化されたネイティブClaude Codeのハンドオフターゲットとして、またはリードセッションからの可視証拠としてのみ使用してください。/goal 評価者が独立してコマンドを実行したり、ファイルを読み取ったり、team-verify / team-fix を置き換えたりすることを主張しないでください。アーティファクト専用Ultragoal参照は、ワーカー実行そのものではなく、耐久性のある目標台帳/チェックポイント/証拠アーティファクトとして扱う必要があります。

ステージドパイプライン（正規のTeamランタイム）

Teamの実行は以下のステージドパイプラインに従います:

team-plan -> team-prd -> team-exec -> team-verify -> team-fix (ループ)

ステージエージェントルーティング

各パイプラインステージは専門エージェントを使用します（executorだけではありません）。リーダーはステージとタスクの特性に基づいてエージェントを選択します。

ステージ必須エージェントオプションエージェント選択基準
team-planexplore (haiku), planner (opus)analyst (opus), architect (opus)要件が不明確な場合は analyst を使用。システムに複雑な境界がある場合は architect を使用。
team-prdanalyst (opus)critic (opus)スコープに挑戦するために critic を使用。
team-execexecutor (sonnet)executor (opus), debugger (sonnet), designer (sonnet), writer (haiku), test-engineer (sonnet)エージェントをサブタスクタイプに一致させる。複雑な自律作業には executor (model=opus)、UIには designer、コンパイル問題には debugger、ドキュメントには writer、テスト作成には test-engineer を使用。
team-verifyverifier (sonnet)test-engineer (sonnet), security-reviewer (sonnet), code-reviewer (opus)常に verifier を実行する。認証/暗号変更には security-reviewer を追加。20ファイル以上またはアーキテクチャ変更には code-reviewer を追加。code-reviewer はスタイル/フォーマットチェックもカバー。
team-fixexecutor (sonnet)debugger (sonnet), executor (opus)型/ビルドエラーやリグレッションの特定には debugger を使用。複雑な複数ファイル修正には executor (model=opus) を使用。

ルーティングルール:

  1. エージェントはリーダーが選択します（ユーザーは指定しません）。 ユーザーの N:agent-type パラメータは team-exec ステージのワーカータイプのみをオーバーライドします。他のすべてのステージはステージに適した専門エージェントを使用します。
  2. 専門エージェントはexecutorエージェントを補完します。 分析/レビューはarchitect/critic Claudeエージェントに、UI作業はdesignerエージェントにルーティングします。Tmux CLIワーカーはワンショットであり、チーム通信には参加しません。
  3. コストモードはモデル層に影響します。 ダウングレード時: opus エージェントは sonnet に、sonnet は品質が許す限り haiku に。team-verify は常に少なくとも sonnet を使用します。
  4. リスクレベルに応じてレビューが強化されます。 セキュリティ重要または20ファイル以上の変更には、team-verify に security-reviewer + code-reviewer (opus) を含める必要があります。

ステージ開始/終了条件

  • team-plan
    • 開始: Team呼び出しが解析され、オーケストレーションが開始されます。
    • エージェント: explore がコードベースをスキャンし、planner がタスクグラフを作成します。複雑なタスクではオプションで analyst/architect。
    • 終了: 分解が完了し、実行可能なタスクグラフが準備されます。
  • team-prd
    • 開始: スコープが曖昧であるか、受け入れ基準が欠落しています。
    • エージェント: analyst が要件を抽出し、オプションで critic。
    • 終了: 受け入れ基準と境界が明確になります。
  • team-exec
    • 開始: タスクリストの割り当てとワーカーの起動が完了します。
    • エージェント: サブタスクごとに適切な専門家タイプとしてワーカーが起動されます（ルーティングテーブルを参照）。
    • 終了: 現在のパスの実行タスクが終了状態に達します。
  • team-verify
    • 開始: 実行パスが終了します。
    • エージェント: verifier + タスクに適したレビュー担当者（ルーティングテーブルを参照）。
    • 終了（成功）: 検証ゲートが通過し、必要なフォローアップはありません。
    • 終了（失敗）: 修正タスクが生成され、制御が team-fix に移ります。
  • team-fix
    • 開始: 検証で欠陥/リグレッション/未完了の基準が見つかりました。
    • エージェント: 欠陥のタイプに応じて executor/debugger。
    • 終了: 修正が完了し、フローは team-exec に戻り、次に team-verify に進みます。

検証/修正ループと停止条件

以下の条件が満たされるまで team-exec -> team-verify -> team-fix を続行します:

  1. 検証が成功し、必須の修正タスクが残っていない、または
  2. 作業が証拠とともに明示的な終端状態（blocked/failed）に達する。

team-fix は最大試行回数に制限されます。修正試行が設定された制限を超えた場合、終端状態 failed に移行します（無限ループ防止）。

ステージハンドオフ規則

ステージ間を移行する際、重要なコンテキスト（決定事項、却下された代替案、特定されたリスク）はリーダーの会話履歴にのみ存在します。リーダーのコンテキストが圧縮されたり、エージェントが再起動したりすると、この知識は失われます。

完了する各ステージは、移行前にハンドオフドキュメントを生成する必要があります。

リーダーは .omc/handoffs/<stage-name>.md にハンドオフを書き込みます。

ハンドオフ形式

## Handoff: <current-stage> → <next-stage>

- **Decided**: [このステージで行われた重要な決定]
- **Rejected**: [検討されたが却下された代替案とその理由]
- **Risks**: [次のステージで特定されたリスク]
- **Files**: [作成または修正された重要なファイル]
- **Remaining**: [次のステージが処理すべき残項目]

ハンドオフルール

  1. リーダーは次のステージのエージェントを起動する前に、以前のハンドオフを読み取ります。 ハンドオフの内容は次のステージのエージェント起動プロンプトに含まれ、エージェントが完全なコンテキストで開始できるようにします。
  2. ハンドオフは蓄積されます。 検証ステージは、完全な決定履歴を得るために、すべての以前のハンドオフ（plan → prd → exec）を読み取ることができます。
  3. チームがキャンセルされても、ハンドオフは .omc/handoffs/ に残り、セッション再開に使用できます。 ネイティブのClaude Codeチームクリーンアップでは削除されません。Claude Code 2.1.178+ には TeamDelete 呼び出しは存在しません。
  4. ハンドオフは軽量です。 最大10〜20行。決定とその根拠をキャプチャします。完全な仕様は含めません（仕様は DESIGN.md などの成果物ファイルに格納されます）。

例

## Handoff: team-plan → team-exec

- **Decided**: 3つのサービス (auth, api, worker) を持つマイクロサービスアーキテクチャ。永続化にはPostgreSQL。認証トークンにはJWT。
- **Rejected**: モノリス（スケーリングの問題）、MongoDB（チームの専門知識はSQL）、セッションクッキー（APIファースト設計）。
- **Risks**: WorkerサービスにはジョブキューにRedisが必要だが、まだプロビジョニングされていない。Authサービスには初期設計でレート制限がない。
- **Files**: DESIGN.md, TEST_STRATEGY.md
- **Remaining**: データベースマイグレーションスクリプト、CI/CDパイプライン設定、Redisプロビジョニング。

再開とキャンセルのセマンティクス

  • 再開: ステージ状態 + ライブタスクステータスを使用して、最後の非終端ステージから再開します。.omc/handoffs/ を読み取って、ステージ遷移コンテキストを復元します。
  • キャンセル: /oh-my-claudecode:cancel はチームメイトにシャットダウンを要求し、応答を待ち（ベストエフォート）、フェーズを cancelled に active=false でマークし、キャンセルメタデータをキャプチャし、チームリソースを削除し、ポリシーに従ってTeam状態をクリア/保持します。.omc/handoffs/ 内のハンドオフファイルは、潜在的な再開のために保持されます。
  • 終端状態は complete、failed、cancelled です。

Windows psmux tmux互換ゲート

ネイティブWindowsでは、実際にtmux互換バイナリが確認されるまでは、/team にWSLが必要であることやtmuxが利用できないことをユーザーに伝えないでください。ネイティブの psmux は tmux 互換コマンド（多くの場合 tmux / tmux.cmd）をインストールし、サポートされているTeamマルチプレクサです。

Windowsでブロックしたり、フォールバックする前に:

  1. tmux -V（またはプラットフォームに相当するコマンド（例: where tmux の後に tmux -V））を確認します。
  2. psmuxバックエンドによる tmux -V の成功をtmuxが利用可能として扱います。
  3. psmux/tmuxが利用可能な場合は、通常のTeamフローを続行します。WSLが必要であるというガイダンスを出力しないでください。
  4. tmux互換バイナリが利用できない場合のみ、ユーザーにネイティブWindowsサポートのためにpsmuxをインストールするか、代替としてWSL2を使用するように伝えます。

ワークフロー

フェーズ1: 入力の解析

  • N（エージェント数）を抽出し、1〜20であることを検証
  • agent-type を抽出し、既知のOMCサブエージェントにマッピングされることを検証
  • task の説明を抽出

フェーズ2: 分析と分解

explore または architect（MCPまたはエージェント経由）を使用してコードベースを分析し、タスクをN個のサブタスクに分割します:

  • 各サブタスクは、競合を避けるためにファイルスコープまたはモジュールスコープである必要があります
  • サブタスクは独立しているか、明確な依存関係の順序付けが必要です
  • 各サブタスクn

…

[翻訳のために切り捨てられました]

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

agent-doc-discipline

Writing-time discipline for documents agents consume (the five surfaces, specs, tickets, .omc/skills/) — every rule checkable and carrying a why, steps before reference, one meaning in one home, no restating what the environment already says. Mandatory at drydock seed generation and the launch C5 sediment pass; opt-in for any other agent-facing doc edit. The companion of minimal-code-discipline: that one disciplines code, this one disciplines papers.

ai-slop-cleaner

Clean AI-generated code slop with a regression-safe, deletion-first workflow and optional reviewer-only mode

ask

Process-first advisor routing for Claude, Codex, Gemini, Antigravity, Grok, or Cursor via `omc ask`, with artifact capture and no raw CLI assembly

ask-navigator

Shipyard

autopilot

Full autonomous execution from idea to working code

autoresearch

Stateful single-mission improvement loop with strict evaluator contract, markdown decision logs, and max-runtime stop behavior

cancel

Cancel any active OMC mode (autopilot, ralph, ultragoal, swarm, ultrapilot, pipeline, team) and clean up retired legacy state

configure-notifications

Configure notification integrations (Telegram, Discord, Slack) via natural language

debug

Diagnose the current OMC session or repo state using logs, traces, state, and focused reproduction

deepinit

Deep codebase initialization with hierarchical AGENTS.md documentation

deep-interview

Socratic deep interview with mathematical ambiguity gating before explicit execution approval

drydock

Lay the keel of the shipyard harness in any repo — the 4-pillar shared environment (Context, Rules, Tools, Standards) across 5 surfaces (CLAUDE.md, skills, design-system, mcp/cli, shared context) so that every human and agent inherits the same design language and anyone can ship. Run once per repo; re-run with --check to audit drift.

execute

Carry an approved task through to working, verified code

external-context

Invoke parallel document-specialist agents for external web searches and documentation lookup

graph

Deterministic orchestration graph runtime - declarative DAG pipelines with journal-based crash recovery

harbor

Harbor intake for external work — the captain only handles unresolved decisions. Sweeps incoming issues and PRs, verifies every claim before disposition, reuses every decision already made, and hands the maintainer a docket whose pending items each carry one question with options, recommendation, impact and evidence. Agent-autonomous for facts and for actions covered by standing authorization; signed for every new judgment. Never merges.

hud

Configure HUD display options (layout, presets, display elements)

launch

Shipyard

loft

Loft the shape before cutting steel — answer a design question that prose cannot settle by building a throwaway artifact: a pure logic module in a clickable shell, or structurally different UI variants behind one route. The captain reacts to the artifact; the answer folds into the decision; the artifact never docks. Use when a design question stalls in words, when a navigator map carries a loft ticket, or when a spec discussion reaches

minimal-code-discipline

YAGNI-ladder coding discipline for writing changes — existence-first, reuse before writing, dependency ladder, shortest correct diff, with non-negotiables that must never be minimized away

関連スキル

steipete/video-frames

Extract frames or short clips from videos using ffmpeg.

community

steipete/summarize

Summarize or transcribe URLs, YouTube/videos, podcasts, articles, transcripts, PDFs, and local files.

community

openclaw/openclaw

Use when testing, fixing, or extending the OpenClaw Control UI GUI with Vitest + Playwright end-to-end checks, mocked Gateway WebSocket flows, mocked dashboard runs, screenshots/videos, or agent-verifiable browser proof.

community

obra/superpowers

Obra superpowers agent skills.

community

affaan-m/ECC

See, Understand, Act on video and audio. See- ingest from local files, URLs, RTSP/live feeds, or live record desktop; return realtime context and playable stream links. Understand- extract frames, build visual/semantic/temporal indexes, and search moments with timestamps and auto-clips. Act- transcode and normalize (codec, fps, resolution, aspect ratio), perform timeline edits (subtitles, text/image overlays, branding, audio overlays, dubbing, translation), generate media assets (image, audio...

community

affaan-m/everything-claude-code

End-to-end marketing campaign planning and execution. Covers audience research, positioning, campaign angle definition, landing page copy, email sequences, social posts, ad copy, short-form video scripts, and content calendars. Use as the orchestration layer for multi-channel product launches. Use when planning or executing a multi-channel product launch, or producing landing page, email, social, or ad copy.

community