Setup

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 wacli doctor 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.

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/wacli-doctor.json and wacli-chats.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:       zsh → ~/.zshrc
 Core CLIs:   ✓ jq  ✓ git  ✓ gh  ✓ aws  ✓ node
 Channels:    ✓ wacli  ✓ 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.

Step 1 — Ask which sections to configure

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 → 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", show a single AskUserQuestion listing the section names (cli, daemon, channels, mcp, registry, prefs, env, ecom, mktg, voice, revenue) and jump directly to that step.

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):

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, wacli. 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]
Install wacli?        [Yes, install now] [Skip — manual install required]

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 2c — 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 (wacli-sync, message-listener, inbox-digest, store-health) 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 / WSL (OS=linux|wsl): launchctl is not available. The daemon script (${CLAUDE_PLUGIN_ROOT}/scripts/ops-daemon.sh) runs fine under bash, but installing it as a user service requires systemd --user (Linux) or a custom cron/at wrapper (WSL). That work is out of scope for this patch — track as future work. For now, print:

  ○ Background daemon — skipped (Linux/WSL install via systemd --user is pending; see docs/daemon-guide.md).
    You can still launch it manually with:  nohup ${CLAUDE_PLUGIN_ROOT}/scripts/ops-daemon.sh &
  

  Write daemon.enabled = false and daemon.skip_reason = "platform:<os>" to $PREFS_PATH and continue to Step 3.

• 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 (wacli-sync, 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):

# Always resolve CLAUDE_PLUGIN_ROOT to the CURRENT installed version — never hardcode a version number.
# If CLAUDE_PLUGIN_ROOT is not set, detect it from the plugin cache:
PLUGIN_ROOT="${CLAUDE_PLUGIN_ROOT:-$(ls -d "$HOME/.claude/plugins/cache/ops-marketplace/ops"/*/ 2>/dev/null | sort -V | tail -1)}"
DAEMON_SCRIPT="${PLUGIN_ROOT}/scripts/ops-daemon.sh"
chmod +x "$DAEMON_SCRIPT"
PLIST_TEMPLATE="${PLUGIN_ROOT}/scripts/com.claude-ops.daemon.plist"
PLIST_DEST="$HOME/Library/LaunchAgents/com.claude-ops.daemon.plist"
DATA_DIR="${CLAUDE_PLUGIN_DATA_DIR:-$HOME/.claude/plugins/data/ops-ops-marketplace}"
LOG_DIR="$DATA_DIR/logs"
mkdir -p "$LOG_DIR"

# Resolve bash 4+ (required for associative arrays in ops-daemon.sh).
# macOS ships bash 3; Homebrew installs bash 5 at /opt/homebrew/bin/bash.
BASH_PATH="/bin/bash"
if [[ -x /opt/homebrew/bin/bash ]]; then
  BASH_PATH="/opt/homebrew/bin/bash"
elif [[ -x /usr/local/bin/bash ]]; then
  BASH_PATH="/usr/local/bin/bash"
fi

# Generate plist
sed -e "s|__DAEMON_SCRIPT_PATH__|$DAEMON_SCRIPT|g" \
    -e "s|__BASH_PATH__|$BASH_PATH|g" \
    -e "s|__PLUGIN_ROOT__|$PLUGIN_ROOT|g" \
    -e "s|__LOG_DIR__|$LOG_DIR|g" \
    -e "s|__HOME__|$HOME|g" \
    "$PLIST_TEMPLATE" > "$PLIST_DEST"

# Write a minimal initial services config — only the services that don't depend on
# channels yet. `briefing-pre-warm` runs ops-gather every 2 minutes so the next
# /ops:go is instant. `memory-extractor` runs but stays idle until channels exist.
SERVICES_CONFIG="$DATA_DIR/daemon-services.json"
cat > "$SERVICES_CONFIG" <<JSON
{
  "services": {
    "briefing-pre-warm": {
      "enabled": true,
      "command": "${CLAUDE_PLUGIN_ROOT}/bin/ops-gather",
      "cron": "*/2 * * * *",
      "_note": "Pre-warms /ops:go cache. Runs every 2 minutes."
    },
    "memory-extractor": {
      "enabled": true,
      "command": "${CLAUDE_PLUGIN_ROOT}/scripts/ops-memory-extractor.sh",
      "cron": "*/30 * * * *",
      "health_file": "~/.claude/plugins/data/ops-ops-marketplace/memories/.health",
      "_note": "Idle until channels are configured; will extract profiles once wacli/gog are live."
    }
  }
}
JSON

# Remove the old standalone wacli keepalive if present
launchctl bootout gui/$(id -u)/com.claude-ops.wacli-keepalive 2>/dev/null || true
rm -f "$HOME/Library/LaunchAgents/com.claude-ops.wacli-keepalive.plist"

# Load daemon in background — does NOT block the wizard
launchctl bootout gui/$(id -u) "$PLIST_DEST" 2>/dev/null || true
launchctl bootstrap gui/$(id -u) "$PLIST_DEST"

Write daemon.enabled = true and daemon.installed_at_step = "2c" 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 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:

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: detect the host OS before suggesting installs

The claude-ops wizard runs on macOS, Linux (all major distros + WSL), and Windows (native + WSL). Before printing any install command, the skill MUST detect the host OS and pick the OS-appropriate variant. Never print a brew install … command to a Windows user, and never print winget install … to a macOS user.

Minimal detection snippet (bash — works on macOS, Linux, WSL, MSYS/Cygwin):

case "$(uname -s)" in
  Darwin*) OS=macos ;;
  Linux*)
    if grep -qi microsoft /proc/version 2>/dev/null; then OS=wsl
    elif [ -f /etc/os-release ]; then
      . /etc/os-release
      case "$ID" in
        arch|manjaro) OS=arch ;;
        fedora|rhel|centos|rocky|almalinux) OS=fedora ;;
        debian|ubuntu|pop|linuxmint) OS=debian ;;
        alpine) OS=alpine ;;
        opensuse*|sles) OS=suse ;;
        *) OS=linux ;;
      esac
    else OS=linux; fi ;;
  MINGW*|MSYS*|CYGWIN*) OS=windows ;;
  *) OS=unknown ;;
esac

Cascade for the package manager (pick the first one available):

1. brew (macOS + Linuxbrew) — preferred on macOS.
2. Native OS manager — apt-get (debian/ubuntu), dnf (fedora/rhel), pacman (arch), zypper (suse), apk (alpine).
3. winget (Windows 10 1809+) → scoop → choco → build-from-source as last resort on Windows.

When the preferred manager isn't installed, fall forward to the next available option rather than aborting the flow. Every AskUserQuestion "[Install now — …]" prompt below uses an OS-aware command table — print only the row(s) that match the detected OS.

For the authoritative cross-OS detection logic, reuse bin/ops-setup-detect (which emits os, pkg_mgr, arch, keyring_backend, shell, browser_profiles_found in its JSON output).

Shared: prefer OAuth over manual tokens

Whenever a channel has a browser-based OAuth flow available, offer that first and put manual-token entry behind it as a fallback. OAuth is safer (scoped, revocable, no secrets in dotfiles), and usually faster for the user.

When a channel supports OAuth, the default AskUserQuestion should lead with it:

[Connect via OAuth (recommended)]  [Enter a token manually]  [Skip]

Only go into the credential auto-scan flow below when the user picks "manually" or when the channel (Telegram, local tools) has no OAuth path.

Universal Credential Auto-Scan

BEFORE asking the user for ANY credential, run this scan sequence. This applies to ALL steps — channels, ecommerce, marketing, voice, and MCPs. The user should never be asked to find a key that's already on their system.

CRITICAL — exhaust ALL sources before reporting. Run every scan source (1-10 below) in a single batch, THEN analyze the combined results. Do NOT report "no credentials found" after checking only env vars and Dashlane — Chrome history, .env files, Doppler, and keychain may have the answer. If API tokens are missing but the store/service identity was found (e.g. store URL in Chrome history, login entry in Dashlane), report what you found and skip to the token step with the identity pre-filled. The user saying "find it" or "check all available sources" means you did not search thoroughly enough — never ask the user to look for something you can find programmatically.

