Ops Orchestrate

Runtime Context

Before orchestrating, load:

1. Preferences: cat ${CLAUDE_PLUGIN_DATA_DIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}/preferences.json — read owner, timezone, yolo_enabled, registry path
2. Daemon health: cat ${CLAUDE_PLUGIN_DATA_DIR}/daemon-health.json — ensure all services healthy before dispatching
3. Secrets: Resolve via env → Doppler → password manager: GITHUB_TOKEN, SENTRY_AUTH_TOKEN, LINEAR_API_KEY, ANTHROPIC_API_KEY
4. Ops memories: Check ${CLAUDE_PLUGIN_DATA_DIR}/memories/topics_active.md for priority context

OPS ► ORCHESTRATE — Autonomous Work Engine

Load ops-rules before acting. Public repo (no personal data). Outbound: one draft → one approval → one send. If AskUserQuestion / Workflow are missing, follow Rule 10 in ops-rules (Hermes: numbered options / two-turn Telegram card; delegate_task).

Context Detection

Detect where this skill was invoked:

# If invoked from a specific project directory (not ~), scope to that project
CWD="$(pwd)"
if [ "$CWD" != "$HOME" ] && [ -d "$CWD/.git" ]; then
  echo "SCOPED:$CWD"
else
  echo "GLOBAL"
fi

• SCOPED mode (invoked inside a project dir): Limit work to that project only. Include all todos/tasks from the current conversation context. Skip the global registry scan.
• GLOBAL mode (invoked from ~ or with no git repo): Scan all registered projects.

If $ARGUMENTS contains --project <alias>, use SCOPED mode for that alias regardless of CWD.

Orchestration Mode — How to Choose

Decision matrix (shown to user if no flag passed)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 ORCHESTRATION MODE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 --subagents (default)     Fire-and-forget. Cheapest. Best for:
                           - Independent single-repo fixes
                           - Tasks that don't need mid-flight changes
                           - Cost: ~1.5-2x base token usage

 --teams                   Agent Teams with mid-flight steering. Best for:
                           - Cross-repo contract changes (API + consumer)
                           - Security/auth work touching 2+ repos
                           - When you need to redirect agents based on findings
                           - Cost: ~3-7x base token usage

 --hybrid (recommended)    Auto-selects per task. Teams for cross-repo
                           and security work, subagents for everything else.
                           Best balance of speed, cost, and coordination.
                           Cost: ~2-4x base token usage

 --dry-run                 Audit + plan only. Shows what would be dispatched
                           without executing. Good for reviewing before committing.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

If no flag is passed, use AskUserQuestion:

  [Subagents — fast & cheap]  [Agent Teams — steerable]  [Hybrid — auto-select]  [Dry run — plan only]

Auto-detection heuristic (for --hybrid mode)

Tag each task during Phase 2:

Feature flag requirement for Agent Teams

Agent Teams requires CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. Check before using:

[ "${CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS:-0}" = "1" ] && echo "teams_available" || echo "teams_unavailable"

If --teams or --hybrid is requested but the flag is off, warn and fall back to --subagents.

Phase 1 — Audit (parallel, read-only)

1a. Discover projects

SCOPED mode: Use only the current directory. Read .planning/STATE.md if it exists.

GLOBAL mode: Scan the project registry:

# registry.json is written by scripts/ops-gsd-registry-sync.sh into the data dir.
# Its schema is name/path/remote_url/status/phase/branch — NOT the alias/paths/repos/gsd
# shape of registry.example.json. lib/registry-path.sh resolves the real file.
PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT}" . "${CLAUDE_PLUGIN_ROOT}/lib/registry-path.sh"
jq -r '.projects[] | "\(.name)|\(.path)|\(.remote_url // "none")|\(.has_roadmap // false)|\(.status // "")|\(.phase // "")|\(.branch // "")"' "$REGISTRY" 2>/dev/null

For each project path, verify it exists on disk. Skip missing paths. Skip entries under archives/, scratch/ or .worktrees/ unless --project names them; the sync dedupes on remote_url and keeps the extra copies in aliases.

1b. Parallel audit dispatch

Group projects into batches of ~8. Dispatch one audit subagent per batch (always subagents — audit is read-only, no steering needed):

Each audit agent checks:

• git status --porcelain — uncommitted changes
• git log origin/dev..HEAD --oneline — unpushed commits
• gh pr list --state open --json number,title,statusCheckRollup,reviewDecision,mergeable,isDraft — open PRs + CI
• gh run list --limit 5 --json status,conclusion,name,headBranch,createdAt — recent CI runs
• .planning/STATE.md — current GSD phase + progress
• .planning/ROADMAP.md — upcoming phases
• Unresolved review comments on open PRs

1c. Filter already-fixed failures

Before creating tasks for CI failures:

# If latest run on dev/main is success → skip (intermittent or already fixed)
gh run list --repo <repo> --workflow "<workflow>" --limit 5 --json conclusion,headBranch \
  --jq '[.[] | select(.headBranch == "dev" or .headBranch == "main")] | .[0].conclusion'

