flow-parallel

ホスト：Codex CLI — このスキルはClaude Code向けに設計され、Codex用に適応されています。 相互参照コマンドでは、/octo:* スラッシュコマンドではなく、Codexにインストールされているスキル名を使用します。 アクティブなCodexシェルとサブエージェントのツールを使用してください。現在のセッションで利用可能であることが確認できるまでは、プロバイダー、モデル、ホストのサブエージェントが利用可能だと主張しないでください。 ホストツールとの対応については、skills/blocks/codex-host-adapter.mdを参照してください。

停止 — スキルはすでに読み込まれています

Skill()を再度呼び出さないでください。これ以上スキルを読み込まないでください。そのまま実行してください。

実行契約（必須 — 省略不可）

このスキルでは強制実行モードを使用します。この7段階の手順に正確に従う必要があります。

設計原則： ホストのサブエージェントツールのサブエージェントはプラグインを読み込みません。一方、独立したclaude -pプロセスは読み込みます。このスキルは独立したclaude -pプロセスを起動するため、各作業パッケージでOctopusプラグイン一式、独自のDouble Diamond、エージェント、品質ゲートが利用できます。

ステップ1：確認の質問（必須）

ほかの操作を行う前に、AskUserQuestionを使って質問してください。

ユーザーから以下の情報を必ず収集してください。スコープ、件数、依存関係の回答がないと、分解が一般的なものになり、重複する作業パッケージが作られてマージの競合が発生します。

AskUserQuestion with these questions:

1. **Compound task**: What compound task should be decomposed?
   - Use inline args if provided (e.g., /octo:parallel "build auth system")
   - If no args: ask "What compound task should I decompose into parallel work packages?"

2. **Work package count**: How many work packages?
   - Options: "3 (Recommended)", "4", "5", "Custom (up to 10)"
   - Default: 3-5 is optimal

3. **Dependencies**: Are the work packages independent?
   - "Fully independent - no dependencies between packages (Recommended)"
   - "Some dependencies - packages may need to share interfaces"
   - "Sequential dependencies - packages must complete in order"

ユーザーがコマンドとともに説明を入力した場合（例：/octo:parallel build a full auth system with OAuth, RBAC, and audit logging）、それをタスクの説明として使用します。ただし、残りの質問（件数、依存関係）は引き続き尋ねてください。

いずれかの質問にユーザーが「スキップ」と答えた場合は、デフォルト（作業パッケージ3件、完全に独立）を使用してください。

質問に回答があるまで、ステップ2に進まないでください。

ステップ2：視覚的なインジケーターを表示（必須 — ブロッキング）

必須：バナーを表示する前に、ネイティブのシェルコマンドツールを使ってプロバイダーチェックを実行してください。省略したり、利用可能だと決めつけたりしないでください。

bash "${HOME}/.claude-octopus/plugin/scripts/helpers/check-providers.sh"

以下の実際の結果を使用してください。禁止事項：すべてのプロバイダーを一覧にせず、「🔵 Claude：利用可能 ✓」だけを表示すること。

分解を始める前に、実際のプロバイダー状況を反映したこのバナーを表示してください。

🐙 CLAUDE OCTOPUS ACTIVATED - Team of Teams Mode
Parallel Phase: Decomposing compound task into N independent work packages

Architecture:
  Main (this session) - Orchestrator: decompose, launch, monitor, aggregate
  WP-1..WP-N (claude -p) - Independent workers with full plugin capabilities

Each worker:
  - Runs as independent claude -p process in its own git worktree
  - Loads full Octopus plugin
  - Has own context, tools, and quality gates
  - Produces output.md + exit-code
  - Tracked in agent registry (~/.claude-octopus/agents/registry.json)

Estimated Time: 5-15 minutes (depending on task complexity)

バナーを表示するまで、ステップ3に進まないでください。

ステップ3：以前の状態を読み込む（必須 — 状態管理）

分解する前に、以前のコンテキストを読み込んでください。

# Initialize state if needed
if [[ -d ".octo" ]]; then
  echo "Found existing .octo/ state directory"
else
  echo "No prior .octo/ state found - starting fresh"
fi

# Check for prior discover/spec context
if [[ -f ".octo/STATE.md" ]]; then
  echo "Prior state found:"
  cat .octo/STATE.md
fi

if [[ -f ".octo/PROJECT.md" ]]; then
  echo "Prior project context found:"
  cat .octo/PROJECT.md
fi

以前のコンテキスト（発見事項、仕様定義、プロジェクトの状態）を活用し、WBSの分解に反映してください。

状態の読み込みが完了するまで、ステップ4に進まないでください。

