**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.
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.
**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:**
๐ต 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:**
**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
- โ 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 Bash 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:
- ๐ก Exploring alternative approaches (Gemini)...
**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.
**After orchestrate.sh completes, verify it succeeded:**
```bash
# 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:**
```bash
# Extract key implementation decisions from synthesis
**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.
1. Call **Codex CLI** with the implementation task
2. Call **Gemini CLI** with the implementation task
3. You (Claude) contribute implementation analysis
4. Synthesize approaches and recommend best path
### Step 3: Review Quality Gates
The tangle phase includes automatic quality validation:
- Code quality checks
- Security scanning
- Best practice validation
- Implementation completeness
### Step 3b: Handle Agent Continuation (v9.5 / CC v2.1.77+)
When orchestrate.sh output contains `AGENT_TEAMS_RESUME:${agent_id}:${task_id}:${role}:${phase}`:
1. Send a message to the existing agent using `SendMessage({to: "${agent_id}", message: "<iteration prompt>"})` โ this auto-resumes a stopped agent automatically (CC v2.1.77+)
2. Read the iteration prompt from the resume instruction JSON at `~/.claude-octopus/agent-teams/${task_id}.json`
3. If SendMessage returns an error (agent GC'd or not found), fall back to creating a new agent with the full prompt from the instruction file
4. After the agent responds, store its agentId via: `bridge_store_agent_id(task_id, agent_id)` in the bridge ledger
Note: The `Agent(resume: ...)` parameter was removed in CC v2.1.77. Always use `SendMessage` for agent continuation.
## After Implementation: Auto Code Review & E2E Verification (MANDATORY)
**After implementation completes and before presenting results to the user, you MUST launch two verification agents in parallel.** Do NOT skip this step or ask the user whether to run it โ it is automatic.
### Launch both agents simultaneously:
**Agent 1 โ Code Review (Sonnet):**
```
Agent(
model: "sonnet",
subagent_type: "feature-dev:code-reviewer",
run_in_background: true,
description: "Code review: post-develop",
prompt: "Review the code changes from this development session. Focus on:
1. Bugs, logic errors, security vulnerabilities
2. Hidden dependencies or coupling issues
3. Whether error handling covers failure modes
4. Adherence to project conventions (check CLAUDE.md)
Check git diff for the changed files. Report only high-confidence issues."
)
```
**Agent 2 โ E2E Verification (Sonnet):**
```
Agent(
model: "sonnet",
run_in_background: true,
description: "E2E test: post-develop",
prompt: "Run end-to-end verification of the development changes:
1. Run the project's test suite (detect from package.json scripts, Makefile, or pyproject.toml)
2. Verify no regressions in existing tests
3. Check that new files are properly integrated (imported, registered, sourced)
4. Verify the implementation matches the original task requirements
Report: tests passed/failed, any integration issues found."
)
```
**After both agents complete:**
- Present their findings to the user as part of the results
- If the code reviewer found HIGH-confidence issues, flag them prominently
- If tests failed, flag before the "what next?" prompt
- Do NOT block on the review โ present findings alongside results
WHY: The user should never have to manually request a code review after development work. Fresh-eyes review from a different model (Sonnet vs Opus) catches issues the implementer is blind to. Running tests automatically catches regressions before the user discovers them.
---
## After Implementation Checklist
After writing code, ensure:
- [ ] All files created/updated
- [ ] Code follows recommended patterns from synthesis
- [ ] Code follows the project's existing commenting conventions (do not add comments unless asked or required by project style)
- [ ] Security concerns addressed
- [ ] Error handling implemented
- [ ] Tests written (if applicable)
- [ ] Lint/typecheck commands run (detect from package.json, pyproject.toml, Cargo.toml, Makefile; if not found, ask the user)
- [ ] If lint/test commands were discovered and not documented in CLAUDE.md, suggest adding them