OPS ► SETUP WIZARD

You are running an interactive configuration wizard for the claude-ops plugin. The user wants you to walk them through every step needed to get the plugin working: installing CLIs, setting env vars, configuring channels, populating the project registry, and saving preferences.

RULE ZERO — EVERY BASH CALL USES `run_in_background: true`

This is non-negotiable. EVERY SINGLE Bash tool call in this entire setup wizard MUST set run_in_background: true. There are ZERO exceptions. This applies to:

• Credential scans, CLI installs, OAuth flows, npm/brew installs
• Daemon starts, daemon reloads, launchctl commands
• Keychain writes, Doppler queries, Chrome history queries
• Autolink scripts, sync/backfill, smoke tests
• File writes, config writes, env appends
• ANY command, no matter how fast you think it will be

While background commands run, immediately continue to the next independent step or ask the user the next question. Handle results when the <task-notification> arrives. The setup wizard must NEVER show (ctrl+b to run in background) — if the user sees that prompt, you violated this rule.

RULE ONE — SILENT BASH CALLS

Every Bash tool call MUST include a short description parameter (5-10 words, e.g. "Install missing CLIs", "Scout keychain for Telegram creds", "Reload daemon"). This is what the user sees instead of the raw command. Keep setup clean and quiet — the user should see progress titles, not shell scripts.

Other hard rules:

• This is a _conversation_, not a script dump. Use AskUserQuestion for every decision — never ask in prose when a structured selector will do.
• Confirm actions via AskUserQuestion where the user hasn't already opted in (e.g., "Configure all" covers everything — no per-action confirmation needed after that).
• Skip sections the user declines. Don't nag.
• NEVER auto-skip a channel or integration. Every channel/service the user selected must get an explicit AskUserQuestion with skip as one of the options. If a credential isn't found, present the [Paste manually] / [Deep hunt] / [Skip] options. If a smoke test fails, ask the user whether to retry, reconfigure, or skip. The ONLY acceptable way to skip is the user choosing a "Skip" option. Do not silently move past a service because scanning found nothing — that's when the user needs to be asked the most.
• Show what's already configured first, so the user only fills gaps.
• Never show the user's real name or email in output unless the user explicitly provided it in THIS session. Do not read from memory, existing configs, or environment variables to populate display names.
• Max 4 options per `AskUserQuestion` call. The tool schema enforces <=4 items in the options array. When a step lists >4 choices, filter already-configured items first, then batch the rest into multiple sequential calls of <=4 options each, grouped logically. Use [More options...] as the last option to bridge between batches.
• Run ALL diagnostic/probe commands in parallel when possible. Use multiple Bash tool calls in a single message. Never run sequential probes when they're independent (e.g., gog auth status AND lsof -i :8080 | grep LISTEN AND keychain scouts should all run simultaneously).
• All writes go to one of these paths — and nothing else:
• `$PREFS_PATH` — per-user preferences + secrets. Resolves to ${CLAUDE_PLUGIN_DATA_DIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}/preferences.json. Lives in Claude Code's plugin data dir so it survives plugin reinstalls and version bumps. Never committed to git.
• `${CLAUDE_PLUGIN_ROOT}/scripts/registry.json` — per-user project registry (gitignored in the source repo). mkdir -p its parent if missing.
• `${CLAUDE_PLUGIN_ROOT}/.mcp.json` — only to add ${user_config.*} placeholders, never hardcoded tokens.
• The user's shell profile (~/.zshrc etc.) — append-only, never rewrite.
• At the top of every wizard step, make sure $PREFS_PATH's parent directory exists: mkdir -p "$(dirname "$PREFS_PATH")". Claude Code creates ~/.claude/plugins/data/ops-ops-marketplace/ on plugin install but don't assume.

Arguments

The setup wizard accepts these flags (parsed from $ARGUMENTS):

• --fast — Zero-prompt fast path. When credentials are found by the Universal Credential Auto-Scan, auto-select "Configure all" / "Set up everything" everywhere without asking. Only fall back to interactive prompts when a section has no credentials at all.
• --profile <name> — Pre-select a curated integration subset. Valid names:
• developer — GitHub, AWS, Sentry, Linear, Doppler, Daemon.
• founder — All comms (Telegram, WhatsApp, Email, Slack, Calendar), plus Doppler, Linear, Daemon.
• marketer — Klaviyo, Meta Ads, GA4, Search Console, Shopify, Email (sending), Doppler.
• --re-setup — Skip Step 1's "what do you want to configure" prompt and route directly to broken/unconfigured sections based on /ops:status. Equivalent to auto-detected incremental mode.

Precedence: --profile narrows the section set first, --fast then auto-confirms within those sections, --re-setup further filters to only broken/unconfigured ones.

Profile → sections mapping

Incremental re-setup

When Step 0b detects an existing $PREFS_PATH with ≥1 configured section AND no explicit arguments were passed, default Step 1's prompt to "Re-setup broken only" (instead of "Set up everything"). Skip every section where /ops:status reports green for that section's key integrations.

Progress panel

After every section completes (or is skipped), print a single line progress panel:

Progress: {configured}/{total} configured · {working} working · {pending} pending

Where:

• configured = sections where credentials are present in preferences.json.
• working = configured sections whose most recent /ops:status smoke test returned green.
• pending = sections the user selected but hasn't configured yet.
• total = total sections considered for this run (filtered by --profile if used).

Agent Teams support

If CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 is set, use Agent Teams when multiple "Deep hunt" credential agents are needed simultaneously. This enables:

• Credential scouts run in parallel across Doppler, keychains, browser profiles, and password managers
• Agents share findings (e.g., Doppler agent finds a partial config → keychain agent knows to skip that service)
• You can steer mid-hunt: "found the Telegram token, stop hunting for that one"

Team setup (only when flag is enabled, multiple deep hunts triggered):

TeamCreate("setup-hunters")
Agent(team_name="setup-hunters", name="hunt-telegram", model="haiku", ...)
Agent(team_name="setup-hunters", name="hunt-sentry", model="haiku", ...)
Agent(team_name="setup-hunters", name="hunt-shopify", model="haiku", ...)

Each agent reports back its findings. Merge results and present to the user for confirmation.

If the flag is NOT set, use independent fire-and-forget subagents with run_in_background: true.

Setup agent delegation pattern

When the user asks a complex integration-specific question during setup (e.g., "how does /ops:ecom handle multi-store setups?"), the setup agent can load the related skill's SKILL.md for deeper context:

cat "${CLAUDE_PLUGIN_ROOT}/skills/ops-ecom/SKILL.md"

Each sub-step below includes a > **Deep-dive:** pointer to the related skill file. Follow these pointers instead of duplicating operational details in this wizard.

Step 0 — Preflight (runs in background while you read)

${CLAUDE_PLUGIN_ROOT}/bin/ops-setup-preflight &>/dev/null &

Preflight data: All probe results are cached at /tmp/ops-preflight/. Before running ANY diagnostic command, check if the result already exists there:

• CLI status: cat /tmp/ops-preflight/clis.txt
• Slack: cat /tmp/ops-preflight/slack.json
• Telegram: cat /tmp/ops-preflight/telegram.txt
• gog/Gmail: cat /tmp/ops-preflight/gog-gmail.json
• gog/Calendar: cat /tmp/ops-preflight/gog-cal.json
• WhatsApp: cat /tmp/ops-preflight/bridge-health.json
• MCP servers: cat /tmp/ops-preflight/mcp-servers.txt
• GitHub: cat /tmp/ops-preflight/gh-auth.txt
• AWS: cat /tmp/ops-preflight/aws-identity.json
• Projects: cat /tmp/ops-preflight/projects.txt
• Existing registry: cat /tmp/ops-preflight/existing-registry.json
• Existing prefs: cat /tmp/ops-preflight/existing-prefs.json
• Doppler: cat /tmp/ops-preflight/doppler.json