ステップ4：WBSに分解する（必須）

Claudeが複合タスクを分析し、作業分解構成図を作成します。

分解ルール：

• 独立した作業パッケージを3～5件に分割します（WP-1からWP-N、最大10件）。
• 各WPに、名前、スコープの説明、想定される出力ファイル、依存関係を設定します。
• スコープが重複していないこと、全体として漏れがないことを検証します。
• 各WPは、独立したclaude -pプロセスで実行できるだけの自己完結性を備えている必要があります。

調整用ディレクトリとWBSを作成してください。

# Create parallel coordination directory
mkdir -p .octo/parallel

# Write wbs.json
cat > .octo/parallel/wbs.json << 'WBSEOF'
{
  "task": "<compound task description>",
  "created": "<ISO timestamp>",
  "work_packages": [
    {
      "id": "WP-1",
      "name": "<work package name>",
      "scope": "<what this WP covers>",
      "expected_outputs": ["<list of files this WP should produce>"],
      "dependencies": [],
      "wave": 1,
      "branch": "<a branch name unique to this work package>",
      "status": "pending"
    }
  ]
}
WBSEOF

**分析した複合タスクに基づいて、実際のWBSの内容を必ず記述してください。**上記のJSONはテンプレートです。実際の分解内容を入力してください。テンプレートやプレースホルダーのままのWBSでは指示が曖昧になり、エージェントごとに解釈が異なって、作業の重複やスコープの見落としが発生します。

検証ゲート：wbs_generated — .octo/parallel/wbs.jsonが存在し、有効なJSONを含んでいることを確認してください。

# Validate WBS was created
if [[ -f ".octo/parallel/wbs.json" ]]; then
  python3 -c "import json; json.load(open('.octo/parallel/wbs.json')); print('WBS validation: PASSED')" 2>/dev/null || echo "WBS validation: FAILED - invalid JSON"
else
  echo "WBS validation: FAILED - file not found"
fi

WBSの検証が完了するまで、ステップ5に進まないでください。

STEP 4.5: 敵対的WBSクロスチェック（推奨）

WBSを生成した後、依存関係を検証する前に、2つ目のモデルを使って分解内容をクロスチェックします。 単一モデルによる分解では、隠れた依存関係、曖昧なインターフェース契約、スコープの抜けがあるワークパッケージが生じることが多く、マージ競合や作業の重複につながります。

外部プロバイダーが利用可能な場合は、Octopusルーティングを通じてWBSを敵対的レビューにかけます。

WBS_CONTENT=$(<".octo/parallel/wbs.json")
review_provider=""
command -v codex >/dev/null 2>&1 && review_provider="codex"
[[ -z "$review_provider" ]] && command -v agy >/dev/null 2>&1 && review_provider="agy"

if [[ -n "$review_provider" ]]; then
  "${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh" spawn "$review_provider" \
    "Review this Work Breakdown Structure for a parallel execution pipeline. Your job is to find problems BEFORE agents start working.