For each variable name (e.g. TELEGRAM_BOT_TOKEN, SHOPIFY_ACCESS_TOKEN, KLAVIYO_API_KEY):

1. Current shell environment — printenv <VAR>. Running shell inherits exports, Doppler injections, dotenv-loaded files. Most likely to be correct.
2. Shell profile files — grep ~/.zshrc, ~/.bashrc, ~/.zprofile, ~/.config/fish/config.fish, ~/.envrc (direnv) for <VAR>= or export <VAR>=. Show the file path next to the value so the user knows where it's from.
3. Doppler (all projects) — if command -v doppler succeeds:

   for proj in $(doppler projects --json 2>/dev/null | jq -r '.[].slug'); do
     doppler secrets --project "$proj" --config prd --json 2>/dev/null | \
       jq -r --arg var "$VAR" --arg proj "$proj" \
       'to_entries[] | select(.key == $var) | "\(.value.computed) (doppler:\($proj)/prd)"'
   done
   

   Also try the default project config (dev/staging) if prd fails. Show source attribution (project: <slug>, config: <config>).
4. Dashlane CLI — if command -v dcli succeeds:

   dcli password "$SERVICE_KEYWORD" --output json 2>/dev/null
   

   Map service keywords: shopify → SHOPIFY vars, klaviyo → KLAVIYO vars, bland / bland-ai → BLAND vars, etc.
5. macOS Keychain — for specific services:

   security find-generic-password -s "$SERVICE" -w 2>/dev/null
   

   Use service names matching common patterns (e.g. shopify-admin-token, klaviyo-api-key, bland-ai-api-key).
6. OpenClaw config — if ~/.openclaw/openclaw.json exists:

   jq -r --arg var "$VAR" '.agents.defaults.env[$var] // empty' ~/.openclaw/openclaw.json 2>/dev/null
   

7. Installed MCP configs — read each .mcp.json the detector found. For each server entry, look at .env and .args for the variable name or for literal values that look like the target. Show the MCP server name as the source.
8. Plugin preferences — check existing $PREFS_PATH for the key under the relevant section (e.g. .ecom.shopify.admin_token, .marketing.klaviyo.api_key). If found and not a doppler: reference, show it as a source.
9. Chrome history — for services with web admin UIs (Shopify, Klaviyo, etc.), query Chrome's History SQLite DB for admin URLs that reveal the account/store identity:

   sqlite3 ~/Library/Application\ Support/Google/Chrome/Default/History \
     "SELECT DISTINCT url FROM urls WHERE url LIKE '%<service_domain>%' ORDER BY last_visit_time DESC LIMIT 10" 2>/dev/null
   

   Extract identifiers (e.g. *.myshopify.com store slugs, account IDs) from the URLs.
