---
name: triage
description: "Escape hatch for prompts that don't fit a standard forge workflow command — research questions, monitoring playbooks, ad-hoc data exploration, codebase explainers, debugging-without-fix. Classifies the work, then offers three routes: (a) ad-hoc with rules-only, (b) escalate to `/feature` with most phases skipped, (c) document the workflow gap for `/forge-evolve` then do it ad-hoc."
argument-hint: "[short description of the work, optional]"
---

# /triage — Non-Workflow Escape Hatch

forge's standard workflow commands (`/feature`, `/bugfix`, `/refactor`, `/hotfix`, `/greenfield`) all assume an SDLC-shaped task with a clear output. Some prompts don't fit — research, monitoring, single-pass exploration, "explain this codebase," debugging where the user wants the diagnosis but not (yet) a fix. `/triage` gives those prompts a graceful exit instead of forcing them through a workflow that doesn't apply.

The user invokes `/triage` when they know their work doesn't fit. The agent may also suggest it (per `support-system-guide`) when no workflow command matches the user's intent.

## Step 1: Classify the work

Restate the user's prompt in one line, then propose a classification. Pick **one** from this list — choose the closest match; do not invent new categories:

| Category | Example |
|---|---|
| `research` | "What's the state of CRDT libraries in 2026?" / "Compare LiveKit vs Daily" |
| `monitoring` | "Set up an alert when error rate exceeds 1%" / "Write a runbook for the X outage" |
| `ad-hoc-exploration` | "Poke at this dataset and tell me what's interesting" / "Try three approaches and report" |
| `explanation` | "Walk me through how auth works in this repo" / "Why is this file structured this way?" |
| `debugging-without-fix` | "Diagnose why login is slow, don't fix it yet" |
| `data-pipeline` | "Pull X from Y, transform, write to Z — one-shot script" |
| `other` | None of the above — describe what it actually is in one phrase |

Surface the classification and wait for the user to confirm or correct. If the user disagrees, accept their correction and proceed.

## Step 2: Offer routes

Based on the confirmed classification, propose **one** of these three routes. Pick the one most likely to serve the user; mention the other two as alternatives.

### (a) Ad-hoc with rules-only

Just answer the question / do the work with the auto-loaded common rules in play. No command, no manifest, no gates. The session still runs under `forge-system`, `security`, `guardrails`, `verification`, `skill-selection`, `quality-gates`, `git-workflow` — so safety floor and verification discipline stay active — but the SDLC pipeline does not engage.

**Best for:** `research`, `explanation`, single-pass `ad-hoc-exploration`, `debugging-without-fix` where the user only wants a diagnosis.

### (b) Invoke `/feature` (lightweight default)

If the work IS code-shaped but doesn't need extended SDLC phases (a small CLI tool, a one-shot script, a monitoring playbook that's actually a small program), invoke `/feature <name>` and accept its **lightweight default** at Step 0c — build + tests + review + PR with the extended phases (`concept` / `wireframe` / `prototype` / `iterate` / `codify`) staying `skipped`. The user does not need to pass any flag; the lightweight default is already what `/feature` proposes at preflight.

**Best for:** `data-pipeline`, `monitoring` when the output is real code, `ad-hoc-exploration` that turned into "let's actually build this small thing."

### (c) Document gap for `/forge-evolve`, then do it ad-hoc

If the work surfaces a pattern that recurs and deserves its own command (e.g., third `monitoring` request in two months), capture the workflow gap so `/forge-evolve` can review it later.

**Capture location depends on whether the aiwiki layer is enabled** (set at `/setup` Step 4; default Y for production / greenfield, N for prototype — see `commands/setup.md`):

- **`aiwiki_enabled: true`** (the common case): append a brief note to `aiwiki/raw/{YYYY-MM-DD}.md` using `/note` or an inline append. The note format:

  ```markdown
  ## {HH:MM} — workflow gap: {category}

  Triage classified this as `{category}`; no standard forge command fits.
  User prompt: "{user's prompt, ≤120 chars}"
  Pattern signal: {first occurrence | recurring — Nth time this month | known gap}
  Suggested follow-up: consider a `/{proposed-command-name}` workflow if this recurs.
  ```

- **`aiwiki_enabled: false`**: aiwiki is not scaffolded, so there's no `aiwiki/raw/` to write into. Surface a one-line upgrade hint to the user — "This is the Nth `{category}` request worth tracking. Enable the aiwiki knowledge layer (re-run `/setup` and answer Y at Step 4) if you want `/forge-evolve` to see this gap later." Then proceed with route (a) without the note. Do NOT silently write to a different location — the gap is signal that may or may not be worth persisting; the user decides.

Then proceed with route (a).

**Best for:** any classification where the user senses the gap matters beyond this one prompt.

## Step 3: Confirm and proceed

Present the suggested route in one line: **Suggested route:** `(a) / (b) / (c)` — `<one-sentence rationale>`. Mention the other two routes briefly. Wait for the user to pick (or override).

- Route (a): do the work directly in this session. Use any non-workflow skills that apply (`support-debug` for `debugging-without-fix`, etc.) and respect the auto-loaded rules.
- Route (b): invoke `/feature <name>` with the user's blessing. Accept `/feature` Step 0c's lightweight default (extended phases stay skipped); the user can flip individual phases on at preflight if their judgment differs from yours.
- Route (c): if aiwiki is enabled, write the `aiwiki/raw/` note (via `/note` or inline append), then proceed as route (a). If aiwiki is disabled, surface the upgrade hint and proceed as route (a) without persisting the gap note.

## When to use

- The user invokes `/triage` explicitly because they know their prompt doesn't fit a workflow.
- The agent (per `support-system-guide`) cannot classify the user's intent into `/feature`, `/bugfix`, `/refactor`, `/hotfix`, or `/greenfield`, and is about to default to one of them — suggest `/triage` instead.
- A user asks "which command for X?" and none of the workflow commands genuinely fits.

## When NOT to use

- The prompt fits a standard workflow command — use that command directly. `/triage` is for the in-between, not a routing layer over working routes.
- The user has already invoked a workflow command and the preflight should handle it — let the command's Step 0 do its job.
- A trivial inline question that doesn't need three steps of classification ("what does `phase_plan` mean?") — just answer it.

## I/O Contract

| Field | Value |
|---|---|
| **Requires** | -- (escape hatch; no preconditions) |
| **Produces** | Console classification + suggested route. Route (c) appends to `aiwiki/raw/{YYYY-MM-DD}.md` when aiwiki is enabled; surfaces an upgrade hint when disabled. Route (b) creates a `.forge/work/feature/{name}/manifest.yaml` via `/feature` with its lightweight default. |
| **Updates manifest** | None directly (route (b) delegates to `/feature`) |
| **Feeds into** | Route (a): ad-hoc session work; Route (b): `/feature` trivial-scope flow; Route (c): `/forge-evolve` (future review of accumulated gap notes) |

## Do NOT

- Do NOT skip Step 1 and jump to a route. Classification is the point — without it, route (c) cannot record a useful gap note and routes (a)/(b) lose their rationale.
- Do NOT use `/triage` to bypass a workflow command that fits. If `/feature` applies, use `/feature`.
- Do NOT invent new classifications beyond the seven in Step 1. If none fits, use `other` and describe the work in one phrase.
- Do NOT auto-execute a route without user confirmation. `/triage` is a suggestion layer; the user picks.