team-implement

What this skill does

# Team Implement

Adaptive spec-driven development team that scales from 3 agents (lite) to 11 agents (full) based on project complexity. All planning completes before any code changes, with explicit user approval between planning and implementation.

## Prerequisites

**Full mode** requires the experimental agent teams flag. Add to your environment or `settings.json`:

```
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
```

**Lite mode** works without this flag (uses Task subagents instead of Teammate API).

**Delegate mode** (recommended for full mode): Press `Shift+Tab` to enable delegate mode, which restricts the lead to coordination-only tools and prevents it from implementing tasks itself. Without delegate mode, always wait for teammates to complete their tasks before proceeding — do not implement tasks yourself.

## Input

$ARGUMENTS

## Known Limitations

- **No session resumption**: `/resume` does not restore teammates. If a session is interrupted mid-team, teammates are lost
- **One team per session**: Cannot run multiple team-implement invocations simultaneously
- **No nested teams**: Teammates cannot spawn their own teams
- **Task status can lag**: Teammates sometimes forget to mark tasks complete; orchestrator should monitor
- **Teammates load CLAUDE.md**: Project-specific guidance applies automatically to all agents (this is a benefit)

## Workflow Overview

```
MACRO PHASE A: PLANNING (no code changes)
  Phase 0: Input Ingestion & Discovery
  Phase 1: Clarifying Questions
  Phase 2: Specification
  Phase 3: Architecture & Design
  Phase 4: Adversarial Review
  Phase 5: Task Decomposition

  ══════════════════════════════════════
  USER APPROVAL GATE
  ══════════════════════════════════════

MACRO PHASE B: IMPLEMENTATION (code changes)
  Phase 6: Implementation
  Phase 7: Quality Assurance
  Phase 8: Documentation & Delivery
  Phase 9: Teardown
```

---

## Phase 0: Input Ingestion & Discovery

### Step 0.1: Detect Input Source

Parse `$ARGUMENTS` to determine the input type. For detection patterns and ingestion commands, see [references/spec-workflow.md](references/spec-workflow.md) Section 1.

**Detection order** (first match wins):

| Pattern | Source Type | Ingestion |
|---------|-----------|-----------|
| `PROJ-123` | Jira ticket | `jira issue view PROJ-123 --json` |
| `#42` or `owner/repo#42` | GitHub issue | `gh issue view 42 --json title,body,labels,comments` |
| `!123` or PR URL | GitHub PR | `gh pr view 123 --json title,body,files,comments,labels` |
| Existing file path | File | Read file content |
| Existing directory path | Directory | Read README.md, CLAUDE.md, key files |
| `http://` or `https://` | URL | WebFetch to extract content |
| Everything else | Plain text | Use directly as requirements |

### Step 0.2: Project Discovery

Spawn an Explore/haiku agent to understand the project:

```
Task tool (Explore, haiku):
"Discover the project's technology stack and development workflow:
  1. Read CLAUDE.md and README.md for project context
  2. Check for task runners: Makefile, package.json, pyproject.toml
  3. Identify test, lint, build, dev server commands
  4. Map major components and modules
  5. Note frameworks, databases, authentication patterns
  6. Find existing patterns and conventions
  Return: structured summary of project architecture and available commands."
```

### Step 0.3: Assess Complexity

Evaluate complexity signals to determine team mode. See [references/spec-workflow.md](references/spec-workflow.md) Section 2 for the full scoring matrix.

| Signal | +2 (Full) | +1 (Medium) | 0 (Lite) |
|--------|-----------|-------------|----------|
| Components affected | 3+ (frontend + backend + DB + infra) | 2 components | Single component |
| Security sensitivity | Auth, payments, PII | Permission checks | No sensitive data |
| Performance requirements | Real-time, SLAs | Caching, optimization | Standard CRUD |
| External integrations | 2+ APIs/services | 1 external API | Self-contained |
| Estimated file changes | 15+ files | 10-14 files | <10 files |
| Domain familiarity | Unfamiliar tech | Partially familiar | Well-understood |

