route

name

route

description

The suite's risk-sized front door: given a request, name the right top-level PIPELINE (which existing entry points, in what order) by scope and risk — analysis, trivial change, bug fix, feature/high-risk, or codebase health. Advisory; it routes the pipeline only and never sizes verification depth (the brain's job). Trigger: a "which pipeline / where do I start / what process for this / route this" question, or an ambiguous ask whose right path is unclear.

Route — the suite's risk-sized front door

Choosing the pipeline is a cognitive act, so it lives in the brain. The suite already routes by convention (analysis → deep-analysis, a feature → prd-builder/architect, …); this skill makes that convention explicit, named, and reliable as one table. It recommends an ordered pipeline of existing entry points and hands control back — it never dispatches, never hard-blocks, and never re-implements any plugin's own trigger detection.

Classify by scope + risk (check the highest-stakes signal first)

• Intent verb: understand/audit/review/why → analysis · broken/bug/error/crash/wrong-output (a behavioral defect) → bugfix · build/add/implement/create/feature/design/refactor → change-or-feature · health/tech-debt/production-ready/roadmap → health. ("Fix" follows its object: fix a crash → bugfix; fix a typo / cosmetic string with no behavioral failure → trivial change, lane 2.)
• Irreversibility: touches data model / migration / schema / public API / auth / payments / deletion. Any of these escalates to lane 4.
• Blast radius: system-wide / core / shared / rename-everywhere vs. single-file / cosmetic.
• Seam-touching: crosses a documented boundary in docs/architecture/.

Resolve irreversibility/blast/seam before settling a "change" into the trivial lane — an irreversible or system-wide change is never trivial.

The lanes (scope/risk → ordered pipeline of existing entry points)

Lane	When	Pipeline (in order)
1 · Analysis	understand/audit/review, no change verb	maestro:deep-analysis → publishes docs/deep-analysis/. No taskmanager, no prd/architect.
2 · Trivial change	a change verb AND single-file/cosmetic AND no irreversibility/data/seam	maestro:implement directly (read docs → change → verify + maestro:regression → update docs). No full pipeline.
3 · Bug fix	broken/error/crash	systematic debugging → fix → verify + maestro:regression → a scribe incident.
4 · Feature / high-risk	build/feature/design AND (irreversibility OR high blast OR data/compliance OR seam). Also the escalation target for any lane that trips an irreversibility/data signal.	prd-builder → architect → taskmanager (plan → run) → verify → maestro:regression.
5 · Health	health/tech-debt/roadmap	maestro:deep-analysis → roadmap → re-enter (each roadmap item re-classifies through lanes 2/3/4).

Lanes 1 vs 5 share the deep-analysis first step, so the choice is low-stakes. Pick 1 · Analysis for "understand / audit / give me findings or recommendations" — you stop at the findings. Pick 5 · Health only for forward-looking "is this production-ready / what should we prioritize / build a roadmap" — deep-analysis then a re-entering roadmap. (So "audit + recommendations" is lane 1; "what should we work on next / production-readiness" is lane 5.)

Two stamps on every lane

1. Read docs/ first (brownfield-first): STATUS.md, the relevant docs/architecture/, the open docs/adr/. If docs/ is absent, say so and point to scribe:init for the read step. (This names which docs the pipeline reads — it is not a verification-depth instruction.)
2. High-risk → recommend a maestro adversarial pass (adversarial-verify): recommend that a pass be present in the pipeline, naming the entry point — exactly like naming prd-builder. How deep it goes is the brain's call.

Cross-project modifier (any change lane): if the work will land inside a dependency you own (a path/symlinked package), the edit belongs in that package's repo — see the cross-project skill. This is where the edit lands, orthogonal to the lane; route only points, it does not re-detect.

Uncertain → lighter lane + the escalating signal

If signals conflict or are thin, recommend the lighter lane and name the one signal that would escalate it ("looks trivial — but if this touches the orders→billing seam, escalate to lane 4"). Never silently guess heavy; never silently guess light past an irreversibility signal.

What this is NOT

• Not a dispatcher. It recommends an order; the brain proceeds under normal judgment. No auto-run, no hard-block — the real gates (taskmanager's done-gate, the regression verdict) stay downstream and untouched.
• Not a verification-depth sizer. There is no rigor/lens-count column. Lane 4 selects the pipeline shape; adversarial-verify and regression size their own depth ("refute-first always; multi-vote when it matters"). Router = "what pipeline, in what order"; brain = "how deep."
• Not a re-detector. It names deep-analysis/prd-builder/architect/taskmanager/ regression/scribe and composes with their existing triggers; it never re-implements "is this a feature?". implement (trivial/standard/epic) and deep-work ("Route first") already self-route within their scope — this table unifies them at the suite level, it does not paste into them.
• Not fired on a clear ask. "Fix this typo" needs no routing; the model's own skill-selection handles it. Routing is for ambiguous "what process should this take?" moments.