10. Project .env files — scan ~/Projects/*/.env* for the variable name or service domain patterns. These often contain credentials from other projects that can be reused.

Env var → service keyword mapping for auto-scan:

Present the findings with AskUserQuestion (max 4 options per call):

Found credential for SHOPIFY_ACCESS_TOKEN:
  [A] shell env + ~/.zshrc + Dashlane — shpat_508b...682e  (matched across 3 sources)
  [B] Doppler (project: mystore, config: prd) — shpat_9f2c...a17b  (different!)
  [C] Enter a different one

Rules for the prompt:

• Show the first 8 and last 4 characters of any token, never the full value.
• Always collapse matching sources into one option with (matched in env + ~/.zshrc + Dashlane) appended. This is critical to stay within the 4-option limit.
• If sources disagree, show each distinct value as a separate option. If there are more than 3 distinct values (rare), batch into multiple calls with [More sources...].
• Placeholder values like ${user_config.*}, <your-token>, CHANGE_ME, or empty strings count as NOT FOUND.
• Always include an [Enter a different one] option as the last option.
• If NO source has a value, present the user with options via AskUserQuestion:

<SERVICE_NAME> — no credential found after scanning all sources.

  [I have it — let me paste it]
  [Deep hunt — spawn an agent to find it]
  [Skip this service]

• "I have it" → show instructions for where to find the credential in the service's dashboard, then accept free-text input.

• "Deep hunt" → spawn a Haiku subagent in the background with this mandate:

  Find the <CREDENTIAL_NAME> for <SERVICE_NAME>. Search exhaustively:
  1. All Doppler projects and configs (dev/stg/prd/ci)
  2. All .env* files across ~/Projects/ recursively
  3. macOS Keychain (security find-generic-password with various service name patterns)
  4. Dashlane CLI (dcli password <service> + related keywords)
  5. Chrome browser — navigate to <service_admin_url> via Kapture/Playwright MCP, log in if needed, and extract the credential from the settings page
  6. All shell profile files (~/.zshrc, ~/.bashrc, ~/.zprofile, ~/.envrc, ~/.config/fish/*)
  7. 1Password CLI (op item list --tags <service>) if available
  8. AWS Secrets Manager / SSM Parameter Store if aws cli authenticated
  
  Return the credential value if found, or a detailed report of everywhere you checked and what you found (partial matches, expired tokens, wrong-format values).
  

  Use Agent(subagent_type: "general-purpose", model: "haiku") with run_in_background: true. Continue to the next service while the hunt runs. When the agent returns, present findings to the user for confirmation.

• "Skip" → record as skipped in $PREFS_PATH, move on.

On selection, use the chosen value as the source of truth and — with the user's consent — optionally propagate it back to the other sources (e.g. "Also update ~/.zshrc and Doppler to match?"). Default to NO for propagation unless the user opts in.

Shared: credential auto-scan

This section applies specifically to channel tokens (Telegram, Slack). For all other steps, see the Universal Credential Auto-Scan section above — the same pattern applies everywhere.

Before prompting the user to paste any token, scan for it using the Universal Credential Auto-Scan sequence above. Show the user what was found and ask them to confirm or override. Never silently use a token without confirmation.

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

Always ask before starting the Telegram flow — even when the user selected "all channels". Use AskUserQuestion:

Set up Telegram personal account access?
  [Yes — enter my phone number and authenticate]
  [Skip Telegram]

If the user skips, record channels.telegram = "skipped" in $PREFS_PATH and move on. Do NOT silently mark Telegram as unconfigured — the explicit skip prevents the status header from showing ○ telegram (no token) as an action item on subsequent runs.

Rate-limit guard: Before starting, check $PREFS_PATH for channels.telegram being an object with .status == "rate_limited" — use a type guard: if (channels.telegram | type) == "object" and .channels.telegram.status == "rate_limited" (jq: if (.channels.telegram | type) == "object" then .channels.telegram.status else "skipped" end). If retry_after is in the future, present the user with AskUserQuestion:

Telegram is rate-limited until [time]. What would you like to do?
  [Wait and retry after cooldown — re-run /ops:setup telegram after [time]]
  [Skip Telegram for now]

Do NOT attempt send_password during a rate-limit window — it will fail immediately and may extend the cooldown. If the user selects Skip, record the skip in $PREFS_PATH and move to the next channel.

Bots cannot read user DMs, so /ops-inbox telegram requires a personal-account MCP. The plugin ships bin/ops-telegram-autolink.mjs which:

1. Scans scout sources (keychain → ~/.claude.json → shell profiles → Doppler) for previously-extracted TELEGRAM_API_ID / TELEGRAM_API_HASH / TELEGRAM_SESSION.
2. If none found, makes plain HTTP requests to my.telegram.org (no browser — my.telegram.org uses server-side HTML, no JS required), logs in with a phone code from the bridge file, creates an app if needed, and extracts api_id + api_hash.
3. Runs gram.js client.start() to generate a session string, bridging the second code via the same file.
4. Emits final JSON on stdout: {api_id, api_hash, phone, session}.

Sub-flow (only runs if user selected Yes above):

1. Scout first. Check keychain for previously-extracted Telegram credentials:

   for svc in telegram-api-id telegram-api-hash telegram-phone telegram-session; do
     security find-generic-password -s "$svc" -w 2>/dev/null && echo "FOUND: $svc"
   done
   

   Also check ~/.claude.json mcpServers.telegram.env.TELEGRAM_API_ID. If all 4 are found and the stored TELEGRAM_SESSION decodes as a StringSession, tell the user "✓ Telegram already configured (api_id=XXXXXXX, phone=+XX...)" and skip to step 8.

2. Ask the user for their phone number via AskUserQuestion with a single free-text option. Do NOT offer country-specific presets or example numbers — just one option that prompts for direct input:

   Enter your Telegram phone number (include country code, e.g. +31612345678):
     [Enter phone number — type your full number starting with +]
   

   The user will select this option and type their number in the "Other" free-text field. Validate it matches ^\+\d{7,15}$. Explain that the phone is only used once during the first-run extraction and is stored locally only.

3. Warn about 2 codes. Inform the user via AskUserQuestion: "Telegram will send TWO codes to your Telegram app — one for my.telegram.org web login, then a second one for gram.js auth. Have your Telegram app ready." Options: [I'm ready], [Cancel].

4. Spawn the autolink script in the background with restrictive file perms:

   (umask 077 && node "${CLAUDE_PLUGIN_ROOT}/bin/ops-telegram-autolink.mjs" --phone "$PHONE" 2>/tmp/ops-telegram-autolink.log 1>/tmp/ops-telegram-autolink.out &)
   echo $! > /tmp/ops-telegram-autolink.pid
   

   Use the Bash tool's run_in_background: true. The umask 077 creates all bridge files (log, out) with mode 0600. The .out file contains the full credential JSON including the gram.js session string — if it's world-readable, any local process can exfiltrate long-lived Telegram account access.

5. Poll the stderr log for need_code events. Every 3 seconds, read /tmp/ops-telegram-autolink.log and look for the most recent {"type":"need_code", ...} line that hasn't been answered yet. When you see one:

   • Determine which code: channel: "web_login" (first) or channel: "gram_auth" (second).
   • Use AskUserQuestion with a free-text input: "Enter the code Telegram just sent to your Telegram app:". Do NOT say "digits only" — Telegram web login codes can contain letters, hyphens, and underscores (e.g. Zv_-ef77YSU). The autolink's bridge file accepts any 3-20 character alphanumeric+hyphen+underscore string.
   • Write the code to /tmp/telegram-code.txt with restrictive perms: Bash: (umask 077 && printf '%s' "$CODE" > /tmp/telegram-code.txt). The umask 077 is critical — without it the file is created world-readable on macOS (where /tmp is drwxrwxrwt) and any local process can race to read the code during the 2s poll window.
   • Verify the code was consumed within 10 seconds: ls /tmp/telegram-code.txt 2>/dev/null. If the file still exists after 10s, the script's validation regex rejected the code. Read the log for errors. Do NOT re-run the script or request a new code — that burns a login attempt.
   • Wait for the next event.
   • If you see {"type":"need_password"}, handle 2FA: ask the user via AskUserQuestion and write to /tmp/telegram-password.txt with (umask 077 && printf '%s' "$PW" > /tmp/telegram-password.txt). Same perm hardening as the code file. The 2FA password is far more sensitive than a one-time code.

6. Wait for the script to exit. Poll until the process is no longer running (ps -p "$(cat /tmp/ops-telegram-autolink.pid)"). Read /tmp/ops-telegram-autolink.out — it should contain a single JSON line with api_id, api_hash, phone, and session. Security note: the setup skill should have dispatched the autolink with (umask 077 && node "${CLAUDE_PLUGIN_ROOT}/bin/ops-telegram-autolink.mjs" --phone "$PHONE" 2>/tmp/ops-telegram-autolink.log 1>/tmp/ops-telegram-autolink.out &) so the .log and .out files get 0600 mode. Verify with stat -f '%Lp' /tmp/ops-telegram-autolink.out → must print 600. Immediately shred -u (Linux) or

…(truncated)