Flow Develop

Host: Codex CLI — This skill was designed for Claude Code and adapted for Codex. Cross-reference commands use installed skill names in Codex rather than /octo:* slash commands. Use the active Codex shell and subagent tools. Do not claim a provider, model, or host subagent is available until the current session exposes it. For host tool equivalents, see skills/blocks/codex-host-adapter.md.

{{PREAMBLE}}

Load skills/blocks/engineering-method-selection.md from the installed plugin and apply only the methods relevant to this task. Preserve this entry point's execution contract and output format. Read referenced skills as instructions; do not invoke the current command recursively or add provider calls from a seat.

Portable feature boundary

Before implementation, select the existing feature and run its boundary adapter:

OCTO_ROOT="${CLAUDE_PLUGIN_ROOT:-${HOME}/.claude-octopus/plugin}"
bash "$OCTO_ROOT/scripts/helpers/feature-workflow.sh" boundary develop "${OCTOPUS_FEATURE:-}"

Read the bound project policy, relative source and digest. Ask the returned marker batch once through the available native host question tool. Keep skipped or noninteractive decisions open. Report the open count and defer only tasks whose current contract depends on a named unanswered decision. The runtime repeats these checks before actual task dispatch.

Two or more spec/plan/tasks artifacts trigger deterministic analysis automatically. A clean pass uses no extra model seat. Unresolved findings can trigger at most one independent bounded seat, shared across host and runtime for that artifact revision. Unavailable or failed semantic review warns and proceeds. Analysis reports exact source quotations and never rewrites artifacts.

Use stable task IDs and metadata when present. The parent resolves paths, dependencies and current Git state at every wave. A hint cannot grant concurrency or permit overwriting user changes. Legacy inputs retain their existing planner and execution path.

Pre-Development: State Check

Before starting development:

1. Read .octo/STATE.md to verify Define phase complete
2. Update STATE.md:
   • current_phase: 3
   • phase_position: "Development"
   • status: "in_progress"

# Verify Define phase is complete
if [[ -f ".octo/STATE.md" ]]; then
  define_status=$("${HOME}/.claude-octopus/plugin/scripts/octo-state.sh" get_phase_status 2)
  if [[ "$define_status" != "complete" ]]; then
    echo "⚠️ Warning: Define phase not marked complete. Consider running definition first."
  fi
fi

# Update state for Development phase
"${HOME}/.claude-octopus/plugin/scripts/octo-state.sh" update_state \
  --phase 3 \
  --position "Development" \
  --status "in_progress"

⚠️ EXECUTION CONTRACT (MANDATORY - CANNOT SKIP)

This skill uses ENFORCED execution mode. You MUST follow this exact sequence.

STEP 1: Detect Work Context (MANDATORY)

Analyze the user's prompt and project to determine context:

Knowledge Context Indicators:

• Deliverable terms: "PRD", "proposal", "presentation", "report", "strategy document", "business case"
• Business terms: "market entry", "competitive analysis", "stakeholder", "executive summary"

Dev Context Indicators:

• Technical terms: "API", "endpoint", "function", "module", "service", "component"
• Action terms: "implement", "code", "build", "create", "develop" + technical noun

Also check: Does project have package.json, Cargo.toml, etc.? (suggests Dev Context)

Capture context_type = "Dev" or "Knowledge"

Step 1b: Detect Dev Subtype (if Dev context)

When context_type is Dev, determine the subtype to inject domain-appropriate quality guidance into the prompt sent to providers. Append the matching supplement text after the user's prompt.

frontend-ui enrichment

When frontend-ui subtype is detected, do TWO things:

A. Inject quality supplement into the prompt: Self-contained files preferred. Accessibility: ARIA labels, keyboard nav, 44px touch targets (WCAG 2.5.5). Safe DOM: createElement over innerHTML. Progressive enhancement: feature-detect APIs (navigator.share, localStorage) with fallbacks. Persist user prefs via localStorage.

B. Pull design intelligence from BM25 (if available):

Before calling orchestrate.sh, check if the design intelligence engine exists and query it for relevant design context:

SEARCH_PY="${HOME}/.claude-octopus/plugin/vendors/ui-ux-pro-max-skill/src/ui-ux-pro-max/scripts/search.py"
if [[ -f "$SEARCH_PY" ]]; then
    # Detect relevant domains from the prompt
    design_context=""
    # Style query — what visual style fits this task?
    style_hit=$(python3 "$SEARCH_PY" "<user's task description>" --domain style --top 1 2>/dev/null || true)
    [[ -n "$style_hit" ]] && design_context+="Design style suggestion: $style_hit\n"
    # UX query — relevant UX patterns
    ux_hit=$(python3 "$SEARCH_PY" "<user's task description>" --domain ux --top 1 2>/dev/null || true)
    [[ -n "$ux_hit" ]] && design_context+="UX pattern: $ux_hit\n"
    # Append to prompt if hits found
    if [[ -n "$design_context" ]]; then
        # Append design intelligence to the orchestrate.sh prompt
        prompt="${prompt}\n\nDesign intelligence (from BM25 search):\n${design_context}"
    fi
