/handoff

name: handoff
description: >-
  Phase 3 of the prd-taskmaster pipeline: smart mode selection and user
  handoff. Detects installed capabilities (superpowers, ralph-loop,
  task-master-ai, playwright, research providers), recommends ONE execution
  mode (A/B/C) with reasoned justification, appends the task-execution
  workflow to CLAUDE.md, surfaces a structured AskUserQuestion multi-option
  picker for user agency, and dispatches the chosen mode. Mode D (Atlas Fleet)
  is selectable only when detect_capabilities returns tier=premium (licensed
  atlas-launcher detected); otherwise it is a locked Atlas Pro teaser.
  Plan Mode is NOT used (spec section 13.5): AskUserQuestion is the sole
  user-agency mechanism. Declares HANDOFF complete so EXECUTE can follow.
user-invocable: false
allowed-tools:
  - Read
  - Bash
  - Skill
  - AskUserQuestion
  - ToolSearch
  - mcp__atlas-engine
  - mcp__plugin_prd_go
  - mcp__plugin_prd-taskmaster_go
  - mcp__plugin_atlas-go_go

Phase 3: Handoff

Declarative phase skill. Invoked by the prd-taskmaster orchestrator when `current_phase` is `HANDOFF`. Never called directly by a user.

The one rule: **detect what the user has, recommend ONE mode, give the user a structured choice, dispatch the chosen mode. Mode D executes only on tier=premium; otherwise it is a locked teaser.**

Task provider routing comes first

For `atlas-kanban`, follow phases/HANDOFF.md's default branch before the entry gate below: read the canonical references with `workflow-status`, report `doctor`, then hand IDs/acceptance to the parent for its external-session reservation protocol. Do not use Taskmaster lifecycle commands, append a file-mode CLAUDE.md workflow, invoke execute-task/fleet, or forge legacy pipeline gate evidence for canonical cards. All remaining modes, steps and file-mode gates apply only to taskmaster-file.

Entry gate

1. Call `mcp__plugin_prd_go__check_gate(phase="HANDOFF", evidence={})` for diagnostics.

`check_gate` is an EXIT gate: it requires `user_mode_choice` and `plan_file_exists` — both produced by HANDOFF itself, i.e. evidence to *advance*, not to *enter*. On first entry neither exists yet, so a `gate_passed: false` here is EXPECTED — the state machine's legal transitions already guarantee only legal entry.

• **First entry** (no evidence yet): note the result and continue with the Procedure.
• **Re-entry**: if the gate reports violations, report them and stop — it protects

against re-running a completed phase or skipping ahead from GENERATE. 2. Read the GENERATE outputs — `.taskmaster/docs/prd.md`, `.taskmaster/tasks/tasks.json`, `.taskmaster/reports/task-complexity-report.json`. If any are missing, report and stop. The gate should have caught this, but belt-and-braces.

Handoff checklist

Copy into your response before running the procedure:

HANDOFF CHECKLIST:
- [ ] Capabilities detected (tier + per-capability flags)
- [ ] Recommended mode: ___ (reason: ___)
- [ ] Summary displayed (spec location, task count, capabilities)
- [ ] CLAUDE.md task workflow appended (idempotent)
- [ ] AskUserQuestion mode picker surfaced (or prose fallback if hook-blocked)
- [ ] User choice dispatched (Mode A / B / C, or D when tier=premium)
- [ ] Debrief scaffold emitted (optional, silently tolerated)
- [ ] Handoff complete

Step 1: Detect capabilities

**MCP (preferred)**: `mcp__plugin_prd_go__detect_capabilities()`

**CLI fallback**: `python3 script.py detect-capabilities`

Returns a `tier` field (`"free"` or `"premium"`) plus per-capability flags. Key signals:

| Capability | What It Enables | |------------|----------------| | superpowers plugin | Modes A, C (brainstorm, plans, subagents) | | task-master-ai (CLI or MCP) | Mode B (native auto-execute loop) | | ralph-loop plugin | Mode C (iterative execution loop) | | atlas-launcher MCP (licensed) | Mode D — Atlas Fleet (tier=premium) | | atlas-loop / atlas-cdd skills | legacy Mode-D seeds — superseded by atlas-launcher detection | | Research model (task-master or MCP) | Deep research per task | | Playwright MCP | Tier S browser verification |

**Mode D (Atlas Fleet) unlocks on `tier: "premium"` only** — i.e. a licensed `atlas-launcher` MCP registration detected by `detect_atlas_launcher()`. Local `atlas-loop`/`atlas-cdd` skills do NOT unlock it. See Step 2 and the Mode D section below.

Step 2: Recommend ONE mode

Decision logic (first match wins):

• `superpowers` + `ralph-loop` present → **Mode C** (recommended free)
• `superpowers` only → **Mode A** (plan-only, manual drive)
• `task-master-ai` only → **Mode B** (native auto-execute)
• Fallback → **Mode A**

External-tool modes (E–J: Cursor, RooCode, Codex, Gemini, CodeRabbit, Aider) are offered as alternatives via the `alternative_modes` field, not primary recommendations. **Mode D is recommended iff `tier == "premium"` AND the task graph parallelizes (>= 2 independent dependency chains — check `fleet-waves` output: any wave with >= 2 chunks). Premium + serial graph: recommend the best free mode and say why ("your tasks form a single dependency chain — Verified Loop is the right tool here"); Fleet stays selectable but not default. Free tier: Mode D is a locked Atlas Pro teaser, never selectable, regardless of which local plugins are installed.**

Mode A: Plan Only (Manual)

Recommended: Plan Only
  superpowers:writing-plans creates your implementation plan
  Plan references TaskMaster task IDs from tasks.json
  You drive execution manually

Mode B: TaskMaster Auto-Execute (Mode B — TaskMaster backend only)

Recommended: TaskMaster Auto-Execute
  MCP:  mcp__task-master-ai__next_task -> implement -> set_task_status(id, "done") (Mode B — TaskMaster backend only)
  CLI:  task-master next -> implement -> task-master set-status --id N --status done (Mode B — TaskMaster backend only)
  Native TaskMaster execution loop (no external orchestrator required)

Mode C: Plan + Ralph Loop (Recommende