1. What DEPENDENCIES between work packages were missed? (e.g., WP-2 needs a type definition from WP-1 but doesn't declare it)
2. What INTERFACE CONTRACTS are ambiguous? (e.g., two WPs will create conflicting exports, or expect different API signatures)
3. Do any work packages OVERLAP in scope? (e.g., both WP-1 and WP-3 might modify the same file)
4. Are there GAPS — things no work package covers?

WBS:
${WBS_CONTENT}" 2>/dev/null || true
fi

レビュー結果を受け取った後：

• スコープの重複が見つかった場合：WBSのWPの境界とファイルパスを調整します
• 依存関係の不足が見つかった場合：dependencies 配列に追加します
• インターフェースの曖昧さが見つかった場合：該当するWPの指示に明示的なIntegration Contractセクションを追加します
• 抜けが見つかった場合：新しいWPを追加するか、既存のWPのスコープを拡張します

--fast が指定されている場合、またはユーザーが徹底性より速度を明示的に優先している場合は、この手順をスキップします。

STEP 4.6: 依存関係の検証とWaveの割り当て（必須）

いずれかのワークパッケージの dependencies が空でない場合は、依存関係グラフを検証し、Wave番号を割り当てます。

すべてのワークパッケージが "dependencies": [] の場合は、この手順をスキップします。すべてのワークパッケージにWave 1が割り当てられます（後方互換性）。

依存関係の検証とWaveの割り当てを実行します：

python3 << 'DEPEOF'
import json, sys

with open('.octo/parallel/wbs.json') as f:
    wbs = json.load(f)

packages = wbs['work_packages']
ids = {wp['id'] for wp in packages}
deps = {wp['id']: wp.get('dependencies', []) for wp in packages}

# Check for missing references
errors = []
for wp_id, wp_deps in deps.items():
    for dep in wp_deps:
        if dep not in ids:
            errors.append(f"WP {wp_id} depends on unknown {dep}")

if errors:
    print("DEPENDENCY VALIDATION: FAILED")
    for e in errors:
        print(f"  ERROR: {e}")
    sys.exit(1)

# Cycle detection (DFS)
WHITE, GRAY, BLACK = 0, 1, 2
color = {wp_id: WHITE for wp_id in ids}

def has_cycle(node, path):
    color[node] = GRAY
    for dep in deps[node]:
        if color[dep] == GRAY:
            cycle = path[path.index(dep):] + [dep]
            return cycle
        if color[dep] == WHITE:
            result = has_cycle(dep, path + [dep])
            if result:
                return result
    color[node] = BLACK
    return None

for wp_id in ids:
    if color[wp_id] == WHITE:
        cycle = has_cycle(wp_id, [wp_id])
        if cycle:
            print(f"DEPENDENCY VALIDATION: FAILED - Cycle detected: {' -> '.join(cycle)}")
            sys.exit(1)

# Topological sort and wave assignment
waves = {}
assigned = set()

def get_wave(wp_id):
    if wp_id in waves:
        return waves[wp_id]
    if not deps[wp_id]:
        waves[wp_id] = 1
        return 1
    max_dep_wave = max(get_wave(d) for d in deps[wp_id])
    waves[wp_id] = max_dep_wave + 1
    return waves[wp_id]

for wp_id in ids:
    get_wave(wp_id)

# Update WBS with wave assignments
for wp in packages:
    wp['wave'] = waves[wp['id']]

with open('.octo/parallel/wbs.json', 'w') as f:
    json.dump(wbs, f, indent=2)

max_wave = max(waves.values())
print(f"DEPENDENCY VALIDATION: PASSED")
print(f"Waves assigned: {max_wave}")
for w in range(1, max_wave + 1):
    wave_wps = [wp_id for wp_id, wave in waves.items() if wave == w]
    print(f"  Wave {w}: {', '.join(wave_wps)}")
DEPEOF

検証に失敗した場合： エラーをユーザーに報告して停止します。無効な依存関係のまま続行してはいけません。

依存関係が検証されるまで（または独立したWPの場合は手順をスキップするまで）、STEP 5に進んではいけません。

STEP 5: 指示ファイルの生成（必須）

WBS内の各ワークパッケージについて、指示ファイルと起動スクリプトを作成します。

各WP-Nについて、以下を作成します：

instructions.md

mkdir -p ".octo/parallel/WP-N"

cat > ".octo/parallel/WP-N/instructions.md" << 'INSTREOF'
# Work Package WP-N: <name>

## Task
<Clear description of what this work package must accomplish>

## Scope Boundaries
- IN SCOPE: <what this WP covers>
- OUT OF SCOPE: <what other WPs handle — explicit boundaries>

## Expected Output
- Files to create/modify: <explicit file paths — MANDATORY>
- Location: <where outputs go in the project>

## Integration Contract
- This WP produces: <what downstream consumers can expect>
- This WP consumes: <what it needs from the project, NOT from other WPs>

## Quality Requirements (MANDATORY)
- Code must compile/parse without errors
- Follow existing project conventions (naming, structure, patterns)
- Run any existing tests related to your changes — do NOT skip tests
- Run the project linter if one exists (eslint, ruff, golangci-lint, etc.)
- No `type: ignore`, `@ts-ignore`, `any` casts, or suppression comments unless the existing code already uses them
- No placeholder code — no `TODO`, `FIXME`, or stub implementations
- Verify your changes work by running or testing them before completing
- If you break existing tests, fix them — do not delete or skip them

## Committing (MANDATORY if you changed any file)
- Commit your work to this package's own branch before you finish. The worktree is removed once
  your commit exists and the tree is clean. Uncommitted work is retained for recovery.
- Stage explicit paths. Never `git add -A` or `git add .` — the coordination directory and other
  packages' stray files must not enter your commit.

## Dependency Context
- This WP depends on: <list of dependency WP IDs, or "none">
- Outputs from completed dependencies will be provided below when available
INSTREOF

重要： すべての instructions.md に、明示的なファイルパスを必ず記載してください。並列エージェントは曖昧なスコープをそれぞれ独立して解釈するため、パスを明示しないと、2つのWPが同じファイルを変更したり、範囲の間に抜けが生じたりする可能性があります。「認証モジュールを作成する」のような曖昧な説明は禁止です。src/auth/oauth.ts のように正確なパスを指定してください。

launch.sh

v8.44.0：各ワークパッケージは、ファイルを完全に分離するため、独自のgit worktreeで実行されます。 これにより、複数のエージェントが同時にファイルを変更する際の書き込み競合を防ぎます。

cat > ".octo/parallel/WP-N/launch.sh" << 'LAUNCHEOF'
#!/bin/bash
SCRIPT_DIR="$(cd "$(dirname "${0}")" && pwd)"
PROJECT_ROOT="<absolute-project-root-path>"
WP_ID="WP-N"
WP_BRANCH="<wp-branch-name>"
BASE_REF="<base-ref>"
REGISTRY="${HOME}/.claude-octopus/plugin/scripts/agent-registry.sh"

# Every exit path must leave exit-code and .done behind, or the orchestrator's
# monitor loop waits for a marker that never arrives and only the wave timeout
# ends the run.
fail() {
    echo "${1}" >&2
    if [[ -x "$REGISTRY" ]]; then
        "$REGISTRY" update "$WP_ID" --status failed --error "${1}" 2>/dev/null || true
    fi
    echo "${2:-1}" > "$SCRIPT_DIR/exit-code"
    touch "$SCRIPT_DIR/.done"
    exit "${2:-1}"
}

# A retry must not inherit the previous run's completion status.
rm -f "$SCRIPT_DIR/.done" "$SCRIPT_DIR/exit-code" || fail "ERROR: cannot clear completion markers"
# Hook environments can otherwise redirect Git away from PROJECT_ROOT.
while IFS= read -r git_var; do unset "$git_var"; done < <(git rev-parse --local-env-vars)

# v8.44.0: Create isolated worktree for this work package.
# Each package checks out its OWN branch. git refuses to check one branch out
# in two worktrees, so reusing the session branch fails every package after the
# first, and a shared branch would also pile unrelated packages onto one ref.
cd "$PROJECT_ROOT" || fail "ERROR: cannot enter $PROJECT_ROOT"
PROJECT_ROOT="$(pwd -P)"
WORKTREE_DIR="${PROJECT_ROOT}/../.octo-worktree-${PROJECT_ROOT##*/}-${WP_ID}"
COMMON_DIR="$(git rev-parse --git-common-dir)" || fail "ERROR: not a Git repository"
COMMON_DIR="$(cd "$COMMON_DIR" && pwd -P)" || fail "ERROR: cannot resolve repository identity"
git worktree prune 2>/dev/null || true
if [[ -d "$WORKTREE_DIR" ]]; then
    # Retry: reuse the existing worktree instead of discarding the work in it.
    cd "$WORKTREE_DIR" || fail "ERROR: cannot enter $WORKTREE_DIR"
else
    git worktree add -b "$WP_BRANCH" "$WORKTREE_DIR" "$BASE_REF" \
        > "$SCRIPT_DIR/worktree.log" 2>&1 ||
        git worktree add "$WORKTREE_DIR" "$WP_BRANCH" \
            >> "$SCRIPT_DIR/worktree.log" 2>&1 ||
        fail "ERROR: failed to create worktree at $WORKTREE_DIR (see worktree.log)"
fi

# Reject stale directories from another project, branch, or non-worktree path.
cd "$WORKTREE_DIR" || fail "ERROR: cannot enter $WORKTREE_DIR"
WORKTREE_DIR="$(pwd -P)"
WORKTREE_TOP="$(git rev-parse --show-toplevel)" || fail "ERROR: not a Git worktree"
WORKTREE_TOP="$(cd "$WORKTREE_TOP" && pwd -P)" || fail "ERROR: cannot resolve worktree root"
WORKTREE_COMMON_DIR="$(git rev-parse --git-common-dir)" || fail "ERROR: cannot identify worktree repository"
WORKTREE_COMMON_DIR="$(cd "$WORKTREE_COMMON_DIR" && pwd -P)" || fail "ERROR: cannot resolve worktree repository"
WORKTREE_BRANCH="$(git symbolic-ref --quiet --short HEAD)" || fail "ERROR: worktree has detached HEAD"
[[ "$WORKTREE_TOP" == "$WORKTREE_DIR" && "$WORKTREE_COMMON_DIR" == "$COMMON_DIR" && \
   "$WORKTREE_BRANCH" == "$WP_BRANCH" ]] || fail "ERROR: worktree repository or branch does not match this package"

# Register agent in registry
if [[ -x "$REGISTRY" ]]; then
    "$REGISTRY" register "$WP_ID" "$WP_BRANCH" "$WORKTREE_DIR" 2>/dev/null || true
fi

cd "$WORKTREE_DIR" || fail "ERROR: cannot enter $WORKTREE_DIR"
unset CLAUDECODE
# v8.32.0: Credential isolation — work packages don't need provider keys
unset OPENAI_API_KEY AGY_AUTH_TOKEN ANTIGRAVITY_API_KEY OPENROUTER_API_KEY PERPLEXITY_API_KEY
# No `set -e` around this call: a non-zero claude -p must still record its exit
# code and .done rather than abort the script before either is written.
claude -p < "$SCRIPT_DIR/instructions.md" > "$SCRIPT_DIR/output.md" 2>"$SCRIPT_DIR/agent.log"
EXIT_CODE=$?
echo $EXIT_CODE > "$SCRIPT_DIR/exit-code"

# Update agent registry with completion status
if [[ -x "$REGISTRY" ]]; then
    if [[ "$EXIT_CODE" -eq 0 ]]; then
        "$REGISTRY" update "$WP_ID" --status done 2>/dev/null || true
    else
        "$REGISTRY" update "$WP_ID" --status failed --error "Exit code $EXIT_CODE" 2>/dev/null || true
    fi
fi

# Discard the worktree only once its work is committed to the package's branch.
# A force-remove over uncommitted edits destroys everything the package built;
# the commits themselves survive removal, because they are already in the
# shared object store on WP_BRANCH.
UNCOMMITTED="$(git -C "$WORKTREE_DIR" status --porcelain 2>/dev/null)" ||
    fail "ERROR: cannot inspect worktree status; retained $WORKTREE_DIR"
COMMITS="$(git -C "$WORKTREE_DIR" rev-list --count "$BASE_REF..HEAD" 2>/dev/null)" ||
    fail "ERROR: cannot inspect worktree commits; retained $WORKTREE_DIR"
echo "$COMMITS" > "$SCRIPT_DIR/commit-count"
cd "$PROJECT_ROOT"
if [[ -z "$UNCOMMITTED" && "$COMMITS" -gt 0 ]]; then
    git worktree remove "$WORKTREE_DIR" 2>/dev/null ||
        fail "ERROR: cannot remove worktree; retained $WORKTREE_DIR"
elif [[ -n "$UNCOMMITTED" ]]; then
    echo "KEPT $WORKTREE_DIR: uncommitted work present on $WP_BRANCH" \
        >> "$SCRIPT_DIR/agent.log"
else
    echo "KEPT $WORKTREE_DIR: no commits beyond $BASE_REF on $WP_BRANCH" \
        >> "$SCRIPT_DIR/agent.log"
fi
touch "$SCRIPT_DIR/.done"
LAUNCHEOF

chmod +x ".octo/parallel/WP-N/launch.sh"

3つすべてのプレースホルダーを必ず置き換えてください： <absolute-project-root-path> は実際のプロジェクトルート（pwd を使用）、<wp-branch-name> はこのパッケージ固有のWBS内のブランチ、<base-ref> はすべてのパッケージがブランチを作成する参照先（通常は origin/<trunk>。これにより、パッケージはセッションブランチに積み重ならず、独立したブランチになります）。

Worktreeのフォールバック： git worktreeが利用できない場合（shallow clone、detached HEADなど）、起動スクリプトは安全側に停止し、.done とともにゼロ以外の終了コードを記録します。これにより、Waveはハングせずに失敗を報告します。コミットされていない作業が残っているworktreeは削除せず、その理由を agent.log に追記します。

検証ゲート：instructions_written — すべての指示ファイルが存在することを確認します。

# Count WPs from wbs.json
wp_count=$(python3 -c "import json; print(len(json.load(open('.octo/parallel/wbs.json'))['work_packages']))")

# Verify each WP has instructions.md and launch.sh
missing=0
for i in $(seq 1 "$wp_count"); do
  if [[ ! -f ".octo/parallel/WP-$i/instructions.md" ]]; then
    echo "MISSING: .octo/parallel/WP-$i/instructions.md"
    missing=$((missing + 1))
  fi
  if [[ ! -f ".octo/parallel/WP-$i/launch.sh" ]]; then
    echo "MISSING: .octo/parallel/WP-$i/launch.sh"
    missing=$((missing + 1))
  fi
done

if [[ "$missing" -eq 0 ]]; then
  echo "Instruction files validation: PASSED ($wp_count work packages)"
else
  echo "Instruction files validation: FAILED ($missing files missing)"
fi

すべての指示ファイルの検証が完了するまで、STEP 6に進んではいけません。

STEP 6: 起動と監視 — Waveベースの実行（必須）

依存関係のWaveに従ってワークパッケージを起動します。Wave 1を最初に実行し、出力を注入したうえでWave 1が完了してからWave 2を開始します。以降も同様に進めます。

すべてのWPがWave 1に属している場合（依存関係がない場合）、従来の起動と同じ動作になります（後方互換性）。

Waveベースの起動シーケンス：

PROJECT_ROOT="$(pwd)"
WBS_FILE=".octo/parallel/wbs.json"
MAX_WAVE=$(python3 -c "import json; wbs=json.load(open('$WBS_FILE')); print(max(wp.get('wave',1) for wp in wbs['work_packages']))")
TIMEOUT=600  # 10 minutes per wave

echo "Executing $MAX_WAVE wave(s)..."

for WAVE in $(seq 1 "$MAX_WAVE"); do
  echo ""
  echo "=== WAVE $WAVE ==="
  echo ""

  # Get WPs for this wave
  WAVE_WPS=$(python3 -c "
import json
wbs=json.load(open('$WBS_FILE'))
wps=[wp['id'] for wp in wbs['work_packages'] if wp.get('wave',1)==$WAVE]
print(' '.join(wps))
  ")

  # Inject outputs from completed dependency WPs into instructions
  for WP_ID in $WAVE_WPS; do
    WP_NUM="${WP_ID#WP-}"
    WP_DIR=".octo/parallel/$WP_ID"

    # Get dependencies for this WP
    DEPS=$(python3 -c "
import json
wbs=json.load(open('$WBS_FILE'))
wp=[w for w in wbs['work_packages'] if w['id']=='$WP_ID'][0]
print(' '.join(wp.get('dependencies',[])))
    ")

    if [[ -n "$DEPS" ]]; then
      echo "Injecting dependency outputs into $WP_ID..."
      echo "" >> "$WP_DIR/instructions.md"
      echo "## Outputs from Dependencies" >> "$WP_DIR/instructions.md"
      for DEP in $DEPS; do
        DEP_DIR=".octo/parallel/$DEP"
        if [[ -f "$DEP_DIR/output.md" ]]; then
          echo "" >> "$WP_DIR/instructions.md"
          echo "### From $DEP:" >> "$WP_DIR/instructions.md"
          head -c 4000 "$DEP_DIR/output.md" >> "$WP_DIR/instructions.md"
        fi
      done
    fi
  done

  # Launch WPs in this wave with 12s stagger
  WAVE_COUNT=0
  for WP_ID in $WAVE_WPS; do
    WP_NUM="${WP_ID#WP-}"
    echo "Launching $WP_ID at $(date '+%H:%M:%S')..."
    # Clear before background launch, so the monitor cannot see a stale result.
    rm -f ".octo/parallel/$WP_ID/.done" ".octo/parallel/$WP_ID/exit-code" || exit 1
    bash ".octo/parallel/$WP_ID/launch.sh" &
    WP_PID=$!
    echo "$WP_PID" > ".octo/parallel/$WP_ID/pid"
    echo "  $WP_ID launched (PID: $WP_PID)"
    WAVE_COUNT=$((WAVE_COUNT + 1))

    # 12-second stagger within wave (skip after last)
    REMAINING=$(echo "$WAVE_WPS" | wc -w | tr -d ' ')
    if [[ "$WAVE_COUNT" -lt "$REMAINING" ]]; then
      echo "  Waiting 12 seconds before next launch..."
      sleep 12
    fi
  done

  # Monitor this wave
  START_TIME=$(date +%s)
  COMPLETED=0
  WAVE_TOTAL=$(echo "$WAVE_WPS" | wc -w | tr -d ' ')

  echo "Monitoring Wave $WAVE ($WAVE_TOTAL WPs, timeout: ${TIMEOUT}s)..."

  while [[ "$COMPLETED" -lt "$WAVE_TOTAL" ]]; do
    COMPLETED=0
    for WP_ID in $WAVE_WPS; do
      if [[ -f ".octo/parallel/$WP_ID/.done" ]]; then
        COMPLETED=$((COMPLETED + 1))
      fi
    done

    ELAPSED=$(( $(date +%s) - START_TIME ))
    echo "Wave $WAVE progress: $COMPLETED/$WAVE_TOTAL complete (${ELAPSED}s elapsed)"

    if [[ "$ELAPSED" -gt "$TIMEOUT" ]]; then
      echo "TIMEOUT: Wave $WAVE did not complete within ${TIMEOUT}s"
      break
    fi

    if [[ "$COMPLETED" -lt "$WAVE_TOTAL" ]]; then
      # v8.45.0: Fire reaction engine between poll cycles
      REACTIONS="${HOME}/.claude-octopus/plugin/scripts/reactions.sh"
      if [[ -x "$REACTIONS" ]]; then
        "$REACTIONS" check-all 2>/dev/null || true
      fi
      sleep 15
    fi
  done

  echo "Wave $WAVE complete: $COMPLETED/$WAVE_TOTAL finished."
done

echo ""
echo "All waves executed."

検証ゲート：processes_launched — すべてのWPについてPIDファイルが存在することを確認します。

重要： 上記の起動コマンドと監視コマンドは、ネイティブのシェルコマンドツール経由で実行してください。コマンドをまとめるか、監視を別個のポーリング手順として実行する必要がある場合があります。監視ループは、各Waveが完了するかタイムアウトするまでブロックします。

すべてのWaveが完了するまで、STEP 7に進んではいけません。

STEP 7: 集約して提示（必須）

すべての作業パッケージが完了した後（またはタイムアウト後）、結果を集約します。

すべての出力と終了コードを確認します：

echo "=== WORK PACKAGE RESULTS ==="
echo ""

FAILED=0
SUCCEEDED=0

for i in $(seq 1 "$WP_COUNT"); do
  WP_DIR=".octo/parallel/WP-$i"

  if [[ -f "$WP_DIR/exit-code" ]]; then
    EXIT_CODE=$(cat "$WP_DIR/exit-code")
  else
    EXIT_CODE="N/A (not completed)"
  fi

  if [[ "$EXIT_CODE" == "0" ]]; then
    STATUS="SUCCESS"
    SUCCEEDED=$((SUCCEEDED + 1))
  else
    STATUS="FAILED (exit code: $EXIT_CODE)"
    FAILED=$((FAILED + 1))
  fi

  echo "WP-$i: $STATUS"

  if [[ -f "$WP_DIR/output.md" ]]; then
    OUTPUT_SIZE=$(wc -c < "$WP_DIR/output.md" | tr -d ' ')
    echo "  Output: $OUTPUT_SIZE bytes"
  else
    echo "  Output: MISSING"
  fi

  echo ""
done

echo "=== SUMMARY ==="
echo "Total: $WP_COUNT | Succeeded: $SUCCEEDED | Failed: $FAILED"

次に、Read ツールを使用して各 output.md を読み込み、成功を宣言する前に品質を確認します：

1. 完了した WP の output.md ファイルをすべて読み込みます
2. 失敗した WP（終了コードが 0 以外）を、その agent.log の内容とともに報告します
3. 成功した各 WP の品質を抜き取り確認します — 出力内をスキャンして、以下を確認します：
   • 抑制マーカー（@ts-ignore、type: ignore、noqa、eslint-disable）
   • プレースホルダーコード（TODO、FIXME、not implemented、スタブ関数）
   • テストのスキップマーカー（skip、xit、xdescribe、pytest.mark.skip）
   • 見つかった場合は 品質警告 として報告します（自動的に失敗とはせず、ユーザーに提示します）
4. すべての WP で作成または変更されたファイルを一覧表示します
5. 手動での対応が必要な統合ポイント（共有インターフェース、重複するファイルなど）を記載します

次の形式で結果を提示します：

=== TEAM OF TEAMS - RESULTS ===

Compound Task: <original task>
Work Packages: N total | N succeeded | N failed

WP-1: <name> - [SUCCESS/FAILED]
  <summary of what was accomplished>

WP-2: <name> - [SUCCESS/FAILED]
  <summary of what was accomplished>

...

Integration Notes:
- <any cross-WP concerns>
- <files that may need reconciliation>

Failed Work Packages (if any):
- WP-X: <error summary from agent.log>

Coordination Files: .octo/parallel/

検証ゲート：all_work_packages_complete — すべての WP に .done ファイルがあり、終了コードの確認が完了しています。

エージェントレジストリの概要（v8.44.0）：

# Show agent registry status for this parallel run
REGISTRY="${HOME}/.claude-octopus/plugin/scripts/agent-registry.sh"
if [[ -x "$REGISTRY" ]]; then
  echo ""
  echo "=== AGENT REGISTRY ==="
  "$REGISTRY" list
fi

調整プロトコルのディレクトリ構造

このスキルによって作成および管理されます：

.octo/parallel/
  wbs.json              # Work Breakdown Structure
  WP-1/
    instructions.md     # Task instructions for this WP
    launch.sh           # Launch script (runs claude -p)
    output.md           # Agent output (created by claude -p)
    agent.log           # Agent stderr log (created by launch.sh)
    exit-code           # Process exit code (created by launch.sh)
    pid                 # Process ID (created by orchestrator)
    .done               # Completion marker (created by launch.sh)
  WP-2/
    ...
  WP-N/
    ...

禁止事項（必須 — 違反不可）

• ホストのサブエージェントツールのサブエージェントを代替手段として使用してはなりません。Task サブエージェントはプラグインにアクセスできない隔離されたサンドボックスで実行されるため、Octopus の品質ゲート、ペルソナ、プロバイダーオーケストレーションを利用できません
• WBS 分解（Step 4）を省略してはなりません。分解しないと、エージェントは複合タスク全体を受け取り、互いに重複する調整されていない出力を生成します
• 指示ファイルなしで起動してはなりません（Step 5 を Step 6 より前に実施する必要があります）
• 起動間の 12 秒の間隔を省略してはなりません。プロセスを同時に起動すると CPU／メモリの競合が発生し、すべてのエージェントのパフォーマンスが低下します
• 終了コードを確認せずに成功を宣言してはなりません
• 現在のステップを完了せずに次のステップへ進んではなりません
• 曖昧な指示を書いてはなりません。明示的なファイルパスの指定は必須です
• 作業パッケージを 10 個を超えて起動してはなりません。10 個を超えると、リソースの競合とマージの複雑さが並列化の利点を上回ります
• 監視ループを省略してはなりません。監視しないと、失敗またはハングしたエージェントを検出できず、オーケストレーターが誤って成功を報告します
• 依存関係のあるウェーブが完了する前に、後続のウェーブを起動してはなりません。後続のウェーブは先行するウェーブの出力を使用するため、早すぎる起動は、エージェントが不足したコンテキストで作業する原因になります
• 依存関係がある場合に、依存関係の検証を省略してはなりません

エラー処理

作業パッケージが失敗した場合（終了コードが 0 以外）：

1. エラーの詳細を確認するため、その agent.log を読み込みます
2. エラーをユーザーに提示します
3. 失敗した WP のみを個別に再試行することを提案します
4. 成功した WP を再実行してはなりません

監視がタイムアウトした場合：

1. 完了した WP と未完了の WP を報告します
2. タイムアウトした WP がまだ実行中かどうかを確認します（PID を確認）
3. さらに待つか、残りのプロセスを終了するかを提案します

claude コマンドを利用できない場合：

1. command -v claude で確認します
2. ユーザーに報告して停止します。claude CLI がなければ続行できません

使用例

例：認証システム

User: /octo:parallel build a full authentication system with OAuth, RBAC, and audit logging

Decomposition:
  WP-1: OAuth Integration
    - OAuth provider setup (Google, GitHub)
    - Token management and refresh
    - Callback handlers
    Files: src/auth/oauth.ts, src/auth/providers/

  WP-2: RBAC Implementation
    - Role and permission models
    - Authorization middleware
    - Role assignment API
    Files: src/auth/rbac.ts, src/middleware/authorize.ts

  WP-3: Audit Logging
    - Audit event model
    - Logging middleware
    - Audit query API
    Files: src/audit/logger.ts, src/audit/events.ts

Each WP runs as independent claude -p with full Octopus plugin.
Results aggregated after all complete.

例：移行（バッチ形式）

User: /octo:batch migrate all components in src/components/ from class components to functional React with hooks

Decomposition:
  WP-1: Form components (src/components/forms/)
  WP-2: Layout components (src/components/layout/)
  WP-3: Data display components (src/components/tables/, src/components/charts/)
  WP-4: Navigation components (src/components/nav/)

Each WP migrates its directory, runs existing tests, fixes any failures.
No overlapping files — safe to merge all results.

例：複数の問題を並行して修正

User: /octo:parallel fix issue #12, issue #15, and issue #22

Decomposition (after reading each issue):
  WP-1: Fix #12 — login redirect loop (src/auth/login.ts)
  WP-2: Fix #15 — pagination off-by-one (src/api/pagination.ts)
  WP-3: Fix #22 — dark mode toggle not persisting (src/hooks/useTheme.ts)

No file overlaps detected — all three run in Wave 1.
Each WP runs related tests before marking complete.

例：独立したツールを並行して構築

User: /octo:parallel build a confluence scraper in go, a markdown-to-obsidian converter, a qdrant vectorizer, and a CLI search tool

Decomposition:
  WP-1: Confluence scraper (cmd/scraper/) — Wave 1
  WP-2: Markdown-to-Obsidian converter (cmd/converter/) — Wave 2 (depends on WP-1 output format)
  WP-3: Qdrant vectorizer (cmd/vectorizer/) — Wave 2 (depends on WP-2 output format)
  WP-4: CLI search tool (cmd/search/) — Wave 2 (depends on WP-3 schema)

Wave 1 completes first, output format injected into Wave 2 instructions.
Each WP builds, runs go test, and verifies the binary works.