**Thresholds:**
- Score 0-1: Use **lite mode** automatically
- Score 2-3: Ask user (recommend lite)
- Score 4+: Use **full mode** automatically

### Step 0.4: Generate Spec Namespace

Create `.specs/<short-id>/` directory. Format: `<slugified-title>-<YYYYMMDD>` (e.g., `auth-oauth2-20260205`). See [references/spec-workflow.md](references/spec-workflow.md) Section 3 for the generation algorithm.

### Step 0.5: Create Initial Artifacts

1. Create `.specs/<short-id>/` directory
2. Write `.specs/<short-id>/input-digest.md` using template from [references/spec-templates.md](references/spec-templates.md)
3. Write `.specs/<short-id>/README.md` (session dashboard)
4. Update `.specs/README.md` (global index) — create if first spec session

### Step 0.6: Git Handling (first time only)

If `.specs/` does not already exist in git or `.gitignore`, ask the user:

```
AskUserQuestion:
  question: "How should .specs/ be handled in git?"
  options:
    - "Commit to git (specs are part of the project)"
    - "Add to .gitignore (specs are local-only)"
```

### Step 0.7: Propose Team Composition

Present the mode decision and team composition to the user for confirmation:

```
AskUserQuestion:
  question: "Complexity assessment complete. Proceed with this team?"
  options:
    - "[MODE] mode with [ROLES] (Recommended)"
    - "Switch to [OTHER_MODE] mode"
    - "Customize team composition"
```

**Full mode team spawn:**
```
Teammate({ operation: "spawnTeam", team_name: "team-<short-id>" })
```

---

## Phase 1: Clarifying Questions

**CRITICAL**: Before any planning begins, analyze the input digest for ambiguities.

Look for:
- Vague requirements ("should support authentication" — which kind?)
- Missing acceptance criteria
- Unclear scope boundaries (what's in/out)
- Technology decisions needing user input
- Conflicting requirements

Use `AskUserQuestion` to resolve ambiguities. Multiple rounds are fine. Only proceed when requirements are clear enough to specify.

If the input is already well-defined (e.g., detailed Jira ticket with acceptance criteria), this phase can be brief or skipped.

---

## Phase 2: Specification

### Full Mode

Spawn **Product Manager** and **Scrum Master** (Wave 1). See [references/agent-catalog.md](references/agent-catalog.md) for complete prompt templates.

```
Task tool (team_name: "team-<short-id>", name: "product-manager"):
  subagent_type: general-purpose
  model: sonnet
  prompt: [Product Manager prompt from agent-catalog.md, substituting SPEC_ID and project context]
```

Product Manager writes:
- `.specs/<short-id>/proposal/brief.md`
- `.specs/<short-id>/proposal/requirements.md`
- `.specs/<short-id>/proposal/acceptance-criteria.md`

Scrum Master reviews for completeness.

**Gate: Spec Review** — Orchestrator validates coherence, asks user about remaining gaps.

### Lite Mode

Spawn **Product Analyst** subagent (via Task, not Teammate). See [references/agent-catalog.md](references/agent-catalog.md) Combined Agent 12.

Product Analyst writes:
- `.specs/<short-id>/brief.md`
- `.specs/<short-id>/design.md` (combined)

---

## Phase 3: Architecture & Design

### Full Mode

Spawn **Architect** (Wave 2, **opus** model). See [references/agent-catalog.md](references/agent-catalog.md) Agent 3.

```
Task tool (team_name: "team-<short-id>", name: "architect"):
  subagent_type: general-purpose
  model: sonnet
  prompt: [Architect prompt from agent-catalog.md]
```

Architect writes:
- `.specs/<short-id>/design/architecture.md`
- `.specs/<short-id>/design/api-contracts.md`
- `.specs/<short-id>/design/data-model.md`
- `.specs/<short-id>/design/diagrams/system-overview.md`
- `.specs/<short-id>/decisions/NNNN-*.md` (lightweight ADRs)

### Lite Mode

**Architect/Developer** subagent writes `.specs/<short-id>/design.md` (combined). See [references/agent-catalog.md](references/agent-catalog.md) Combin