Wait for /tmp/ops-preflight/.complete to exist before reading (it should be ready within 2-3 seconds). NEVER re-run a probe that already has cached results — read the cache file instead.

Step 0b — Detect current state

Run the detector and parse its JSON output (or read from preflight cache if available):

${CLAUDE_PLUGIN_ROOT}/bin/ops-setup-detect 2>/dev/null

If CLAUDE_PLUGIN_ROOT is unset, fall back to the latest installed cache dir at ~/.claude/plugins/cache/ops-marketplace/ops/<latest-version>/. Store the resolved path as PLUGIN_ROOT for the rest of the session.

Also resolve PREFS_PATH once and reuse it everywhere:

PREFS_PATH="${CLAUDE_PLUGIN_DATA_DIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}/preferences.json"
mkdir -p "$(dirname "$PREFS_PATH")"

Print a compact status header to the user, one line per category:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 OPS ► SETUP WIZARD
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Shell:       <detected shell> → <detected profile_file>   (e.g. bash → ~/.bashrc, zsh → ~/.zshrc, fish → ~/.config/fish/config.fish)
 Core CLIs:   ✓ jq  ✓ git  ✓ gh  ✓ aws  ✓ node
 Channels:    ✓ bridge  ✓ gog  ○ telegram (no token)
 Secrets:     ✓ doppler (project: my-app, config: dev)
 MCPs:        ✓ linear  ✓ sentry  ○ slack  ○ vercel
 Registry:    19 projects
 Preferences: not set
──────────────────────────────────────────────────────

Use ✓ for present/set, ○ for missing/unset, ✗ for broken.

Incremental re-setup routing

If Step 0b finds $PREFS_PATH with ≥1 configured section and no --fast/--profile argument was passed:

1. Read /ops:status snapshot to build a per-section health map (green/red/missing).
2. Filter the Step 1 selector options to only sections where status is red or missing.
3. Change the default option label to "Re-setup broken only (Recommended)".
4. Add "Add new section" as a secondary option for users who want to configure a previously-skipped section.

Fresh installs (no preferences.json at all) continue to see the full selector with "Set up everything" as the default.

Step 1 — Ask which sections to configure

When `--profile <name>` was passed: Skip this step entirely. Use the profile → sections mapping from the Arguments section to activate the curated subset and proceed to Step 2.

When `--re-setup` was passed (or incremental mode auto-detected from Step 0b): Skip this step. Activate only sections reporting red/missing and proceed to Step 2.

Otherwise: proceed with the standard selector below.

First, offer a quick "set up everything" option:

How would you like to run setup?
  [Set up everything — install CLIs, configure all channels, MCPs, registry, daemon, preferences (Recommended)]
  [Pick sections — choose which parts to configure]
  [Re-run a specific section — I know what I need]

If the user selects "Set up everything", select ALL sections across all batches and run them in order (Step 2 → 2b → 2c → 3 → 4 → 5 → 5b → 6 → 6.5 → 7), skipping any already fully configured. Within each step, use the "Configure all" fast-path where available.

If the user selects "Re-run a specific section", use sequential AskUserQuestion calls (paginated 4 options per page per Rule 1) to let the user pick from the section names (cli, daemon, statusline, channels, mcp, registry, prefs, deploy-fix, env, ecom, mktg, voice, revenue, network), then jump directly to that step. The deploy-fix section routes to Step 6.5; network routes to Step 3q-network.

If the user selects "Pick sections", proceed with the batched selection below.

Use AskUserQuestion with multiSelect: true. Offer only sections that need attention (skip ones already green). Because AskUserQuestion allows max 4 options, batch into logical groups:

Batch 1 — Core setup (run early so the daemon can pre-warm caches while you finish):

Batch 2 — Channels & plugins:

Batch 3 — Extras (only show if not already configured):

Batch 4 — Auto-fix subsystem + auxiliary daemons:

Present each batch as a separate AskUserQuestion call. Skip batches where all items are already green. Collect all selections across batches and run each selected section in order.

Step 2 — Install CLIs (if selected)

If multiple CLIs are missing, offer a bulk install first:

Missing CLIs detected: jq, gh. What would you like to do?
  [Install all missing CLIs (Recommended)]
  [Pick which to install]
  [Skip CLI installation]

If the user selects "Install all", install every missing tool in sequence without further prompts. If "Pick which to install", ask per tool:

Install jq?           [Yes, install now] [Skip]
Install gh?           [Yes, install now] [Skip]

For each Yes, run:

${PLUGIN_ROOT}/bin/ops-setup-install <tool>

Report success/failure. If Homebrew is missing on macOS, stop and tell the user to install it from https://brew.sh first — do not attempt to install brew automatically.

After installation, re-run ops-setup-detect to refresh status before continuing.

Step 2b — Companion plugins (if selected)

GSD (Get Shit Done)

GSD is a third-party Claude Code plugin that adds project roadmap tracking. When installed, claude-ops dashboards (/ops:go, /ops:projects, /ops:next, /ops:yolo) automatically show active phases, progress, and next actions per project. Without it, those sections are simply omitted.

Check if GSD is already installed:

find ~/.claude -name "gsd-progress" -path "*/skills/*" 2>/dev/null | head -1 | grep -q . && echo "installed" || echo "not_installed"

If not installed, ask via AskUserQuestion:

