Flow Deliver

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}}

Pre-Delivery: State Check

Before starting delivery:

1. Read .octo/STATE.md to verify Develop phase complete
2. Update STATE.md:
   • current_phase: 4
   • phase_position: "Delivery"
   • status: "in_progress"

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

# Update state for Delivery phase
"${HOME}/.claude-octopus/plugin/scripts/octo-state.sh" update_state \
  --phase 4 \
  --position "Delivery" \
  --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:

• Document terms: "report", "presentation", "PRD", "proposal", "document", "brief"
• Quality terms: "argument", "evidence", "clarity", "completeness", "narrative"

Dev Context Indicators:

• Code terms: "code", "implementation", "API", "endpoint", "function", "module"
• Quality terms: "security", "performance", "tests", "coverage", "bugs"

Also check: What is being reviewed? Code files -> Dev, Documents -> Knowledge

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 validation criteria into the review prompt. Append the matching validation supplement after the user's prompt when calling orchestrate.sh in Step 4.

How to apply: When calling orchestrate.sh in Step 4, append the validation supplement:

orchestrate.sh deliver "<user prompt>\n\nDomain-specific validation criteria:\n<supplement text>"

DO NOT PROCEED TO STEP 2 until context determined. Context type (Dev vs Knowledge) and dev subtype determine which validation supplements to inject — wrong context produces a review that checks irrelevant criteria.

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 validation mode
✅ [Dev] Deliver Phase: [Brief description of code review]

Provider Availability:
🔴 Codex CLI: [Available ✓ / Not installed ✗] - Code quality analysis
🟡 Antigravity CLI: [Available ✓ / Not installed ✗] - Security and edge cases
🧭 Antigravity CLI: [Available ✓ / Not installed ✗] - Additional external-model challenge
🔵 Claude: Available ✓ - Synthesis and recommendations

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

For Knowledge Context:

🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider validation mode
✅ [Knowledge] Deliver Phase: [Brief description of document review]

Provider Availability:
🔴 Codex CLI: [Available ✓ / Not installed ✗] - Structure and logic analysis
🟡 Antigravity CLI: [Available ✓ / Not installed ✗] - Content quality and completeness
🧭 Antigravity CLI: [Available ✓ / Not installed ✗] - Additional external-model challenge
🔵 Claude: Available ✓ - Synthesis and recommendations

💰 Estimated Cost: 0.02-0.08 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 full project 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-deliver" "deliver"

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

# Get context from all prior 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")
develop_context=$("${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" get_context "develop")

# Display what you found (validation needs full context)
echo "📋 Validation Context Summary:"

if [[ "$discover_context" != "null" ]]; then
  echo "  Discovery: $discover_context"
fi

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

if [[ "$develop_context" != "null" ]]; then
  echo "  Development: $develop_context"
fi

if [[ "$prior_decisions" != "[]" && "$prior_decisions" != "null" ]]; then
  echo "  Decisions to validate against:"
  echo "$prior_decisions" | jq -r '.[] | "    - \(.decision) (\(.phase))"'
fi

This provides full context for validation:

• Requirements and scope (from define phase)
• Implementation decisions (from develop phase)
• Research findings (from discover phase)
• All architectural decisions to validate against
• If claude-mem is installed, its MCP tools (search, timeline, get_observations) are available — use them to check for past delivery issues or quality patterns

DO NOT PROCEED TO STEP 4 until state read.

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

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

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

CRITICAL: You are PROHIBITED from:

• ❌ Reviewing directly without calling orchestrate.sh — adversarial multi-AI review catches blind spots that a single reviewer misses; Codex finds code quality issues while Antigravity catches security and edge cases
• ❌ Doing single-perspective analysis instead of multi-provider
• ❌ 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):

• 🔴 Analyzing code quality and patterns (Codex)...
• 🟡 Validating security and edge cases (Antigravity)...

Phase 2 - Synthesis (Sequential):

• 🔵 Synthesizing validation results...

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 validation file (created within last 10 minutes)
VALIDATION_FILE=$(find ~/.claude-octopus/results -name "ink-validation-*.md" -mmin -10 2>/dev/null | head -n1)

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

echo "✅ VALIDATION PASSED: $VALIDATION_FILE"
cat "$VALIDATION_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 review — fallback to single-model review defeats the adversarial multi-provider validation that catches blind spots

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

After validation is complete, record final metrics:

# Update deliver phase context with validation summary
validation_summary=$(head -30 "$VALIDATION_FILE" | grep -A 2 "## Summary\|Pass\|Fail" | tail -2 | tr '\n' ' ')

"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" update_context \
  "deliver" \
  "$validation_summary"

# Update final metrics (completion of full workflow)
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" update_metrics "phases_completed" "1"

# Display final state summary
echo ""
echo "📊 Session Complete - Final Metrics:"
"${HOME}/.claude-octopus/plugin/scripts/state-manager.sh" show_summary

DO NOT PROCEED TO STEP 7 until state updated.

STEP 7: Present Validation Report & Post to PR (Only After Steps 1-6 Complete)

Read the validation file and present:

• Overall status (✅ PASSED / ⚠️ PASSED WITH WARNINGS / ❌ FAILED)
• Quality score (XX/100)
• Summary
• Critical issues (must fix)
• Warnings (should fix)
• Recommendations (nice to have)
• Validation details from all providers
• Quality gates results
• Next steps

