embrace

# Embrace - Complete Double Diamond Workflow

**Your first output line MUST be:** `🐙 Octopus Embrace`

## MANDATORY COMPLIANCE — DO NOT SKIP

**When the user invokes `/octo:embrace`, you MUST execute the full multi-LLM workflow below. You are PROHIBITED from:**
- Deciding the task is "too simple" for the workflow
- Doing the task directly instead of running the phases
- Skipping phases because you judge them unnecessary
- Substituting your own approach for the structured workflow

**The user chose `/octo:embrace` deliberately.** Respect that choice.

## EXECUTION MECHANISM — NON-NEGOTIABLE

**Each phase MUST be executed through the `orchestrate.sh` entrypoint. Direct Skill calls for the workflow phases are not permitted because they can recursively reload command instructions. You are PROHIBITED from:**
- Using the Agent tool to do research yourself instead of running the discovery phase
- Using WebFetch/Read/Grep as a substitute for multi-provider research
- Implementing code directly instead of running the develop phase
- Using a single code-reviewer agent instead of running the deliver phase
- Skipping `orchestrate.sh` calls because "I can do this faster directly"

**The ENTIRE POINT of `/octo:embrace` is multi-LLM orchestration.** If you execute phases using only Claude-native tools (Agent, WebFetch, Write, Edit), you have violated the command's purpose even if you followed the phase structure.

**Self-check after completion:** You should be able to list the `orchestrate.sh` commands you ran. If you used only Claude-native tools, you executed incorrectly.

---

## Step 1: Ask Clarifying Questions

```javascript
AskUserQuestion({
  questions: [
    {
      question: "What's the scope of this project?",
      header: "Scope",
      multiSelect: false,
      options: [
        {label: "Small feature", description: "Single component or small addition"},
        {label: "Medium feature", description: "Multiple components or moderate complexity"},
        {label: "Large feature", description: "System-wide changes or new subsystem"},
        {label: "Full system", description: "Complete application or major architecture"}
      ]
    },
    {
      question: "What areas require the most attention?",
      header: "Focus Areas",
      multiSelect: true,
      options: [
        {label: "Architecture design", description: "System structure and design patterns"},
        {label: "Security", description: "Authentication, authorization, data protection"},
        {label: "Performance", description: "Speed, scalability, optimization"},
        {label: "User experience", description: "UI/UX and usability"}
      ]
    },
    {
      question: "What's your preferred level of autonomy?",
      header: "Autonomy",
      multiSelect: false,
      options: [
        {label: "Supervised (default)", description: "Review and approve after each phase"},
        {label: "Semi-autonomous", description: "Only intervene if quality gates fail"},
        {label: "Autonomous", description: "Run all 4 phases automatically"},
        {label: "Manual", description: "I'll guide each step explicitly"}
      ]
    },
    {
      question: "Should critical decisions be stress-tested with a Multi-LLM debate?",
      header: "Multi-LLM Debate Gates",
      multiSelect: false,
      options: [
        {label: "Yes — debate at Define→Develop gate", description: "Recommended for Large/Full scope"},
        {label: "Yes — debate at both gates", description: "Maximum rigor, uses external API credits"},
        {label: "No — skip debates", description: "Standard workflow without debate checkpoints"},
        {label: "Only if disagreement detected", description: "Auto-trigger when providers diverge"}
      ]
    }
  ]
})
```

After receiving answers, incorporate them into all subsequent phase invocations — use the scope to calibrate research depth, focus areas to weight provider perspectives, autonomy level to control phase transitions, and debate preference to gate handoffs.

Normalize the debate preference immediately:
- `DEBATE_GATES=define` for "Yes — debate at Define→Develop gate"
- `DEBATE_GATES=both` for "Yes — debate at both gates"
- `DEBATE_GATES=none` for "No — skip debates"
- `DEBATE_GATES=auto` for "Only if disagreement detected"

**Gate ledger invariant:** if `DEBATE_GATES=define`, a `embrace-gate-define-develop-*.md` artifact from the current run MUST exist before Phase 3 starts. If `DEBATE_GATES=both`, both `embrace-gate-define-develop-*.md` and `embrace-gate-develop-deliver-*.md` artifacts from the current run MUST exist before their next phases. Autonomy mode does not waive requested gates. If a requested gate command fails or produces no artifact, STOP and report the failed gate instead of continuing.

### Remote/Cloud Defaults

If `CLAUDE_CODE_REMOTE=true` or `OCTOPUS_REMOTE_SESSION=true`, do not block on clarifying questions. Use these defaults unless the user's prompt says otherwise:

- scope: infer from the prompt
- focus: all relevant areas
- autonomy: autonomous
- debate gates: only if provider disagreement is detected

Plan locally first, then run the approved `/octo:embrace` prompt in the hosted or remote-control session with `OCTOPUS_REMOTE_SESSION=true` set in that environment.

## Step 2: Check Provider Availability & Display Banner

**MANDATORY: Run this bash command BEFORE the banner.**

```bash
echo "PROVIDER_CHECK_START"
printf "codex:%s\n" "$(command -v codex >/dev/null 2>&1 && echo available || echo missing)"
printf "gemini:%s\n" "$(command -v gemini >/dev/null 2>&1 && echo available || echo missing)"
printf "perplexity:%s\n" "$([ -n "${PERPLEXITY_API_KEY:-}" ] && echo available || echo missing)"
printf "opencode:%s\n" "$(command -v opencode >/dev/null 2>&1 && echo available || echo missing)"
printf "copilot:%s\n" "$(command -v copilot >/dev/null 2>&1 && echo available || echo missing)"
printf "qwen:%s\n" "$(command -v qwen >/dev/null 2>&1 && echo available || echo missing)"
printf "ollama:%s