{{PREAMBLE}}
Pre-Development: State Check
Before starting development:
- Read
.octo/STATE.mdto verify Define phase complete - 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.
| 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: 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 Bash 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
🟡 Gemini CLI: ${gemini_status} - Alternative approaches
🧭 Antigravity CLI: ${agy_status} - Additional external-model challenge
🔵 Claude: Available ✓ - Integration and quality gates
💰 Estimated Cost: $0.02-0.10
⏱️ 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
🟡 Gemini CLI: ${gemini_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
⏱️ 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_c