/auto

command: auto
disable-model-invocation: true
description: Smart router - Single entry point with natural language intent detection
version: 3.0.0
category: workflow
tags: [router, intent-detection, workflow, smart-routing]
created: 2025-02-03
updated: 2026-03-12

Smart Router (/octo:auto)

Single entry point for all Claude Octopus workflows. Analyzes your natural language request and routes to the optimal workflow automatically.

/octo:auto research OAuth authentication patterns
/octo:auto debug the failing test in auth.ts
/octo:auto should we use Redis or Memcached?
/octo:auto write tests for the payment module
/octo:auto create a complete e-commerce platform

All `/octo:*` commands also work directly, bypassing the router.

Premium automatic peer check

When Premium mode is active, eligible single-owner implementation, review, design, copywriting, and general work receives one automatic cross-provider peer check after the owner returns a result. Users do not need a flag or a second command. Budget and Standard modes do not add this call.

Octopus skips the extra check for quick or direct requests, setup and status work, image and research routes, and workflows that already run councils, debates, crossfire, parallel work, or a full review. Explicit provider/model pins and provider restrictions still win. Set `OCTOPUS_PREMIUM_PEER_CHECK=off` to disable only this automatic addition.

The peer receipt records whether the bounded result review completed. A peer response is advisory and does not prove correctness.

---

EXECUTION CONTRACT (Mandatory)

When the user invokes `/octo:auto <query>` or says `octo <query>`, you MUST use the native path below. The detailed routing table later in this file is reference material for the shared runtime, not a second classifier.

NATIVE PATH: SINGLE AUTHORITATIVE ROUTER

For every non-meta request, pass the complete original query to the shared automatic runtime before doing any local intent matching:

OCTO_ROOT="${CLAUDE_PLUGIN_ROOT:-${HOME}/.claude-octopus/plugin}"
bash "${OCTO_ROOT}/scripts/orchestrate.sh" auto "<full original query>"

Treat the runtime's task classification and selected workflow as authoritative. If it reports Direct mode, continue handling the original request natively in the current Claude Code conversation. If it dispatches an external or parallel workflow, let that workflow complete and do not start a second route. If it reports a Native workflow request, load the named installed command and follow that command's contract in the current conversation. Do not continue to STEP 1 or choose a different route. This avoids two classifiers choosing different workflows and keeps Premium peer policy at the workflow root.

For `help`, `list`, and `capabilities`, run the provider-free installed catalog with `bash "${OCTO_ROOT}/scripts/orchestrate.sh" guide list`. Do not use a remembered command list or initialize a workflow.

ROUTING REFERENCE (not a second execution path)

The following steps document the intent categories used by the runtime. They must not be executed separately by a native `/octo:auto` invocation.

STEP 1: Input Validation

If the query exceeds 500 characters, use only the first 500 characters for intent analysis. Pass the full original query to the shared runtime.

STEP 2: Meta Command Check

If the query matches any of: `help`, `list`, `commands`, `what can you do`, `capabilities`, `options`, `workflows`:

• Show the installed catalog through `guide list` and STOP. Do not route.

STEP 3: Analyze Intent

Match the query against keywords below. Check categories **in priority order** — higher priority wins when intents conflict.

Priority 1 — Specialized Workflows (check first, highest specificity)

Explicit multi-provider requests and security intent retain their priority. For other requests, resolve prototype intent before the keyword table: an engineering experiment to measure feasibility, throughput, compatibility or a technical assumption routes to `octo:plan` for its bounded prototype proposal. A screen, wireframe or interaction prototype routes to `octo:design-ui-ux`. Use the full request's context; for an ambiguous "prototype" ask which outcome is intended.

| Intent | Trigger Keywords | Routes To | |--------|-----------------|-----------| | Lifecycle | end-to-end, complete lifecycle, full workflow, entire project, whole system | `octo:embrace` | | Multi-LLM | multi, multi-llm, multi-provider, all providers, force multi, cross-model | `octo:multi` | | Parallel | parallel, team of teams, decompose, work packages, split into | `octo:parallel` | | Specification | spec, nlspec, specification, requirements doc, define scope, write spec | `octo:spec` | | Security | security audit, OWASP, vulnerability, pentest, threat model, CVE, attack surface | `octo:security` | | TDD | TDD, test-driven, write tests, test first, unit test, test coverage | `octo:tdd` | | Debug | debug, fix bug, troubleshoot, broken, error trace, stacktrace, failing, crash | `octo:debug` | | Design | UI design, UX design, wireframe, mockup, design system, layout, UI prototype | `octo:design-ui-ux` | | PRD | PRD, product requirements, product spec, feature requirements | `octo:prd` | | Brainstorm | brainstorm, ideate, ideas, creative, thought experiment, what if | `octo:brainstorm` | | Deck | presentation, slides, deck, pitch deck, slide deck | `octo:deck` | | Docs | document, documentation, README, API docs, write docs, docstring | `octo:docs` |

Priority 2 — Core Workflows

| Intent | Trigger Keywords | Routes To | |--------|-----------------|-----------| | Research | research, investigate, explore, study, understand patterns, analyze ecosystem | `octo:discover` | | Review | validate, review code, check quality, audit code, inspect, verify, code review | `octo:review` | | Debate | should we, X vs Y, compare, versus, decide between, which is better, trade-off | `octo:debate` |

Priori