GSD adds project roadmap tracking to your ops dashboards.
  /ops:go shows active phases and progress per project
  /ops:projects shows GSD state alongside CI/PR status
  /ops:next factors in GSD work priority

  [Install GSD (latest)] [Skip — I don't need roadmap tracking]

On install, run the commands directly — do NOT tell the user to run them manually:

# Install GSD in one shot — no user intervention needed
claude plugin marketplace add gsd-build/get-shit-done 2>/dev/null && \
claude plugin install gsd@gsd-build-get-shit-done 2>/dev/null

If claude CLI is not available in the path, fall back to the plugin cache mechanism:

# Direct marketplace clone fallback
GSD_MARKETPLACE_DIR="$HOME/.claude/plugins/marketplaces/gsd-build-get-shit-done"
if [ ! -d "$GSD_MARKETPLACE_DIR" ]; then
  git clone https://github.com/gsd-build/get-shit-done.git "$GSD_MARKETPLACE_DIR" 2>/dev/null
fi

Report success/failure. Record plugins.gsd = "installed" in $PREFS_PATH.

If they skip:

Skipped GSD. Install later with: /plugin marketplace add gsd-build/get-shit-done

Step 2b.5 — Superpowers (optional, recommended)

Several ops skills (/ops:ops-merge, /ops:ops-orchestrate, /ops:ops-triage) integrate with superpowers:* skills at key checkpoints — verification-before-completion, finishing-a-development-branch, dispatching-parallel-agents, systematic-debugging. Without superpowers installed, those checkpoints are no-ops; with it, they enforce stronger guardrails on merges, multi-agent dispatch, and root-cause analysis.

Check if superpowers is already installed:

find ~/.claude/plugins -path "*/superpowers/skills/using-superpowers" -type d 2>/dev/null | head -1 | grep -q . && echo "installed" || echo "not_installed"

If not installed, ask via AskUserQuestion:

Superpowers adds verification, dispatch, and debugging guardrails to ops skills.

  [Install Superpowers (latest)] [Skip — I'll add it later]

On install, run the commands directly:

claude plugin marketplace add obra/superpowers-marketplace 2>/dev/null && \
claude plugin install superpowers@superpowers-marketplace 2>/dev/null

Fallback if claude CLI is not on PATH:

SP_MARKETPLACE_DIR="$HOME/.claude/plugins/marketplaces/superpowers-marketplace"
if [ ! -d "$SP_MARKETPLACE_DIR" ]; then
  git clone https://github.com/obra/superpowers-marketplace.git "$SP_MARKETPLACE_DIR" 2>/dev/null
fi

Report success/failure. Record plugins.superpowers = "installed" in $PREFS_PATH.

If they skip:

Skipped Superpowers. Ops skills will run without superpower checkpoints.
Install later with: /plugin marketplace add obra/superpowers-marketplace

Step 2c — Feature-dev (optional, recommended for structured builds)

The feature-dev plugin adds a 7-phase feature pipeline (code-explorer, code-architect, code-reviewer agents). claude-ops routes to it via /ops:ops-feature-dev, /flow feature-dev, and silent auto-swap when general-purpose agents match explore/architect/review keywords.

Check if feature-dev is already installed:

find ~/.claude ~/.cursor -path "*/feature-dev/*/agents/code-explorer.md" 2>/dev/null | head -1 | grep -q . && echo "installed" || echo "not_installed"

If not installed, ask via AskUserQuestion:

Feature-dev adds structured feature development (explore → architect → implement → review).

  [Install feature-dev (latest)] [Skip — I'll add it later]

On install, try the Claude Code plugin CLI when available:

# Cursor / Claude Code — plugin id varies by marketplace; verify with: claude plugin list
claude plugin install feature-dev 2>/dev/null || true

Re-check with the find command above. If still not_installed, tell the user to install feature-dev from Cursor Settings → Plugins (or their Claude Code marketplace UI), then re-run /ops:setup.

Report success/failure. Record plugins.feature_dev = "installed" in $PREFS_PATH only when the find check passes.

If they skip:

Skipped feature-dev. Install later from Cursor plugins or run /feature-dev after installing the feature-dev plugin.
Structured builds still work via /flow build and gsd-execute-phase without it.

Step 2d — Background Daemon (early install, pre-warm caches)

Why install the daemon this early? Running the daemon in parallel with the rest of setup lets it start pre-warming the briefing cache (ops-gather results for infra/git/PRs/CI), so by the time the user reaches Step 7 and runs /ops:go, the briefing is already cached and loads in under 3 seconds instead of 10. Channel-dependent services (message-listener, inbox-digest) are added later in Step 5b once their channels are configured.

Platform support

The background daemon ships with a launchd integration (macOS only). Detect the platform before attempting install:

case "$(uname -s)" in
  Darwin)                OS=macos ;;
  Linux)                 grep -qi microsoft /proc/version 2>/dev/null && OS=wsl || OS=linux ;;
  MINGW*|MSYS*|CYGWIN*)  OS=windows ;;
  *)                     OS=unknown ;;
esac

• macOS (OS=macos): proceed with the full launchctl bootstrap flow below.
• Linux (OS=linux): use the bundled systemd --user installer. Run (RULE ZERO — run_in_background: true):

  bash ${CLAUDE_PLUGIN_ROOT}/scripts/install-ops-daemon-linux.sh

Generates ~/.config/systemd/user/claude-ops-daemon.service from scripts/systemd/claude-ops-daemon.service, enables linger (so the daemon survives logout), chowns ~/.claude/plugins/cache/ back to the user if it was left root-owned by a prior sudo run, then daemon-reload + enable --now. Idempotent. See scripts/install-ops-daemon-linux.sh --help for --dry-run and --uninstall.

Write daemon.enabled = true, daemon.installed_at_step = "2d", daemon.platform = "linux-systemd" to $PREFS_PATH and continue immediately to Step 3 — health verification is deferred to Step 5b.

• WSL (OS=wsl): systemd --user works on WSL2 with systemd=true in /etc/wsl.conf. If systemctl --user status succeeds, run the Linux installer above. Otherwise fall back to:

  ○ Background daemon — skipped (WSL without systemd). Launch manually with:
    nohup ${CLAUDE_PLUGIN_ROOT}/scripts/ops-daemon.sh > /tmp/ops-daemon.log 2>&1 &

Write daemon.enabled = false and daemon.skip_reason = "platform:wsl-no-systemd" to $PREFS_PATH and continue.

• Windows (native, OS=windows): the daemon is not installed. Print ○ Background daemon — not supported on native Windows. Use WSL or run ops-daemon.sh manually. and continue.

If OS=macos, check whether the daemon is already installed:

launchctl print gui/$(id -u)/com.claude-ops.daemon 2>/dev/null | head -1

If already loaded, print ✓ Background daemon already running — will reconcile services in Step 5b. and skip to Step 3.

Otherwise ask via AskUserQuestion:

Install the ops background daemon now?
  Starts pre-warming briefing cache while you finish the rest of setup.
  Auto-heals on failure. Single launchd agent (com.claude-ops.daemon).
  Channel services (whatsapp-bridge health, message-listener) added after channels are set up.
  [Yes — install now]  [Skip — I'll run it manually later]

On Yes, run the install (use run_in_background: true — RULE ZERO):

PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT:-$(ls -d "$HOME/.claude/plugins/cache/ops-marketplace/ops"/*/ 2>/dev/null | sort -V | tail -1)}"
bash "$PLUGIN_ROOT/scripts/install-ops-daemon.sh"

Generates ~/Library/LaunchAgents/com.claude-ops.daemon.plist from the bundled template, writes the initial channel-independent services config (briefing-pre-warm + memory-extractor), removes any legacy whatsapp-bridge keepalive, and bootstraps the daemon. Idempotent — re-running re-bootstraps cleanly. See scripts/install-ops-daemon.sh for the full procedure.

Write daemon.enabled = true and daemon.installed_at_step = "2d" to $PREFS_PATH so Step 5b knows to reconcile services instead of re-installing.

Print:

✓ Background daemon — installed. Pre-warming briefing cache in parallel while you finish setup.
  Channel-dependent services will be added after channels are configured (Step 5b).

Continue immediately to Step 3 — do NOT wait for the daemon to confirm startup. The health file check is deferred to Step 5b.

Deep-dive: see ${CLAUDE_PLUGIN_ROOT}/docs/daemon-guide.md for full operational instructions, CLI reference, and troubleshooting for the background daemon. The setup agent can load that file directly when it needs more depth than this wizard provides.

Step 2e — Recap Marquee (multi-session digest in tmux status-right)

The recap marquee is a separate launchd daemon (com.claude-ops.recap-daemon) that synthesizes a one-line digest across all parallel Claude Code sessions and recent shell activity, then exposes it via /tmp/claude-recap-digest for tmux to scroll across status-right. Independent from the main ops daemon — it can run on its own.

Skip this step entirely if recap_marquee_enabled = false in userConfig.

Step 2e.1 — Ask the user

Use AskUserQuestion:

Enable multi-session recap marquee?
  Background daemon synthesizes a one-line digest across all parallel Claude
  Code sessions + recent shell commands. Display in tmux status-right.
  [Yes — install + auto-configure]  [No — skip]  [What is this?]

If What is this?: explain (the daemon polls per-session recap files written by Stop + PostToolUse hooks, aggregates last 8 sessions + 10 prior digests + recent zsh activity into one Haiku-generated headline, refreshed every ~15s; tmux reads /tmp/claude-recap-digest from status-right and scrolls it). Then re-ask the binary question.

If No: write recap.enabled = false to $PREFS_PATH and skip to Step 3.

Step 2e.2 — Install launchd plist (macOS only)

Same platform gate as Step 2e. On Linux/WSL/Windows, print:

○ Recap daemon — skipped (launchd is macOS-only). Linux users: see
  /ops:recap configure for systemd unit example.

On macOS, install the plist (RULE 4 — run_in_background: true):

PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT:-$(ls -d "$HOME/.claude/plugins/cache/ops-marketplace/ops"/*/ 2>/dev/null | sort -V | tail -1)}"
bash "$PLUGIN_ROOT/scripts/install-recap-daemon.sh"

