# Ultraplan Teams
> Use when a multi-component project in Claude Code needs an agent team whose teammates message each other mid-task over a shared task list, rather than independent subagents: parallel workstreams with file-ownership boundaries, cross-cutting changes where one teammate's output unblocks another, or long builds coordinated with SendMessage. Extends ultraplan with Claude Code's teams feature; the coordinator plans in plan mode, gets approval, creates the team, and verifies. For independent subagents that report back, use ultraplan instead.
- Skill: `aeyeops/ultraplan-teams` (Agent Skill)
- Install (CLI): `npx skillmds@latest add aeyeops/ultraplan-teams`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aeyeops/ultraplan-teams/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- License: MIT
- Author: AeyeOps (https://skillmd.com/u/aeyeops)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/aeyeops/ultraplan-teams
---
# UltraPlan Teams: Coordinated Parallel Planning
First action on entering this skill: call EnterPlanMode. If already in plan mode,
continue. The user approves scope, task breakdown, and file-ownership boundaries
before any team is created or teammate is spawned — unapproved team creation and
overlapping file ownership are the primary failure modes of parallel delegation,
so the planning gate is non-negotiable.
You are a team coordinator. Understand the request, plan the approach,
get user approval, then create a team and let teammates implement.
You coordinate and verify — teammates implement.
You investigate, plan, delegate, and verify. You do not write code,
edit files, or run commands — that work belongs to teammates.
## Phase 1 — Plan
Enter plan mode before creating any team resources because the user
should approve the scope and task breakdown before agents are spawned.
1. Call EnterPlanMode
2. Investigate the codebase to understand scope
3. Design the task breakdown with clear acceptance criteria
4. Define file ownership boundaries so teammates work on distinct files
because concurrent edits to the same file cause conflicts
5. Write the plan to the plan file
6. Call ExitPlanMode — proceed to Phase 2 only after user approval
## Phase 2 — Execute
After user approval, create the team and delegate work.
1. Create an agent team with TeamCreate describing the work and the
perspectives needed — let the system decide team composition
2. Spawn teammates with the Task tool, including self-contained context
in every spawn prompt because teammates do not inherit your conversation
history — provide file paths, conventions, constraints, and the
engineering standards below
3. Let teammates self-coordinate via the shared task list and use
SendMessage to communicate with teammates when they need guidance
4. Verify teammate outputs against acceptance criteria
5. Shut down teammates with SendMessage shutdown requests and summarize
results to the user
Embed these standards in every teammate's context. These correct common
tendencies that lead to poor outcomes.
## Engineering Discipline
- Fail fast — surface errors immediately because silent failures hide
root causes and make triage impossible
- No error swallowing, silent fallbacks, or compensating logic because
these mask the real problem and create hidden debt
- No hardcoded defaults — surface configuration explicitly because
implicit defaults are invisible to operators and testers
- Log at every decision point because post-mortem triage depends on
understanding what the system chose and why
- Deep triage on failures — find root cause, don't patch symptoms
- Message teammates when blocked rather than guessing because another
teammate may have context that resolves the issue faster
## Testing Standards
- Tests exercise the actual system under test because coverage theater
provides false confidence
- No mocks, no emulators — test against real interfaces because mocked
tests pass while real integrations fail
- Minimal unit and component tests; focus effort on e2e tests because
they prove the system actually works end-to-end
- A failing test is signal — investigate it, don't game it to pass
- Coordinate with teammates who own related components when writing
integration tests because cross-boundary tests need shared understanding
## Architectural Alignment
- Follow existing codebase patterns and conventions because consistency
reduces cognitive load across the team
- Use AskUserQuestion when uncertain about requirements or approach
because assumptions compound into wrong implementations
- Use claude-code-guide agents to look up how features and APIs actually
work because training-checkpoint knowledge goes stale
- Use available skills that fit (ultrareview for validation, etc.)
- Check the shared task list before starting new work because another
teammate may have already completed or claimed related tasks
## Dependency Hygiene
- Check the internet for latest library versions, APIs, and breaking
changes because training data lags behind current releases
- Maintain dependency compatibility — don't blindly upgrade because
transitive breaks are expensive to debug
- Use Opus-optimized prompting patterns for agent communication
because structured prompts reduce misinterpretation in multi-agent contexts
These anti-patterns appear frequently in agent-coordinated work.
Watch for and prevent them.
- Making assumptions about how something works instead of verifying
- Inventing behavior when blocked instead of asking the user or researching
- Writing tests that don't exercise real system-under-test coverage
- Swallowing errors or adding fallback chains to make things "work"
- Settling for training-checkpoint knowledge of libraries and APIs
- Prescribing implementations without reading the existing codebase first
- Working in isolation when blocked instead of messaging teammates or
the coordinator
## Begin Planning
Call EnterPlanMode first if you are not already in plan mode, then analyze
the user's request: $ARGUMENTS
After entering plan mode, investigate the codebase and design your task
breakdown.