fi

This gives providers concrete design guidance (style direction, UX patterns) without requiring the user to run /octo:design-ui-ux separately. If the search engine isn't installed, implementation proceeds with the quality supplement only.

How to apply: When calling orchestrate.sh in Step 4, append the quality supplement (and design intelligence if available) to the prompt:

orchestrate.sh develop "<user prompt>\n\nQuality requirements for this deliverable:\n<supplement text>\n<design intelligence if found>"

DO NOT PROCEED TO STEP 2 until context determined. Context type (Dev vs Knowledge) and dev subtype determine which quality supplements and design intelligence to inject — wrong context wastes provider credits on irrelevant analysis.

STEP 2: Display Visual Indicators (MANDATORY - BLOCKING)

MANDATORY: You MUST use the native shell command tool to run this provider check BEFORE displaying the banner. Do NOT skip it. Do NOT assume availability.

bash "${HOME}/.claude-octopus/plugin/scripts/helpers/check-providers.sh"

Use the ACTUAL results below. PROHIBITED: Showing only "🔵 Claude: Available ✓" without listing all providers.

If OCTO_ALLOWED_PROVIDERS is set, treat it as the source of truth for which providers may participate. Providers filtered out by that allowlist are intentionally reported as unavailable; do not invoke or recommend them in the workflow.

Display this banner BEFORE orchestrate.sh execution:

For Dev Context:

🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider implementation mode
🛠️ [Dev] Develop Phase: [Brief description of what you're building]

Provider Availability:
🔴 Codex CLI: ${codex_status} - Code generation and patterns
🟡 Antigravity CLI: ${agy_status} - Alternative approaches
🧭 Antigravity CLI: ${agy_status} - Additional external-model challenge
🔵 Claude: Available ✓ - Integration and quality gates

💰 Estimated Cost: 0.02-0.10 USD
⏱️  Estimated Time: 3-7 minutes

For Knowledge Context:

🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider implementation mode
🛠️ [Knowledge] Develop Phase: [Brief description of deliverable]

Provider Availability:
🔴 Codex CLI: ${codex_status} - Structure and framework application
🟡 Antigravity CLI: ${agy_status} - Content and narrative development
🧭 Antigravity CLI: ${agy_status} - Additional external-model challenge
🔵 Claude: Available ✓ - Integration and quality review

💰 Estimated Cost: 0.02-0.10 USD
⏱️  Estimated Time: 3-7 minutes

DO NOT PROCEED TO STEP 3 until banner displayed. The banner shows users which providers will run and what costs they'll incur — starting API calls without this visibility violates cost transparency.

STEP 3: Read Prior State (MANDATORY - State Management)

Before executing the workflow, read any prior context:

# Initialize state if needed
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" init_state

# Set current workflow
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" set_current_workflow "flow-develop" "develop"

# Get prior decisions (critical for implementation)
prior_decisions=$("${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" get_decisions "all")

# Get context from discover and define phases
discover_context=$("${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" get_context "discover")
define_context=$("${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" get_context "define")

# Display what you found (if any)
if [[ "$discover_context" != "null" ]]; then
  echo "📋 Discovery phase findings:"
  echo "  $discover_context"
fi

if [[ "$define_context" != "null" ]]; then
  echo "📋 Definition phase scope:"
  echo "  $define_context"
fi

if [[ "$prior_decisions" != "[]" && "$prior_decisions" != "null" ]]; then
  echo "📋 Implementing with decisions:"
  echo "$prior_decisions" | jq -r '.[] | "  - \(.decision) (\(.phase)): \(.rationale)"'
fi

This provides critical context for implementation:

• Technology stack and patterns decided
• Scope and requirements defined
• Research findings to inform implementation
• If claude-mem is installed, its MCP tools (search, timeline, get_observations) are available — use them to check for related past implementation patterns

DO NOT PROCEED TO STEP 4 until state read.

STEP 4: Execute orchestrate.sh develop (MANDATORY - Use Bash Tool)

You MUST execute this command via the native shell command tool:

${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh develop "<user's implementation request>"

CRITICAL: You are PROHIBITED from:

• ❌ Implementing directly without calling orchestrate.sh — single-model implementation misses alternative approaches and edge cases that external providers surface through independent analysis
• ❌ Writing code without multi-provider perspectives
• ❌ Claiming you're "simulating" the workflow
• ❌ Proceeding to Step 4 without running this command

You MUST use the native shell command tool to invoke orchestrate.sh.

What Users See During Execution (v7.16.0+)

If running in Claude Code v2.1.16+, users will see real-time progress indicators in the task spinner:

Phase 1 - External Provider Execution (Parallel):

• 🔴 Generating code and patterns (Codex)...
• 🟡 Exploring alternative approaches (Antigravity)...

Phase 2 - Synthesis (Sequential):

• 🔵 Integrating and applying quality gates...

These spinner verb updates happen automatically - orchestrate.sh calls update_task_progress() before each agent execution. Users see exactly which provider is working and what it's doing.

If NOT running in Claude Code v2.1.16+: Progress indicators are silently skipped, no errors shown.

STEP 5: Verify Execution (MANDATORY - Validation Gate)

After orchestrate.sh completes, verify it succeeded:

# Find the latest synthesis file (created within last 10 minutes)
SYNTHESIS_FILE=$(find ~/.claude-octopus/results -name "tangle-synthesis-*.md" -mmin -10 2>/dev/null | head -n1)

if [[ -z "$SYNTHESIS_FILE" ]]; then
  echo "❌ VALIDATION FAILED: No synthesis file found"
  echo "orchestrate.sh did not execute properly"
  exit 1
fi

echo "✅ VALIDATION PASSED: $SYNTHESIS_FILE"
cat "$SYNTHESIS_FILE"

If validation fails:

1. Report error to user
2. Show logs from ~/.claude-octopus/logs/
3. DO NOT proceed with presenting results
4. DO NOT substitute with direct implementation — fallback to single-model implementation skips the multi-provider synthesis that catches design flaws early

STEP 6: Update State (MANDATORY - Post-Execution)

After synthesis is verified, record implementation details in state:

# Extract key implementation decisions from synthesis
implementation_approach=$(head -50 "$SYNTHESIS_FILE" | grep -A 3 "## Implementation\|## Approach" | tail -3 | tr '\n' ' ')

# Record implementation decisions
decision_made=$(echo "$implementation_approach" | grep -o "implemented\|using [A-Za-z0-9 ]*\|chose to\|pattern:" | head -1)

if [[ -n "$decision_made" ]]; then
  "${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" write_decision \
    "develop" \
    "$decision_made" \
    "Multi-AI implementation consensus"
fi

# Update develop phase context
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" update_context \
  "develop" \
  "$implementation_approach"

# Update metrics
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" update_metrics "phases_completed" "1"

DO NOT PROCEED TO STEP 7 until state updated.

STEP 7: Present Implementation Plan (Only After Steps 1-6 Complete)

Read the synthesis file and present:

• Recommended approach
• Implementation steps
• Code overview from all available perspectives
• Quality gates results
• Request user confirmation before implementing

After user confirms: Implement the solution using Write/Edit tools

Include attribution:

*Multi-AI Implementation powered by Claude Octopus*
*Providers: available external providers + 🔵 Claude*
*Full implementation plan: $SYNTHESIS_FILE*

Develop Workflow - Develop Phase 🛠️

⚠️ MANDATORY: Context Detection & Visual Indicators

BEFORE executing ANY workflow actions, you MUST:

Step 1: Detect Work Context

Analyze the user's prompt and project to determine context:

Knowledge Context Indicators (in prompt):

• Deliverable terms: "PRD", "proposal", "presentation", "report", "strategy document", "business case"
• Business terms: "market entry", "competitive analysis", "stakeholder", "executive summary"

Dev Context Indicators (in prompt):

• Technical terms: "API", "endpoint", "function", "module", "service", "component"
• Action terms: "implement", "code", "build", "create", "develop" + technical noun

Also check: Does the project have package.json, Cargo.toml, etc.? (suggests Dev Context)

Step 1b: Detect Dev Subtype — see EXECUTION CONTRACT Step 1b above for subtype table and quality supplements. Append the matching supplement to the prompt before calling orchestrate.sh.

Step 2: Output Context-Aware Banner

For Dev Context:

🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider implementation mode
🛠️ [Dev] Develop Phase: [Brief description of what you're building]
📋 Session: ${CLAUDE_SESSION_ID}

Providers:
🔴 Codex CLI - Code generation and patterns
🟡 Antigravity CLI - Alternative approaches
🔵 Claude - Integration and quality gates

For Knowledge Context:

🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider implementation mode
🛠️ [Knowledge] Develop Phase: [Brief description of deliverable]
📋 Session: ${CLAUDE_SESSION_ID}

Providers:
🔴 Codex CLI - Structure and framework application
🟡 Antigravity CLI - Content and narrative development
🔵 Claude - Integration and quality review

{{VISUAL_INDICATORS}}

Part of Double Diamond: DEVELOP (divergent thinking)

       DEVELOP (tangle)

        \         /
         \   *   /
          \ * * /
           \   /
            \ /

       Diverge with
        solutions

What This Workflow Does

The develop phase generates multiple implementation approaches using external CLI providers:

1. 🔴 Codex CLI - Implementation-focused, code generation, technical patterns
2. 🟡 Antigravity CLI - Alternative approaches, edge cases, best practices
3. 🔵 Claude (You) - Integration, refinement, and final implementation

This is the divergent phase for solutions - we explore different implementation paths before converging on the best approach.

When to Use Develop

Use develop when you need:

Dev Context Examples

• Feature Implementation: "Build a user authentication system"
• Code Generation: "Create an API endpoint for user registration"
• Complex Builds: "Implement a caching layer with Redis"
• Architecture Implementation: "Create a microservice for payment processing"
• Integration Work: "Integrate Stripe payment processing"