do

# /do — Unified Intent Router

## Orientation

Use `/do` when the user wants something done but doesn't know (or care) which tool handles it.
**Don't use when:** you know the destination — invoke /marshal, /archon, /fleet, or any skill directly.

## Commands

| Command | Behavior |
|---|---|
| `/do [anything]` | Classify intent, route to cheapest capable path |
| `/do status` | Show full harness dashboard (/dashboard) |
| `/do next` | Run the decision-first operator console for the next useful harness action |
| `/do operator` | Show the operator console without executing repairs |
| `/do preview <request>` | Show exact resolution or generated candidates and their boundary without executing |
| `/do --route /skill -- <request>` | Use an explicit validated route without bypassing activation or safety boundaries |
| `/do continue` | Resolve and run the deterministic continuation action |
| `/do --list` | Show all skills grouped by category with trigger keywords |
| `/do setup` | First-run experience — configure the harness for this project |

## Protocol

Classification runs top-to-bottom. Exact commands resolve first. Natural-language requests use keyword matches only as candidate evidence for semantic classification.

### Step 0: Skill Registry Check (Cost: ~0 on hit | ~50 tokens on miss)

Compare installed skill directories with `core/skills/routing-table.json`. If they
match, continue without reading skill bodies. For each unknown skill, read only
its frontmatter and use `name`, `description`, and `trigger_keywords` as session-local Tier 2 match targets, then report:
`"Discovered {N} new skill(s): {names}. Run /do setup to regenerate routing."`
Do not write registration fields into `harness.json`; schema-v2 config is exact and generated routing is a projection, not config authority.

### Tier 0: Exact Command Match (Cost: ~0 tokens | Latency: <1ms)

Normalize case, apostrophes, and whitespace, then compare the **entire input**.
Never match a Tier 0 command because its word appears inside a larger request.

<!-- BEGIN GENERATED: exact-command-table -->
| Exact normalized input | Action |
|---|---|
| "status", "dashboard", "what's happening", "what's going on", "show activity" | `node scripts/dashboard.js` |
| "next", "what should i do next", "fix harness state", "repair harness" | `node scripts/operator-console.js --run` |
| "operator", "operator console", "approval capsule", "what's up", "what should happen next" | `node scripts/operator-console.js` |
| "continue", "keep going" | `node scripts/continue-action.js --run` |
| "setup", "first run", "configure harness" | `/do setup` |
| "setup --express" | `/do setup --express` |
| "--list", "list", "list skills" | `/do --list` |
| "test", "tests", "run test", "run tests" | `npm run test` only when `package.json#scripts.test` exists; otherwise non-final |
| "build", "run build" | `npm run build` only when `package.json#scripts.build` exists; otherwise non-final |
| "typecheck", "type check", "run typecheck", "run type check" | `npm run typecheck` only when `package.json#scripts.typecheck` exists; otherwise non-final |
<!-- END GENERATED: exact-command-table -->

`/do preview <request>` strips the `preview` wrapper and reuses the shared exact command and built-in candidate preflight. It does **not** inspect Tier 1 active state,
discover project-local custom skills, or run the Tier 3 LLM classifier. Therefore every natural-language preview is non-final, has no command, and stops at
`semantic-classification-required`. `/do --route /skill -- <request>` passes the requested route through `scripts/route-preview.js --route`; an unknown route is rejected,
and a valid override still goes through activation, worktree, and approval boundaries.

If the whole input matches an exact command, execute it and stop. The `test`, `build`, and `typecheck` commands are final only when the target project's
`package.json` declares the corresponding non-empty script. Otherwise they remain non-executable. Do not execute a command merely because its word appears inside a larger request; continue to active-state and semantic routing.

### Tier 1: Active State Short-Circuit (Cost: ~0 tokens | Latency: <100ms)

Check for active campaigns or fleet sessions that match the input scope:

0. For input exactly equivalent to `continue`, first run:
   ```bash
   node scripts/continue-action.js --run
   ```
   - If it executes a local command such as `node scripts/package-delivery.js <slug>`, report the output and stop.
   - If it returns `/archon continue`, invoke `/archon continue`.
   - If it returns `/fleet continue`, invoke `/fleet continue`.
   - If it returns no command, output "No active campaign or fleet session found. Nothing to continue."
1. Read `.planning/campaigns/` for files with `Status: active` or `status: active` in frontmatter
2. Read `.planning/fleet/` for session files with `status: active` or `needs-continue`
3. **Review-package campaigns:** if the campaign status is `needs-review-package`
   or its `review-package` Exit Evidence row is pending while prior phases are
   complete, route to `node scripts/package-delivery.js <slug>` before Archon.
4. **Improve campaigns (type: improve):** if the active campaign has `type: improve` in
   frontmatter, route to `/improve {target} --continue` where `{target}` is the campaign's
   `target` field. Do NOT route improve campaigns to archon -- improve is its own orchestrator.
5. If input scope matches a non-improve active campaign → `/archon continue`
6. If fleet session needs continuation → `/fleet continue`
7. If input mentions a campaign by name → resume it (check type field for routing)
8. **If input is "continue" but NO active campaign or fleet session found:**
   - Output: "No active campaign or fleet session found. Nothing to continue."
   - **If `.planning/daemon.json` exists with `status: "running"`:** the daemon spawned
     this session but there's no work to do. Update daemon.json:
     `status: "stopped"`