Include attribution:

*Multi-AI Validation powered by Claude Octopus*
*Providers: available external providers + 🔵 Claude*
*Full validation report: $VALIDATION_FILE*

Post to PR (v8.44.0)

After presenting the report, check if the current branch has an open PR and post the validation summary as a PR comment:

CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "")
PR_NUM=""

if [[ -n "$CURRENT_BRANCH" && "$CURRENT_BRANCH" != "main" && "$CURRENT_BRANCH" != "master" ]]; then
    if command -v gh &>/dev/null; then
        PR_NUM=$(gh pr list --head "$CURRENT_BRANCH" --json number --jq '.[0].number' 2>/dev/null || echo "")
    fi
fi

if [[ -n "$PR_NUM" ]]; then
    # Extract summary section from validation file for PR comment
    REVIEW_SUMMARY=$(head -60 "$VALIDATION_FILE")

    REPO_SLUG=$(gh repo view --json nameWithOwner --jq .nameWithOwner)
    COMMENT_BODY="## Deliver Phase — Validation Report

${REVIEW_SUMMARY}

___
*Multi-AI validation by Claude Octopus (/octo:deliver)*
*Providers: available external providers + 🔵 Claude*"
    if ! "${CLAUDE_PLUGIN_ROOT:-${HOME}/.claude-octopus/plugin}/scripts/safe-gh-comment.sh" \
            --repo "$REPO_SLUG" pr-comment "$PR_NUM" - <<< "$COMMENT_BODY"; then
        echo "GitHub write state is unknown; check for the validation report before retrying:" >&2
        gh pr view "$PR_NUM" --repo "$REPO_SLUG" --comments || true
        return 1 2>/dev/null || exit 1
    fi

    echo "Validation report posted to PR #${PR_NUM}"

    # Update agent registry
    REGISTRY="${HOME}/.claude-octopus/plugin/scripts/agent-registry.sh"
    if [[ -x "$REGISTRY" ]]; then
        AGENT_ID="$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "")"
        "$REGISTRY" update "$AGENT_ID" --pr "$PR_NUM" 2>/dev/null || true
    fi
fi

Behavior:

• Auto-posts when running inside /octo:embrace or /octo:factory
• When running standalone via /octo:deliver, asks user first:

  "PR #N found. Post validation report as a PR comment?"
  Options: "Yes, post to PR", "No, terminal only"

• If no PR or gh CLI unavailable, skips silently

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

• Document terms: "report", "presentation", "PRD", "proposal", "document", "brief"
• Quality terms: "argument", "evidence", "clarity", "completeness", "narrative"

Dev Context Indicators (in prompt):

• Code terms: "code", "implementation", "API", "endpoint", "function", "module"
• Quality terms: "security", "performance", "tests", "coverage", "bugs"

Also check: What is being reviewed? Code files -> Dev, Documents -> Knowledge

Step 1b: Detect Dev Subtype — see EXECUTION CONTRACT Step 1b above for subtype table and validation 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 validation mode
✅ [Dev] Deliver Phase: [Brief description of code review]
📋 Session: ${CLAUDE_SESSION_ID}

Providers:
🔴 Codex CLI - Code quality analysis
🟡 Antigravity CLI - Security and edge cases
🔵 Claude - Synthesis and recommendations

For Knowledge Context:

🐙 **CLAUDE OCTOPUS ACTIVATED** - Multi-provider validation mode
✅ [Knowledge] Deliver Phase: [Brief description of document review]
📋 Session: ${CLAUDE_SESSION_ID}

Providers:
🔴 Codex CLI - Structure and logic analysis
🟡 Antigravity CLI - Content quality and completeness
🔵 Claude - Synthesis and recommendations

{{VISUAL_INDICATORS}}

Part of Double Diamond: DELIVER (convergent thinking)

        DELIVER (ink)

         \         /
          \       /
           \     /
            \   /
             \ /

          Converge to
           delivery

What This Workflow Does

The deliver phase validates and reviews implementations using external CLI providers:

1. 🔴 Codex CLI - Code quality, best practices, technical correctness
2. 🟡 Antigravity CLI - Security audit, edge cases, user experience
3. 🔵 Claude (You) - Synthesis and final validation report

This is the convergent phase for delivery - we ensure quality before shipping.

When to Use Deliver

Use deliver when you need:

Dev Context Examples

• Code Review: "Review the authentication implementation"
• Security Audit: "Check for security vulnerabilities in auth.ts"
• Quality Validation: "Validate the API endpoints are production-ready"
• Implementation Verification: "Verify the caching layer works correctly"
• Pre-Deployment Check: "Ensure the feature is ready to ship"

Knowledge Context Examples

• Document Review: "Review the PRD for completeness"
• Presentation Validation: "Check the executive presentation for clarity"
• Report Quality Check: "Validate the market analysis report"
• Proposal Review: "Review the business case for stakeholder readiness"
• Content Audit: "Ensure the strategy document is actionable"

Don't use deliver for:

• Building implementations (use develop-workflow)
• Research and exploration (use discover-workflow)
• Requirement definition (use define-workflow)
• Simple code/document reading (use Read tool)