Intent-Router

English | 简体中文

An intent compiler for AI agents.

Turns a vague request into a typed IntentSpec — the clear, machine-readable input that typed decision models (Jev, Laya) and every router downstream assume already exists: it looks up what it can, asks only what it can't, and refuses to emit while the intent is still underspecified.

What that buys you:

• Prompt equity. You get the interaction of a senior engineer without having to learn prompt engineering — the gap between the top 1% of prompt writers and everyone else stops deciding what you get back. Say it the way you'd say it to a capable teammate, "add caching to the user API", and the skill writes the briefing a senior engineer would have written first. You stop coaxing the model and start putting it to work.
• It asks one question, and the answer lands in the delivered code. Before anything reaches you it reads what your repo, ticket system or docs already answer, so the forty-six-question interview becomes the one question that genuinely needs your judgment — and in the delivery comparison, every run with the skill asks exactly that one question and 3 of 3 delivered caches state their failure policy, while none of the 5 bare deliveries do (report).
• The work carries further. Every run ends in a machine-readable IntentSpec, saved to .intent/<intent>.intent.yaml before the reply that carries it, whose probed fields carry evidence pointers — so the output rests on what your project actually says rather than on an unstated guess, and the next agent, session or teammate starts from that contract file instead of zero.

          "add caching to the user API"       "this customer is furious — sort it out"
                        │                                         │
                        ▼                                         ▼
 ┌────────────────────────────────────────────────────────────────────────────────────┐
 │  parse  →  resolve  →  typecheck  →  emit                    one engine, one spec  │
 ├────────────────────────────────────────────────────────────────────────────────────┤
 │  PROBE   deps, routes, git history, ADRs   │  order + ticket log, entitlements,    │
 │          — you are not interrupted         │  the policy in force                  │
 │                                            │                                       │
 │  ASK     serve stale, or serve uncached?   │  refund, or replace?                  │
 │          the one answer no file holds      │  the one that can't be undone         │
 └────────────────────────────────────────────────────────────────────────────────────┘
                        │                                         │
                        ▼                                         ▼
              IntentSpec  ──────►  your planner / agent / workflow / human

Same three passes. Same stopping predicate. Only the places it looks change.

What a real run looks like — one sentence in, it reads the repo itself and asks only what no file can answer. From the measured run of 2026-09-23 behind the numbers below: 8 of the 10 cases the suite held that day, 0 hallucinated evidence.

No install, no API key, no dependencies — it's a skill:

npx skills add angel291592/Intent-Router

Manual install, or an agent the installer doesn't know: Quick start.

Contents

• How it compares
• The problem · How it works · The four decision states
• Two walkthroughs — one in a codebase, one in a support queue
• The artifact · Where it works · Quick start · Evals
• Design principles · Limitations
• Backends · Prior art · Contributing

How it compares

Intent-Router is the layer five good tools leave empty: deciding whether to look, ask, or act — before acting. grill-me converges beautifully, states the right principle, and keeps nothing. Intent-Router generalizes that principle into grill anything: before it grills you, it grills the repo, the ticket queue, the runbook — everything that can answer for itself. spec-kit keeps everything and makes you buy its whole workflow to get it. Routers decide fast and can't handle ambiguity at all. Jev and Laya return exactly the typed, calibrated decision you want — once the input is already clear: Jev needs a well-formed question, Laya needs a formed state to classify. Producing that clear input from a vague request is the hard part, and it's the part neither of them does.

Read the row gaps, not the checkmarks:

Jev and Laya are the same tier — the System 1 decision layer. Jev is a closed API; Laya is the open-weights, Jev-wire-compatible alternative you can run locally. Both answer typed questions in a single pass once a formed input exists; neither converges a vague request into one. That upstream convergence is the layer Intent-Router occupies, and the IntentSpec it emits is the shape of input they want.

What your harness already does — and what this adds

To be fair: a good harness natively prefers looking things up over asking, and offers a recommended default when it does ask. That much is not this skill's contribution, and nothing else on this page should be read as claiming it is.

What it adds is the part a conversation cannot hold:

• The contract outlives the session. Native answers live in the conversation — compress the context, open a new session, switch models, and they are gone. An IntentSpec is a file-level contract, so the next agent, session or teammate starts from it rather than zero.
• Two failures stay distinct. Natively, a probe that failed and a request that was underspecified collapse into the same "I need more information". Here degraded is an operations signal and underspecified is your next step; merging them hides a backend outage behind what looks like a clarifying question.
• It refuses to emit past an irreversible guess. The native bias is "pick a sensible default, mention it, keep going". When an inferred value touches an irreversible boundary, the skill refuses to ROUTE — it HALTs and names the field instead.

The problem

A compiler doesn't guess the address of an undefined symbol. Your agent shouldn't guess your intent.

When you hand an agent "refactor this module", "look into our churn" or "sort this customer out", exactly one of two things happens.

It guesses. You get 400 lines of confident work built on an assumption you never made. You read it, realize the premise is wrong, and throw it away. The agent was never wrong about how to do the job — it was wrong about what you meant, and it found that out only after spending your tokens.

Or it interviews you. This is better, and it's what /grill-me-style skills do well. But the bill is real: the grill-me docs call "forty-six questions across four rounds an ordinary session." And when it's over, the skill is explicitly stateless — "it writes no files and leaves no workspace behind. The only thing it leaves is a sharper version of the idea, in your own head."

So you pay twice. Once in questions, and again because nothing downstream can read the answers. The next agent, the next session, the next teammate — all start from zero.

**Both failures share one root cause: nobody decided whether the missing information was worth asking a human