---
description: "Full pipeline in local mode  -  no worktree, runs directly on the current branch. Use when the full pipeline should run on the current branch without creating a worktree."
description-tr: "Tam pipeline lokal modda - worktree yok, doğrudan mevcut branch üzerinde çalışır."
allowed-tools: Agent, Bash, Read, Write, Edit, Glob, Grep, TaskCreate, TaskUpdate, TaskList, TaskGet, AskUserQuestion, WebFetch, WebSearch, Skill
---

# multi-agent local  -  Full Pipeline, Local Branch

> **Language (read FIRST)**: Before any status output, read `prefs.global.outputLanguage` and render every conversational line in it. `AskUserQuestion` `label`/`header` stay English, but its `question` and option `description`s render in `outputLanguage`; external payload bodies follow `outputLanguage` too (identifiers, commit messages, branch names stay English). Full contract: `$HOME/.claude/multi-agent-refs/rules.md` "Language Application".

The full pipeline in normal mode (Plan Approval Gate + parallel review + triage included), running on the **current branch with no worktree**. Dedicated alias for the `multi-agent "task" --local` flag form. Phase 5 (User Test) is skipped because there is no worktree to check the change out from; the other seven phases all run.

## When to use it

- You don't want a separate worktree open  -  keeps the editor / IDE in one folder
- You're already on the right branch and just want pipeline discipline
- Small project or prototype  -  the worktree overhead is unnecessary

## When NOT to use it

- Multiple parallel tasks at the same time  -  you lose worktree isolation
- Long-iteration changes on a production repo  -  branch-switch friction shows up
- Multi-repo tasks  -  `--local` is locked to a single repo

## Pipeline

Same phase count and order as the normal pipeline:

```
Phase 0: Init       → project detection, branch check, state (NO worktree)
Phase 1: Analysis   → codebase scan (parallel explore agents, Opus)
Phase 2: Planning   → task breakdown, Plan Approval Gate (approval loop)
Phase 3: Dev        → TDD (Sonnet), build queue
Phase 4: Review     → deterministic gates + parallel review + Fable triage
Phase 6: Commit     → pre-commit checkout prompt, commit + push + PR
Phase 7: Report     → Jira / Wiki / Confluence + log + knowledge/memory
```

## Delegation

This command routes to the orchestrator with the `--local` flag set. The Phase 0-7 contract from `$HOME/.claude/multi-agent-refs/phases/phase-0-init.md` and the later phase docs applies as-is  -  only the worktree step is skipped, and `state.projects[*].worktreePath` stays `null`.

Read the routing table in `$HOME/.claude/commands/multi-agent/SKILL.md` and apply Phase 0 Step 8 in local mode (no worktree: continue on the current branch, state file under `.claude/logs/multi-agent/{project}/{taskId}/`).

## Examples

```bash
/multi-agent:local "PROJ-12345"                                # Jira
/multi-agent:local "#42"                                        # GitHub issue
/multi-agent:local "LoginView dark mode fix"                    # Free-text
```
## Required: outward-facing payload contracts

Before writing anything outward-facing  -  PR body, Jira comment, Confluence page, closing report  -  load `$HOME/.claude/multi-agent-refs/payload-contracts.md`. It names the canonical section set for each payload, the markup dialect per surface (PR body is Markdown, Jira is wiki markup  -  mixing them is a defect), and the token/duration numbers the closing report must carry. Improvising a payload shape from memory is the most common failure of the short modes.

## Required: Phase Tracker Contract

**The phase tracker is mandatory**  -  the agent cannot skip it. Full spec: [`$HOME/.claude/multi-agent-refs/tracker-contract.md`]($HOME/.claude/multi-agent-refs/tracker-contract.md).

> **Local mode:** no worktree is created, work happens on the current branch. Phase 0 Init still calls `init`  -  the `--local` flag is stored in tracker-state.json, and `:resume` restores the correct CWD.

Two channels run in parallel at every phase boundary:

