| name | route |
| description | Use before acting on any request that will change a repo, or that asks for a design decision, debugging help, or planning — decides which skill (or no skill) handles it next. |
route
Runs before action on any substantive request. Trivial talk (greetings, questions about
galdr itself) does not need routing.
Announce the destination in one line, then act:
routing: <destination> — <one-line reason>
Examples:
routing: debug — unexpected behavior reported (SSE handler dropping events)
routing: tdd-fast-path — single file, existing coverage, no cross-repo/registry/i18n/migration surface
Decision table
| Signal | Route |
|---|
| Question / discussion / no repo mutation | answer directly, no ceremony |
| Bug or unexpected behavior reported | debug |
| Fast path: single file, existing test coverage, no cross-repo / registry / i18n / migration surface | tdd directly (announce "fast path") |
| Feature or change, spec/plan already exists | plan (if plan missing) or waves (if plan exists) |
| Feature, no spec, requirements clear enough to state | shape in synthesis mode → spec without interview |
| Feature, requirements fuzzy, user has a position to test | shape in grill mode |
| Feature, open-ended, no position yet | shape in explore mode |
| Multi-session fog (no spec possible yet) | shape with wayfinder map reference |
| Architecture pain, no specific feature | rearchitect |
| Design question answerable by building | prototype |
Canonical route names, in table order (the exact tokens other skills and the accuracy
tests use): answer, debug, tdd-fast-path, plan / waves, shape-synthesis,
shape-grill, shape-explore, shape-wayfinder, rearchitect, prototype.
Fast-path criteria
Route to tdd-fast-path only when ALL of these hold:
- Single file changes.
- Existing test coverage already covers the code being touched.
And NONE of these apply:
- Cross-repo: the change spans more than one repo in the workspace, or touches a
documented mirror pair (two artifacts required to stay in sync across repos — the
repo's setup config lists which ones).
- Registry or enum surface: adds or changes a closed-enum entry (business type, Catalog
vertical, and similar).
- i18n catalog surface: adds or changes user-facing strings that need EN + ID.
- Migration surface: adds or changes a schema migration.
If any one of these applies, or the file lacks existing test coverage, route to plan
(or waves if a plan already exists) instead — the change still needs the normal
ceremony. One boundary: this plan-exit is for changes that are already fully specified
and merely excluded from the fast path. Feature-sized work with no spec still goes
through shape first — the decision table's spec-first rows govern feature scale.
A repo's setup config (docs/agents/galdr.md) may override these criteria. Follow the
repo's override when one is configured; use the list above by default.
Override rule
One word from the user wins. If the user names a different skill or route, switch
immediately. Do not re-litigate the router's own call.
Output budget
On trivial turns (answer, tdd-fast-path), the router's own output is at most 2 lines:
the announce line, plus at most one line leading into the answer or the first test. No
extra framing, no re-explaining the decision table.
Fast path still obeys the Iron Laws
tdd-fast-path skips planning ceremony, not discipline. The Iron Laws still apply in
full: write the failing test first, verify completion with fresh evidence, find the root
cause of any fix. "Fast path" names a shorter path to tdd, not an exemption from it.
