do

Files (5)

• SKILL.md
• no-planning-dir.md · __benchmarks__/
• route-status.md · __benchmarks__/
• status-command.md · __benchmarks__/
• wrong-assumption-routing.md · __benchmarks__/

SKILL.md (first lines)

# /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 route, alternatives, boundary, and verification without executing |
| `/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. First match wins. Each tier is cheaper than the next.

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

Before routing, check if new skills have been added since last registration.

1. Count installed Citadel skills (built-in from plugin + custom in project's `.claude/skills/`)
2. Read `registeredSkillCount` from `.claude/harness.json`
3. **If counts match**: continue to Tier 0. Zero cost.
4. **If counts differ** (or harness.json doesn't exist yet):
   a. Read the `registeredSkills` array from harness.json (default: `[]`)
   b. Diff skill names against the registered list
   c. For each unknown skill: read ONLY lines 1-10 of its `SKILL.md` (frontmatter)
   d. Extract `name` and `description` from frontmatter
   e. Add the skill to the Tier 2 keyword table for this session using its
      `name` and `description` words as match targets
   f. Log to the user: `"Discovered {N} new skill(s): {names}. Run /do setup to rebuild the registry and regenerate the routing table from skill frontmatter."`
   g. Update `registeredSkillCount` and `registeredSkills` array in harness.json

**This means:**
- 99% of invocations: one number comparison, zero file reads
- New skill dropped in: reads only the new frontmatter, routes immediately
- `/do setup` rebuilds the registry and runs `node scripts/generate-routing.js`, which regenerates the Tier 2 table below from each skill's `trigger_keywords` frontmatter

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

Regex/keyword on raw input. Catches trivial commands:

| Pattern | Action |
|---|---|
| "typecheck" or "type check" | Run the project's typecheck command |
| "build" | Run the project's build command |
| "test" or "tests" | Run the project's test command |
| "loop", "repeat until", "retry until", "until tests pass", "max attempts" | Run `/loop` for bounded foreground repetition |
| "status", "dashboard", "what's happening", "what's going on", "show activity" | Show full harness dashboard (/dashboard) |
| "next", "what should I do next", "fix harness state", "repair harness" | Run `node scripts/operator-console.js --run`; if it stops on a skill route or human-review action, report the boundary, risk, next command, and verification profile |
| "operator", "operator console", "what's up", "what should happen next", "approval capsule" | Run `node scripts/operator-console.js`; report the decision, boundary, artifact freshness, and verification profile |
| "preview route", "route preview", "dry run route", "what would /do do" | Run `node scripts/route-preview.js -- "<request>"`; report selected route, alternatives, boundary, and verification profile |
| "continue" or "keep going" | Run `node scripts/continue-action.js --run`; invoke the returned skill route if it prints `/archon continue` or `/fleet continue` |
| "setup" | Run `/do setup` first-run experience |
| "deliver <intake-file>" | Run `node scripts/deliver.js --intake <file>` to create an evidence-backed delivery campaign |
| "deliver intake" or "deliver next intake" | Run `node scripts/deliver.js --next` to create an evidence-backed delivery campaign from the highest-priority pending intake item |
| "package delivery" or "review package" | Run `node scripts/package-delivery.js <campaign-slug>` to create a local review handoff and update campaign evidence |
| "pr ready" or "ready for review" | Run `node scripts/pr-ready.js --pr <pull-request-url> --run-verification` to produce an approval-readiness handoff |
| "--list" or "list" | Show all available skills |
| "fix typo in X" or "rename X to Y" | Direct edit (no orchestrator needed) |
| "commit" | Stage and commit changes |
| "rollback", "undo phase", "restore checkpoint" | Find active campaign, read latest checkpoint ref, run git stash pop |

If matched → execute directly. Done.

### 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"`, `stopReason: "no-active-work"`,
     `stoppedAt: "{ISO timestamp}"`. Delete both triggers if IDs are present.
     Output: "[daemon] Stopped -- no active campaign found. The work is done."
   - Exit. Do NOT fall through to Tier 2 or 3.

If matched → resume the active work. Done.

### Tier 2: Skill Keyword Match (Cost: ~0 tokens | Latency: <10ms)

Match input against installed skill keywords from Citadel's built-in skills
and any project-level custom skills in `.claude/skills/`.

**Built-in skill triggers** (generated from each skill's `trigger_keywords` frontmatter; edit the frontmatter, then run `node scripts/generate-routing.js` to refresh this table):

<!-- BEGIN GENERATED: routing-table -->
| Input Contains | Route To |
|---|---|
| "architect", "architecture", "design the system", "file structure", "plan the build" | `/architect` |
| "campaign", "multi-session", "phases" | `/archon` |

From mayankjain1815-commits/CITADEL, MIT.

More from mayankjain1815-commits/CITADEL