1. **State channel** (every CLI, identical): `phase-tracker.sh` writes to `tracker-state.json`. Drives `:resume`, `:log`, `:status`.
2. **Visual channel** (CLI-specific): native widget on Claude Code, ANSI render on every other CLI. Without it the user sees no phase progress.

```bash
# Phase 0, very first shell call (every CLI):
bash $HOME/.claude/scripts/phase-tracker.sh init "$TASK_ID"
for p in "0:Init" "1:Analysis" "2:Planning" "3:Dev" "4:Review" "6:Commit" "7:Report"; do
  bash $HOME/.claude/scripts/phase-tracker.sh add "${p%%:*}" "${p#*:}"
done
bash $HOME/.claude/scripts/phase-tracker.sh update 0 in_progress

# Every phase boundary (every CLI):
bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress|completed|failed|skipped

# After every LLM call (every CLI):
bash $HOME/.claude/scripts/phase-tracker.sh tokens <N> <in> <out> [cached]
```

### Visual channel  -  Claude Code (native TaskList widget, required)

In Claude Code the agent MUST also drive the native TaskList widget so the user sees a sticky phase tile stack  -  this is the only progress signal Claude Code surfaces. Skipping these calls is the #1 source of "I don't see any phases" complaints.

**TaskCreate ordering (strict)**: All TaskCreate calls fire in strict phase-number order BEFORE any TaskUpdate is applied. The native widget renders by creation order, not by phase number  -  out-of-order calls produce visually scrambled tile stacks (e.g. `1 ✓ · 2 ✓ · 4 ✓ · 0 ▶ · 3 ☐`) even when the underlying state is correct. Pre-marking phases as completed/skipped before Phase 0 starts is FORBIDDEN  -  register the tile in order, then flip status via TaskUpdate when the phase actually short-circuits. Full contract in `$HOME/.claude/multi-agent-refs/tracker-contract.md` section "TaskCreate ordering (strict)".

```text
# Phase 0 startup  -  register one tile per phase (0..N), capture the taskId, persist it:
for each phase in 0:Init, 1:Analysis, 2:Planning, 3:Dev, 4:Review, 6:Commit, 7:Report:
  TaskCreate({ subject: "Phase <N>: <Name>", activeForm: "<doing-form>" })
    -> returns taskId
  bash $HOME/.claude/scripts/phase-tracker.sh meta <N> tasklist_id "<taskId>"

# Phase entry  -  flip the tile to in_progress alongside the state update:
TaskUpdate({ taskId: <saved>, status: "in_progress" })
bash $HOME/.claude/scripts/phase-tracker.sh update <N> in_progress

# Active sub-step inside a phase  -  update activeForm so the spinner header reflects what's happening now:
TaskUpdate({ taskId: <saved>, activeForm: "Editing TopBarView.swift" })

# Phase exit  -  flip to completed/failed/skipped on both channels:
TaskUpdate({ taskId: <saved>, status: "completed" })
bash $HOME/.claude/scripts/phase-tracker.sh update <N> completed
```

`--local` mode does NOT TaskCreate phases 5  -  those are not part of the `--local` phase set (`0:Init 1:Analysis 2:Planning 3:Dev 4:Review 6:Commit 7:Report`). Only register tiles for the active set.

#### TaskCreate ordering (strict)

**All TaskCreate calls fire in strict phase-number order BEFORE any TaskUpdate is applied.** For `--local` that means: Phase 0 → Phase 1 → Phase 2 → Phase 3 → Phase 4 → Phase 6 → Phase 7. The native widget renders by creation order, not by phase number  -  out-of-order calls produce visually scrambled tile stacks. Full ordering contract in `$HOME/.claude/multi-agent-refs/tracker-contract.md` section "TaskCreate ordering (strict)".

### Visual channel  -  Copilot CLI / plain shell

These CLIs have no TaskList widget. After every state change the agent calls render, which prints a bordered ANSI card as the last tool result so the user sees an updated phase table:

```bash
bash $HOME/.claude/scripts/phase-tracker.sh render
```

Do NOT call TaskCreate on these CLIs  -  the tool does not exist and the call fails.