Generates ~/Library/LaunchAgents/com.claude-ops.recap-daemon.plist from the bundled template and bootstraps the agent. Macos-only (the script no-ops cleanly on Linux). See scripts/install-recap-daemon.sh for the full procedure.

Step 2e.3 — Display surface integration (tmux OR Claude Code statusLine)

The daemon writes /tmp/claude-recap-digest. Two display surfaces can render it (and they can coexist):

• tmux `status-right` — preferred when tmux is installed (richer color, scrolling).
• Claude Code `statusLine` — fallback when tmux is missing; renders in Claude Code's own status bar via ~/.claude/settings.json.

Detect tmux availability and branch:

if ! command -v tmux >/dev/null 2>&1; then
  echo "○ tmux not installed — offering Claude Code statusLine fallback instead."
  # → jump to Step 2e.3b (statusLine fallback)
fi

If recap_marquee_auto_configure_tmux = false, print the tmux snippet and skip the rest of this step (let user wire manually). The statusLine fallback in Step 2e.3b still applies if tmux is absent.

If tmux is present and recap_marquee_auto_configure_tmux = true, ask:

Auto-configure tmux status-right?
  [Yes — append to ~/.tmux.conf]  [Show me the line, I'll add manually]  [Skip]

On Show me the line, print the snippet and continue.

On Yes — append, detect existing status-right:

TMUX_CONF="$HOME/.tmux.conf"
existing=$(grep -E '^\s*set\s+-g\s+status-right' "$TMUX_CONF" 2>/dev/null | head -1)

If existing is non-empty, ask via AskUserQuestion (Rule 1 — exactly 4 options max):

Existing tmux status-right detected. How to integrate recap marquee?
  [Replace with recap-only]  [Append (keep existing line as comment)]  [Show me, I'll edit manually]  [Skip]

Append the snippet (or replace, per choice). Use an unquoted heredoc delimiter so ${PLUGIN_ROOT} expands to the installed plugin path (tmux #() does not expand env vars):

PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT:-$(ls -d "$HOME/.claude/plugins/cache/ops-marketplace/ops"/*/ 2>/dev/null | sort -V | tail -1)}"
cat >> "$TMUX_CONF" <<TMUX

# claude-ops recap marquee — synthesizes multi-session digest into status-right
set -g status-right '#('"${PLUGIN_ROOT}"'/scripts/recap/marquee.sh) #[fg=#a6e3a1]%H:%M '
set -g status-interval 2
TMUX

# Live-reload if tmux is currently running
tmux info >/dev/null 2>&1 && tmux source-file "$TMUX_CONF" 2>/dev/null

Step 2e.3b — Claude Code statusLine fallback (no tmux)

When command -v tmux returned non-zero in Step 2e.3, offer the Claude Code statusLine setting as the marquee surface. Same digest file (/tmp/claude-recap-digest), different render target. This is also safe to layer alongside tmux if both are present — but typically only run when tmux is absent.

Ask via AskUserQuestion (Rule 1 — exactly 4 options):

No tmux detected. Wire the recap marquee into Claude Code's statusLine instead?
  [Add to Claude Code statusLine]  [Show me the JSON, I'll add manually]  [Skip]  [Help]

On Help: explain that Claude Code reads ~/.claude/settings.json → statusLine and runs the configured command on each refresh, displaying the output in its own status bar. Then re-ask.

On Show me the JSON: print the snippet below and continue to Step 2e.4 with recap.statusline_wired = false.

On Skip: write recap.statusline_wired = false and continue to Step 2e.4.

On Add to Claude Code statusLine:

1. Pre-check — `jq` availability: Step 2e.3b uses jq for every settings.json read/merge. If jq is missing, all subsequent jq calls silently fail (suppressed by 2>/dev/null), existing evaluates to empty, and the merge step is skipped — but the success path would still record recap.statusline_wired = true in prefs, leaving the user in an inconsistent state. Guard up front:

   if ! command -v jq >/dev/null 2>&1; then
     echo "○ jq not installed — cannot merge statusLine automatically."
     echo "  Install jq (e.g. brew install jq, apt install jq) and re-run /ops:recap configure."
     # Do NOT mark statusline_wired=true. Treat as Skip:
     # write recap.statusline_wired = false in Step 2e.5 and continue to Step 2e.4.
   fi

Only continue with steps 1–5 below when jq is present.

1. Detect existing statusLine entry:

   SETTINGS="$HOME/.claude/settings.json"
   mkdir -p "$(dirname "$SETTINGS")"
   [ -f "$SETTINGS" ] || echo '{}' > "$SETTINGS"
   existing=$(jq -r '.statusLine // empty' "$SETTINGS" 2>/dev/null)

1. If existing is non-empty, ask via AskUserQuestion (Rule 1 — 3 options):

   Existing statusLine detected in ~/.claude/settings.json. How to handle?
     [Replace with recap]  [Append after current (chain commands)]  [Skip]

• Replace with recap → overwrite the statusLine key.
• Append after current → preserve the existing command but suffix ; cat /tmp/claude-recap-digest 2>/dev/null | head -c 80 so both render. Use the existing entry's type and refreshInterval.
• Skip → leave settings.json untouched, write recap.statusline_wired = false, and continue.

1. Merge with jq (preserves all other keys — never overwrite the whole file):

   TMP=$(mktemp)
   jq '.statusLine = {
     "type": "command",
     "command": "cat /tmp/claude-recap-digest 2>/dev/null | head -c 80",
     "refreshInterval": 30
   }' "$SETTINGS" > "$TMP" && mv "$TMP" "$SETTINGS"

For the Append after current branch, build the merged command first:

   prev_cmd=$(jq -r '.statusLine.command // ""' "$SETTINGS")
   if [ -n "$prev_cmd" ]; then
     new_cmd="${prev_cmd}; cat /tmp/claude-recap-digest 2>/dev/null | head -c 80"
   else
     new_cmd="cat /tmp/claude-recap-digest 2>/dev/null | head -c 80"
   fi
   TMP=$(mktemp)
   jq --arg cmd "$new_cmd" '.statusLine.command = $cmd' "$SETTINGS" > "$TMP" && mv "$TMP" "$SETTINGS"

1. Print:

   ✓ Claude Code statusLine wired — restart Claude Code (or open a new session) to activate.

Then write recap.statusline_wired = true before continuing to Step 2e.4.

The JSON snippet to show on Show me the JSON:

{
  "statusLine": {
    "type": "command",
    "command": "cat /tmp/claude-recap-digest 2>/dev/null | head -c 80",
    "refreshInterval": 30
  }
}

Step 2e.4 — Verify daemon is producing output

Wait up to 60s for the daemon to write its first digest. Run in background; do NOT block the wizard:

(
  for i in $(seq 1 12); do
    [ -f /tmp/claude-recap-digest ] && [ -s /tmp/claude-recap-digest ] && exit 0
    sleep 5
  done
  echo "WARN: recap daemon did not produce /tmp/claude-recap-digest within 60s — check /tmp/claude-recap-daemon.log" >&2
) &

Step 2e.5 — Persist preferences

Write to $PREFS_PATH. Set both "tmux_wired" and "statusline_wired" dynamically based on the user’s actual choices:

• "tmux_wired": true when tmux was installed and the user chose to wire status-right in Step 2e.3; false when tmux was missing, the user chose Skip, or Show me the line.
• "statusline_wired": true only after Add to Claude Code statusLine successfully merged recap into ~/.claude/settings.json in Step 2e.3b; false after Skip, Show me the JSON, the nested Skip when an existing statusLine was detected, or if Step 2e.3b did not run (e.g. tmux-only path).

{
  "recap": {
    "enabled": true,
    "tmux_wired": "<true|false — based on Step 2e.3 outcome>",
    "statusline_wired": "<true|false — based on Step 2e.3b outcome>",
    "installed_at_step": "2d",
    "platform": "macos"
  }
}

Example: tmux wired + statusLine skipped → "tmux_wired": true, "statusline_wired": false. No tmux + statusLine wired → "tmux_wired": false, "statusline_wired": true.

Print:

✓ Recap marquee — daemon installed (com.claude-ops.recap-daemon).
  Tmux status-right wired (or skipped per your choice).
  Manage anytime: /ops:recap status | tail | configure | restart

Continue to Step 2f.

Step 2f — Statusline Cockpit (if selected)

Configures the Claude Code statusLine setting — a 3-line terminal cockpit showing context-window health, quota gauges, git branch, fleet state, sys metrics, and per-project ops badges.

Rule Zero: every Bash call in this step MUST use run_in_background: true.

Step 2f.1 — Resolve paths (run_in_background: true)

PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT:-$(ls -d "$HOME/.claude/plugins/cache/ops-marketplace/ops"/*/ 2>/dev/null | sort -V | tail -1)}"
RENDERER_SRC="${PLUGIN_ROOT}templates/statusline/statusline-command.sh"
RENDERER_DST="$HOME/.claude/statusline-command.sh"
SETTINGS_FILE="$HOME/.claude/settings.json"
CFG_DST="$HOME/.claude/statusline.config.json"
SUGGEST_BIN="${PLUGIN_ROOT}bin/ops-statusline-suggest"
THEMES_FILE="${PLUGIN_ROOT}templates/statusline/themes.json"

If RENDERER_SRC does not exist, print:

○ Statusline template not found at expected plugin path. Skipping statusline step.
  (Re-run /ops:setup after updating the plugin: ops-statusline-suggest should be at
   ${PLUGIN_ROOT}bin/ops-statusline-suggest)

Then skip the rest of this step and continue to Step 3.

Step 2f.2 — Ask preset (max 4 options per Rule 1)

Use AskUserQuestion:

Configure the Claude Code cockpit statusline?
  [Yes — cockpit (full color, gauges, per-project badges)]
  [Yes — minimal (essentials, low noise)]
  [Yes — full (all metrics, widest gauges)]
  [Skip — configure later with /ops:statusline config]

On Skip: write statusline.enabled = false to $PREFS_PATH and continue to Step 3.

Set CHOSEN_PRESET from the user's choice (cockpit, minimal, or full).

Step 2f.3 — Ask theme (max 4 options per Rule 1)

Use AskUserQuestion:

Which color theme?
  [cockpit — rich color, graded gauges (Default)]
  [minimal — two shades, no color grading]
  [nord — cool blues and greens]
  [mono — bold only, no color]

Set CHOSEN_THEME.

Step 2f.4 — Run registry auto-suggest (run_in_background: true)

SUGGESTED=$("$SUGGEST_BIN" --preset "$CHOSEN_PRESET" --theme "$CHOSEN_THEME" 2>/tmp/ops-statusline-suggest.log)
PROJ_COUNT=$(printf '%s' "$SUGGESTED" | jq -r '._detected.projects_found // 0' 2>/dev/null || echo 0)

Print detection summary: Detected $PROJ_COUNT projects from registry.

Step 2f.5 — Install renderer (run_in_background: true)

cp "$RENDERER_SRC" "$RENDERER_DST"
chmod +x "$RENDERER_DST"

Validate: [ -x "$RENDERER_DST" ] && echo "✓ Renderer installed at $RENDERER_DST"

Step 2f.6 — Write config (run_in_background: true)

TMP=$(mktemp)
printf '%s\n' "$SUGGESTED" | jq 'del(._comment, ._detected)
  | . + {"_comment": "Configured by /ops:setup on '"$(date -u +%Y-%m-%dT%H:%M:%SZ)"'."}' > "$TMP"
mv "$TMP" "$CFG_DST"
jq . "$CFG_DST" >/dev/null 2>&1 && echo "✓ Config written" || echo "✗ Config JSON invalid"

Step 2f.7 — Merge settings.json statusLine (run_in_background: true)

IMPORTANT: use jq to _merge_ — never clobber the entire settings.json.

STATUSLINE_CMD_STR="\$HOME/.claude/statusline-command.sh"

if [ ! -f "$SETTINGS_FILE" ]; then
  # H5: write to tempfile then atomic mv — Claude Code reads settings.json every frame
  TMP=$(mktemp)
  jq -n --arg cmd "$STATUSLINE_CMD_STR" '{"statusLine": {"command": $cmd}}' > "$TMP" \
    && mv "$TMP" "$SETTINGS_FILE"
else
  EXISTING=$(jq -r '.statusLine.command // empty' "$SETTINGS_FILE" 2>/dev/null)
  if [ -n "$EXISTING" ]; then
    # statusLine already set — ask whether to overwrite
    echo "existing_statusline=$EXISTING"
  else
    # H5: backup existing file, then atomic write via tmp
    cp "$SETTINGS_FILE" "${SETTINGS_FILE}.bak" 2>/dev/null || true
    TMP=$(mktemp)
    jq --arg cmd "$STATUSLINE_CMD_STR" '.statusLine = {"command": $cmd}' "$SETTINGS_FILE" > "$TMP" \
      && mv "$TMP" "$SETTINGS_FILE"
    echo "✓ statusLine wired in ~/.claude/settings.json"
  fi
fi

If existing_statusline is non-empty, use AskUserQuestion:

~/.claude/settings.json already has a statusLine.command. Overwrite?
  [Yes — replace with the cockpit renderer]
  [No — keep existing and skip]

On Yes: run the merge above with the new command. On No: skip the merge and note statusline.settings_wired = false.

Step 2f.8 — Quick preview (run_in_background: true)

PAYLOAD='{"model":{"display_name":"Claude Sonnet"},"rate_limits":{"five_hour":{"used_percentage":30}},"context_window":{"used_percentage":20},"cost":{"total_cost_usd":0.05}}'
printf '%s' "$PAYLOAD" | COLUMNS=100 "$RENDERER_DST" 2>/dev/null

Print between ruler lines so the user sees the cockpit preview inline.

If the render fails (exit non-zero or empty output), print a non-fatal note:

○ Preview failed — renderer may need Claude Code restart to load new settings.json.
  Manage with: /ops:statusline preview | doctor | config

Step 2f.9 — Persist preferences (run_in_background: true)

jq -n \
  --arg preset "$CHOSEN_PRESET" \
  --arg theme "$CHOSEN_THEME" \
  --argjson proj_count "$PROJ_COUNT" \
  '{
    "statusline": {
      "enabled": true,
      "preset": $preset,
      "theme": $theme,
      "projects_detected": $proj_count,
      "renderer": "~/.claude/statusline-command.sh",
      "config": "~/.claude/statusline.config.json"
    }
  }' | jq -s '.[0] * .[1]' "$PREFS_PATH" - > /tmp/prefs-sl-merge.json \
    && mv /tmp/prefs-sl-merge.json "$PREFS_PATH" \
    && echo "✓ Preferences saved"

Print summary:

✓ Statusline cockpit configured (preset=$CHOSEN_PRESET, theme=$CHOSEN_THEME, projects=$PROJ_COUNT).
  Restart Claude Code to activate the statusLine in your terminal.
  Manage anytime: /ops:statusline preview | config | theme | doctor | reset

Continue to Step 3.

Step 3 — Configure channels (if selected)

First, offer a quick "configure everything" option before individual selection. Use AskUserQuestion:

How would you like to configure channels and integrations?
  [Configure all — set up every available channel and service (Recommended)]
  [Pick individually — choose which channels to configure]
  [Skip all — configure channels later]

If the user selects "Configure all", run every channel sub-flow below in sequence (Telegram → WhatsApp → Email → Slack → Notion → Calendar → Doppler → Vault), skipping any already configured. If the user selects "Skip all", move to Step 4.

If the user selects "Pick individually", ask which channels using AskUserQuestion with multiSelect: true. Because AskUserQuestion allows max 4 options, batch into two groups. Skip channels already configured (show only those needing attention).

Batch 1 — Messaging:

Batch 2 — Knowledge & Services:

Batch 3 — Voice journal & integrations (show only if not already configured):

Present each batch as a separate AskUserQuestion call. Skip batches where all items are already configured. For each selected channel, run the matching sub-flow below.

Shared Step-3 material

Before running any channel block below, load [SHARED.md](SHARED.md). It contains:

• Host OS detection (pick the right package manager — brew/apt/dnf/pacman/winget)
• OAuth-vs-manual-token preference rules
• Universal Credential Auto-Scan — the 10-source scan every credential prompt must run before asking the user
• Per-channel credential auto-scan bridge (Telegram, Slack)

Every channel sub-flow below references "the Universal Credential Auto-Scan" by name and assumes SHARED.md is in scope.

3a — Telegram (user-auth via ops-telegram-autolink)

Loaded from `channels/telegram.md` — Bot token + owner ID, ops-telegram-autolink, message-history backfill. Load that file before running this sub-flow.

3b — WhatsApp (bridge health + QR pair)

Loaded from `channels/whatsapp.md` — wacli bridge health, QR pairing, app-state recovery, keepalive. Load that file before running this sub-flow.

3c — Email

Loaded from `channels/email.md` — gog CLI (preferred) or Gmail MCP fallback. Load that file before running this sub-flow.

3d — Slack (scout + ops-slack-autolink)

Loaded from `channels/slack.md` — MCP via claude mcp add slack + ops-slack-autolink scout. Load that file before running this sub-flow.

3e — Notion (MCP integration)

Loaded from `channels/notion.md` — Workspace search, comments, tasks via Notion MCP. Load that file before running this sub-flow.

3f — Calendar

Loaded from `channels/calendar.md` — gog calendar (preferred) or Google Calendar MCP fallback. Load that file before running this sub-flow.

3g — Doppler (secrets management)

Loaded from `channels/doppler.md` — Default project/config + Doppler MCP server. Load that file before running this sub-flow.

3h — Password Manager (credential vault)

Loaded from `channels/password-manager.md` — 1Password/Dashlane/Bitwarden/Keychain auto-detect + query-template wiring. Load that file before running this sub-flow.

3i — Ecommerce (Shopify + dynamic partners)

Loaded from `channels/ecommerce.md` — Shopify multi-store auto-scan + dynamic partner loop (ShipBob, Recharge, Yotpo, etc). Load that file before running this sub-flow.

3j — Marketing (Klaviyo, Meta Ads, GA4, Search Console)

Loaded from `channels/marketing.md` — Klaviyo, Meta Ads, Google Ads (OAuth2), GA4, Search Console, WhatsApp Business + dynamic partner loop. Load that file before running this sub-flow.

3k — Voice (Bland AI, ElevenLabs, Groq)

Loaded from `channels/voice.md` — Bland AI, ElevenLabs, Groq. Load that file before running this sub-flow.

3l — Revenue (Stripe + RevenueCat)

Loaded from `channels/revenue.md` — Stripe + RevenueCat. Load that file before running this sub-flow.

3n — Notifications (fires-watcher sinks)

Loaded from `channels/notifications.md` — fires-watcher per-sink capture. Load that file before running this sub-flow.

3k-home — Home Automation (Homey Pro)

Scout for credentials in background (RULE ZERO):

# Run all scouts simultaneously — run_in_background: true on each
security find-generic-password -s homey-local-token -w 2>/dev/null
echo "$HOMEY_LOCAL_TOKEN"
doppler secrets get HOMEY_LOCAL_TOKEN --project homey-pro --plaintext 2>/dev/null
op item get "Homey" --fields=token 2>/dev/null

If any scout returns a non-empty value, pre-fill it as the default; present found values alongside [Use found value] / [Paste manually] / [Skip].

Required:

1. HOMEY_LOCAL_URL — LAN IP of the Homey Pro, e.g. https://192.168.1.42. Ask via AskUserQuestion free-text.
2. HOMEY_LOCAL_TOKEN — Personal Access Token from https://my.homey.app/manager/tokens. Ask via AskUserQuestion with sensitive: true.

Optional:

Ask via one AskUserQuestion call:

Configure optional Homey cloud credentials?
  [Yes — paste cloud token + Homey ID]
  [Skip optional fields]

If yes, collect HOMEY_CLOUD_TOKEN (Athom OAuth token) and HOMEY_ID (hub ID) via two follow-up AskUserQuestion calls with sensitive: true.

Validate (smoke test, RULE ZERO):

curl -s -H "Authorization: Bearer $HOMEY_LOCAL_TOKEN" \
  "$HOMEY_LOCAL_URL/api/manager/system/system/info" 2>/dev/null

Expect HTTP 200 with JSON containing homeyVersion. If the check fails, present [Retry] / [Save anyway — LAN may be offline] / [Skip] via AskUserQuestion (Rule 3 — never auto-skip).

Save to $PREFS_PATH via jq:

jq --arg url "$HOMEY_LOCAL_URL" \
   --arg lt "$HOMEY_LOCAL_TOKEN" \
   --arg ct "${HOMEY_CLOUD_TOKEN:-}" \
   --arg id "${HOMEY_ID:-}" \
   '.home_automation = {provider: "homey", homey_local_url: $url, homey_local_token: $lt, homey_cloud_token: $ct, homey_id: $id}' \
   "$PREFS_PATH" > "$PREFS_PATH.tmp" && mv "$PREFS_PATH.tmp" "$PREFS_PATH"

Print: ✓ Home automation — Homey Pro configured (local: $HOMEY_LOCAL_URL)

3q-network — UniFi Network (Site Manager + local console)

Scout for credentials in background (RULE ZERO):

# Run all scouts simultaneously — run_in_background: true on each
printenv UNIFI_SITE_MANAGER_API_KEY UNIFI_LOCAL_GATEWAY_URL UNIFI_LOCAL_API_KEY UNIFI_PROTECT_URL UNIFI_PROTECT_API_KEY 2>/dev/null
doppler secrets --project unifi --config prd --json 2>/dev/null | jq -r 'to_entries[] | select(.key|test("UNIFI";"i")) | "\(.key)=(present)"'
security find-generic-password -s "unifi-site-manager-key" -w 2>/dev/null
security find-generic-password -s "unifi-local-key" -w 2>/dev/null
security find-generic-password -s "unifi-protect-key" -w 2>/dev/null

If any scout returns a non-empty value, pre-fill it as the default; present found values alongside [Use found value] / [Paste manually] / [Skip this surface].

Optional surfaces (any subset may be configured — ask per surface, Rule 3):

1. Site Manager (cloud) — UNIFI_SITE_MANAGER_API_KEY from unifi.ui.com → Settings → Control Plane → Integrations → Create API Key.
2. Network (local) — UNIFI_LOCAL_GATEWAY_URL (e.g. https://192.168.1.1) + UNIFI_LOCAL_API_KEY from the Network app → Settings → Control Plane → Integrations.
3. Protect (local) — UNIFI_PROTECT_URL (defaults to gateway URL) + UNIFI_PROTECT_API_KEY from Protect → Settings → Control Plane → Integrations (or reuse the OS key).

Discover the console on the LAN when gateway URL is unknown:

for ip in 192.168.1.1 192.168.0.1 10.0.0.1; do curl -sk --max-time 2 "https://$ip" -o /dev/null -w "$ip → %{http_code}\n" 2>/dev/null; done

Validate each acquired credential before saving (smoke test, RULE ZERO):

# Site Manager
curl -s --max-time 15 -H "X-API-Key: $UNIFI_SM_KEY" https://api.ui.com/v1/hosts | jq -e '.data' >/dev/null
# Network (self-signed cert ⇒ -k)
curl -sk --max-time 12 -H "X-API-Key: $UNIFI_LOCAL_KEY" "${UNIFI_LOCAL_URL}/proxy/network/integration/v1/sites" | jq -e '.data' >/dev/null
# Protect
curl -sk --max-time 12 -H "X-API-Key: $UNIFI_PROTECT_KEY" "${UNIFI_PROTECT_URL}/proxy/protect/integration/v1/meta/info" | jq -e '.version' >/dev/null

401/403 → key invalid; re-prompt via AskUserQuestion ([Paste new key], [Skip this surface]).

Save to $PREFS_PATH via jq (merge — omit empty fields, keep existing values for skipped surfaces):

jq --arg sm "${UNIFI_SM_KEY:-}" \
   --arg url "${UNIFI_LOCAL_URL:-}" \
   --arg lk "${UNIFI_LOCAL_KEY:-}" \
   --arg pu "${UNIFI_PROTECT_URL:-}" \
   --arg pk "${UNIFI_PROTECT_KEY:-}" \
   '.home_network = ((.home_network // {}) + {
     unifi_site_manager_api_key: (if $sm != "" then $sm else (.home_network.unifi_site_manager_api_key // "") end),
     unifi_local_gateway_url: (if $url != "" then $url else (.home_network.unifi_local_gateway_url // "") end),
     unifi_local_api_key: (if $lk != "" then $lk else (.home_network.unifi_local_api_key // "") end),
     unifi_protect_url: (if $pu != "" then $pu else (.home_network.unifi_protect_url // "") end),
     unifi_protect_api_key: (if $pk != "" then $pk else (.home_network.unifi_protect_api_key // "") end)
   })' \
   "$PREFS_PATH" > "$PREFS_PATH.tmp" && mv "$PREFS_PATH.tmp" "$PREFS_PATH"

Print: ✓ UniFi network — configured (site-manager: ${UNIFI_SM_KEY:+yes}${UNIFI_SM_KEY:-no} · local: ${UNIFI_LOCAL_URL:-—} · protect: ${UNIFI_PROTECT_URL:-—})

Deep-dive: see ${CLAUDE_PLUGIN_ROOT}/skills/ops-unifi/SKILL.md for full operational instructions, API reference, and troubleshooting.

3m — Discord (webhook + optional bot)

Loaded from `channels/discord.md` — Webhook + optional bot token. Load that file before running this sub-flow.

3o — Claude account rotator OAuth (if selected)

Loaded from `channels/claude-rotator.md` — Account rotator OAuth — delegates to /ops:rotate-setup. Load that file before running this sub-flow.

3p — Pocket (voice journal activity notifier)

Loaded from `channels/pocket.md` — POCKET_API_KEY credential + WhatsApp/email channel config + launchd notifier install + smoke test. Load that file before running this sub-flow.

Step 4 — Configure MCPs (if selected)

For each MCP that isn't in mcp_configured, offer bulk setup first:

Unconfigured MCPs: Linear, Sentry, Vercel. What would you like to do?
  [Configure all MCPs — run claude mcp add for each (Recommended)]
  [Pick which MCPs to add]
  [Skip MCP configuration]

If the user selects "Configure all", run claude mcp add <name> for each unconfigured MCP in sequence. If "Pick which", list each individually:

Linear:  claude mcp add linear
Sentry:  claude mcp add sentry
Vercel:  claude mcp add vercel
Slack:   claude mcp add slack
Gmail:   claude mcp add gmail   (fallback only — prefer `gog` CLI, see Step 3c)

Offer [Add now], [Skip] for each. Do not try to register MCPs from the skill — the plugin can't do that safely.

Email note: the ops plugin's primary email path is the gog CLI (full read + send, own OAuth). The Gmail MCP connector works as a fallback but cannot send without extra permission config in Claude Desktop → Settings → Connectors. The wizard handles that detection in Step 3c; this step only lists it so users who deliberately prefer MCP can install it here.

Deep-dive: see ${CLAUDE_PLUGIN_ROOT}/skills/ops-linear/SKILL.md, ${CLAUDE_PLUGIN_ROOT}/skills/ops-triage/SKILL.md, and ${CLAUDE_PLUGIN_ROOT}/skills/ops-fires/SKILL.md for full operational instructions, CLI reference, and troubleshooting for the MCP-backed integrations (Linear issue flows, triage routing, Sentry/Vercel fires). The setup agent can load those files directly when it needs more depth than this wizard provides.

Step 5 — Build the project registry (if selected)

Templates: a pre-baked starter for common stacks lives in ${CLAUDE_PLUGIN_ROOT}/scripts/registry.templates/. If you want to start from one, cp "${CLAUDE_PLUGIN_ROOT}/scripts/registry.templates/<stack>.json" "${CLAUDE_PLUGIN_ROOT}/scripts/registry.json" then edit — or continue the wizard below for interactive discovery.

Auto-discover from filesystem

Before asking the user to manually enter projects, scan for existing git repositories:

find ~ ~/Projects -maxdepth 2 -name ".git" -type d 2>/dev/null | sed 's|/.git||' | sort

Present the discovered paths to the user via AskUserQuestion with multiSelect: true. Max 4 options per call — paginate at 3 projects per page + [More...] or [None — I'll enter projects manually] as the last option:

Found git repositories (page 1 of N):
  [ ] ~/Projects/my-app
  [ ] ~/Projects/my-api
  [ ] ~/Projects/my-ai
  [ ] More repositories...

On the final page, replace "More repositories..." with [None of the above / Done selecting].

For each selected project, collect these fields one AskUserQuestion at a time:

• alias (short name, required — suggest the directory name as default)
• org (GitHub org or owner, e.g. your-org or your-username)
• infra.platform → select [aws], [vercel], [cloudflare], [other]
• revenue.model → select in batches of 4: [saas], [subscription], [marketplace], [More...] then [internal], [portfolio], [other]

Auto-discover external projects

A real user's portfolio is rarely just git repos. Shopify stores, Linear teams, Slack workspaces, and Notion databases are first-class projects that ops-external + ops-projects know how to surface — but only if they land in registry.json. This sub-step probes whatever integrations the wizard has already configured and offers discovered items for one-click registration.

${CLAUDE_PLUGIN_ROOT}/bin/ops-discover-external 2>/dev/null || echo '[]'

The script reads Shopify creds from $PREFS_PATH .ecom.shopify.* + SHOPIFY_* env, Linear from LINEAR_API_KEY, Slack from keychain slack-xoxc/slack-xoxd, and Notion from NOTION_API_KEY / keychain notion-api-key. It returns an array of candidate projects, each with a ready-to-merge config block.

Parse the candidates and — for each one not already present in registry.json (match by config.alias or by source + source-specific ID) — present it via AskUserQuestion. Batch at 3 candidates per call + [More...] to respect Rule 1 (max 4 options). Example batch:

Found external projects not yet in your registry (page 1 of N):
  [Register "mystore" (shopify — basic plan, 142 products)]
  [Register "linear-eng" (linear — Engineering, 42 open issues)]
  [Register "notion-roadmap" (notion — Product Roadmap database)]
  [More candidates...]

On the final page, the last option becomes [None of the remaining — skip]. Multi-select is acceptable — if you offer it, keep the multiSelect: true list size ≤ 4.

For each accepted candidate, merge its config block straight into registry.json .projects[] with jq:

PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT}"
REG="$PLUGIN_ROOT/scripts/registry.json"
[ -f "$REG" ] || echo '{"version":"1.0","owner":"","projects":[]}' > "$REG"
jq --argjson new "$CONFIG_JSON" '.projects += [$new]' "$REG" > "$REG.tmp" && mv "$REG.tmp" "$REG"

Status handling:

• discovered → register as-is.
• auth_expired → surface a warning and route the user to /ops:setup for the affected channel before retrying.
• unreachable → offer [Register anyway (will show as unreachable in dashboards)] / [Skip].

If the discovery script returns [], print a single info line (ℹ No external projects auto-discovered. You can add Shopify / Linear / Slack / Notion manually below.) and continue. Never silently skip — the user must know the discovery ran.

If the candidate's credential value came from an env var but the user later wants Doppler, the credential key stored in the candidate (SHOPIFY_ADMIN_TOKEN, etc.) is safe to replace with a doppler: reference later via /ops:settings.

Existing registry

If registry.json already has projects, ask first (4 options, fits in one call): [Keep existing N projects], [Add more projects], [Auto-detect from existing registry], [Start from scratch].

• "Keep existing" → skip this step.
• "Auto-detect from existing registry" → re-read the registry, show a summary of what's already there, and offer to add missing fields or newly-discovered repos.
• "Start from scratch" → write an empty skeleton first ({"version":"1.0","owner":"","projects":[]}) — prompt to confirm before overwriting.
• "Add more" → run the auto-discover scan above, then offer manual entry as a fallback.

Manual add loop

After auto-discovery (or if the user selects "I'll enter projects manually"):

• Ask AskUserQuestion: "Add another project?" → [Yes], [Done].
• If Yes, collect these fields one `AskUserQuestion` at a time:
• alias (short name, required)
• paths (comma-separated absolute paths, required)
• repos (comma-separated org/repo, required)
• type → select [monorepo], [multi-repo]
• infra.platform → select [aws], [vercel], [cloudflare], [other]
• revenue.model → select in batches of 4: [saas], [subscription], [marketplace], [More...] then [internal], [portfolio], [other]
• revenue.stage → select [pre-launch], [development], [growth], [active]
• gsd → select [Yes], [No]
• priority (1-99, defaults to max+1)
• Ensure the registry directory exists: mkdir -p "${CLAUDE_PLUGIN_ROOT}/scripts". If the write fails due to permissions (plugin cache dirs can be read-only), fall back to writing at $DATA_DIR/registry.json and symlink it.
• Read the current registry with jq, append the new project, write back atomically (jq ... > tmp && mv tmp registry.json).
• After each addition, print the running count and offer [Add another] / [Done].
• The registry agent (if spawned) MUST have write access to the target path. If it can't write, the setup wizard should write the file itself from the agent's returned JSON — do not ask the user to intervene.

Deep-dive: see ${CLAUDE_PLUGIN_ROOT}/skills/ops-projects/SKILL.md for full operational instructions, CLI reference, and troubleshooting for the project registry (auto-discovery, registry schema, GSD filters, priority ordering). The setup agent can load that file directly when it needs more depth than this wizard provides.

Step 5b — Daemon Service Reconciliation

By now, the daemon was already installed in Step 2d and has been pre-warming the briefing cache in the background while the user configured channels. This step adds channel-dependent services (whatsapp-bridge, message-listener, inbox-digest, store-health, competitor-intel) now that we know which channels and integrations are configured.

Skip conditions:

• If the user declined daemon install in Step 2d, skip this step entirely.
• If daemon.enabled != true in $PREFS_PATH, skip.

Otherwise continue — reconcile the services list:

1. Verify the daemon is running:

DATA_DIR="${CLAUDE_PLUGIN_DATA_DIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}"
PLIST_DEST="$HOME/Library/LaunchAgents/com.claude-ops.daemon.plist"
launchctl print gui/$(id -u)/com.claude-ops.daemon >/dev/null 2>&1 || {
  # Daemon not running — install it now as a fallback
  launchctl bootstrap gui/$(id -u) "$PLIST_DEST" 2>/dev/null
}

2. Verify health after 5 seconds:

cat "$DATA_DIR/daemon-health.json" 2>/dev/null

Parse the JSON. If action_needed is not null, surface the required action to the user. If the daemon wrote a health file, print:

✓ Background daemon — running (whatsapp-bridge: connected, memory-extractor: scheduled)

If the health file is missing (daemon may still be initializing), wait 5 more seconds and retry once. If still missing, print:

⚠ Daemon started but health file not yet written. Check:
  launchctl print gui/$(id -u)/com.claude-ops.daemon
  tail -20 ~/.claude/plugins/data/ops-ops-marketplace/logs/ops-daemon.log

3. Build the full services list and reconcile with the config written in Step 2d:

Determine which services to enable based on what was configured in earlier steps. The briefing-pre-warm and memory-extractor services were already enabled at Step 2d — preserve them. Add channel-dependent services based on what's now configured:

• whatsapp-bridge — always include if WhatsApp is configured (channels.whatsapp is set)
• memory-extractor — always include
• inbox-digest — always include (runs every 4h, aggregates all configured channels)
• store-health — include ONLY if ecommerce was configured (ecom.shopify.store_url is set in $PREFS_PATH)
• competitor-intel — include only if the user configures queries (see step 5b-i below); otherwise enable with `enabled: fals