• Latest = success → skip
• Latest = failure AND 2+ prior also failure → create task (persistent)
• Latest = failure but prior = success → create P2 task (new regression)

1d. External issue sources (parallel with 1b)

Run these in parallel with the audit agents:

• Sentry: mcp__plugin_sentry_sentry__search_issues or sentry-cli issues list — P0/P1 unresolved errors
• Linear: mcp__linear__list_issues for current sprint — in-progress and unstarted
• GitHub Issues: gh issue list --state open per repo
• Conversation context: Scan current conversation for todos, requests, and incomplete work the user mentioned

1e. Cross-reference against existing tasks

TaskList — check current task board. Flag:

• Tasks already done → mark completed
• Tasks stale (root cause changed) → update description
• New work not yet in TaskList → queue for Phase 2

Phase 2 — Structure (TaskCreate + dependency wiring)

2a. Decompose into atomic tasks

Each task should be:

• One PR max (~2-4 hour scope)
• One repo only (isolation for parallel execution)
• Clear acceptance criteria (what "done" looks like)

2b. TaskCreate with rich metadata

TaskCreate({
  title: "fix: resolve auth middleware race condition",
  description: "File: src/middleware/auth.ts:42\nRepo: my-api\nBranch: fix/auth-race\nAcceptance: unit test passes, no Sentry errors for 5min post-deploy",
  metadata: {
    project: "my-api",
    repo: "your-org/my-api",
    priority: "P1-revenue",
    mode: "subagent",           // or "team" — used by hybrid mode
    wave: 0,                     // parallelization wave
    paths: ["src/middleware/auth.ts", "tests/auth/"],
    quality_gate: "npm run type-check && npm run lint && npm run test:unit"
  }
})

2c. Wire dependencies (CRITICAL for max parallelism)

Rules for dependency wiring:

1. If tasks are independent → NO dependency. They run in the SAME wave.
2. Only add addBlockedBy when the output of task A is genuinely required as input for task B.
3. Never serialize tasks that can run in parallel. Three independent bug fixes in three repos = wave 0, all three, simultaneously.

Common dependency patterns:

• Deploy task → blocked by its implementation task
• Phase N task → blocked by Phase N-1 completion
• Consumer update → blocked by API schema change (cross-repo)
• PR merge → blocked by CI passing
• Main merge → blocked by dev merge

Anti-patterns to AVOID:

• ❌ Serializing independent single-repo fixes (they should be wave 0 parallel)
• ❌ Making task B depend on task A just because A was discovered first
• ❌ Waiting for all wave 0 to complete before starting ANY wave 1 (start wave 1 tasks as soon as their specific blockers clear)

2d. Assign waves

Wave 0: All tasks with ZERO dependencies → dispatch ALL simultaneously
Wave 1: Tasks blocked only by wave 0 items → dispatch as each blocker clears
Wave N: Cascade — but NEVER wait for the full wave to clear.
        Start each task the MOMENT its specific blockers resolve.

2e. Tag orchestration mode (hybrid only)

Apply the decision matrix from above to tag each task as subagent or team.

Phase 3 — Dispatch (maximum parallelism)

Subagent dispatch

Rules:

• Max concurrent: 5 agents (avoid overload)
• One repo per agent (no concurrent edits to same path)
• Each agent gets a worktree via isolation: "worktree"
• Use model: "sonnet" on every Agent() call (saves quota)
• Use run_in_background: true — never block waiting
• Mark task in_progress via TaskUpdate before dispatching

Agent({
  description: "Fix auth race condition in my-api",
  model: "sonnet",
  isolation: "worktree",
  run_in_background: true,
  prompt: "<full task brief with repo path, file paths, branch strategy, acceptance criteria, quality gate>"
})

Agent Teams dispatch

Only when mode is --teams or task is tagged team in hybrid:

TeamCreate("wave-0-cross-repo")

Agent(team_name="wave-0-cross-repo", name="api-worker", model="sonnet", isolation="worktree",
  prompt="<task brief with FILE OWNERSHIP boundaries>")

Agent(team_name="wave-0-cross-repo", name="mobile-worker", model="sonnet", isolation="worktree",
  prompt="<task brief with FILE OWNERSHIP boundaries>")

File ownership (CRITICAL — prevents overwrites): Each teammate prompt MUST include:

Your files: src/api/auth.ts, src/middleware/*.ts, tests/auth/
Do NOT edit: src/api/users.ts (owned by api-worker), src/frontend/ (owned by mobile-worker)

Mid-flight steering (the killer feature):

SendMessage(to="api-worker", content="Schema changed — DTO is now UserResponseV2. Update imports.")
SendMessage(to="mobile-worker", content="API endpoint ready. New: POST /v2/users. Proceed with consumer.")

Cross-repo coordination pattern:

1. Spawn api-worker and consumer-worker on same team
2. Wire dependency: consumer blocked by api
3. When api-worker completes schema → SendMessage to consumer with the new types/endpoint
4. Consumer proceeds with full context — no re-dispatch needed