/flow-develop

name: flow-develop
description: "Multi-AI implementation using available external providers (Double Diamond Develop phase). DO NOT use for simple code edits, reading/reviewing code, built-in commands, or trivial single-file changes."
disable-model-invocation: true

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

Use the installation that loaded this skill for both execution and validation. If `CLAUDE_PLUGIN_ROOT` is absent, replace every `OCTO_ROOT` fallback in this skill with the absolute plugin root derived from this loaded skill's path. Do not infer it from the project directory or an existing stable link. The root helper refreshes installed copies while preserving another session's working root when called from an inferred development checkout.

OCTO_ROOT="${CLAUDE_PLUGIN_ROOT:-${CODEX_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=$("${CLAUDE_PLUGIN_ROOT:-${CODEX_PLUGIN_ROOT:-${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
"${CLAUDE_PLUGIN_ROOT:-${CODEX_PLUGIN_ROOT:-${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.

| Subtype | Trigger keywords | Quality supplement | |---------|-----------------|-------------------| | `frontend-ui` | "page", "widget", "component", "UI", "HTML", "CSS", "form", "dashboard", "layout" | See **frontend-ui enrichment** below. | | `cli-tool` | "CLI", "command-line", "terminal", "script", "flag", "argument" | Help text via --help flag. Meaningful exit codes (0 success, 1 user error, 2 system error). Stdin/stdout/stderr used correctly. Argument validation with clear error messages. | | `api-service` | "API", "endpoint", "REST", "GraphQL", "gRPC", "server", "route" | Input validation at boundaries. Consistent error response format. Auth/authz on every endpoint. Rate limiting consideration. OpenAPI/schema documentation. | | `infra` | "deploy", "terraform", "docker", "CI", "pipeline", "Kubernetes", "helm" | Idempotent operations. Secrets never hardcoded. Rollback path documented. Health checks included. | | `data` | "ETL", "pipeline", "migration", "schema", "database", "SQL" | Idempotent migrations. Backup/rollback strategy. Data validation at ingestion. | | `general` | Default if no subtype matches | No supplement — use base implementer persona only. |

frontend-ui enrichment

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

**A. Inject quality supplement into the prompt:** Self-contained files preferred. Accessibility: