angel291592 / Intent-Router

# Intent-Router
English | 简体中文
**An intent compiler for AI agents.**
Turns a vague request into a typed `IntentSpec`: it looks up what it can, asks only what it
can't, calls out a request that contradicts itself, admits two readings, or rests on a premise
your own repo already disproves, and refuses to emit while the intent is still underspecified.
When the work gets handed off and carried out, it checks the result against the spec it wrote —
one constraint at a time, not a vibe check.
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.yaml` before the reply that carries it, whose probed fields carry
 evidence pointers and which records its own state: still waiting on a question, settled, or
 already carried out. A later session **reads that file before probing anything** — an answered
 question is never asked again, a settled contract is implemented as written — and the result of
 checking the delivered work against it is written back into the same file. So the next agent,
 session or teammate starts from what you actually decided instead of zero.
### What "installed" changes, in the diff itself
Same weak request, same fixture, same permissions, one line apart —
bare vs. with the skill (N=5 bare, N=3 skill).
Excerpted verbatim from each run's own `diff.patch`, the part that decides what happens when the
cache itself fails:
**Bare** — no failure path exists to read. A downed Redis takes the request down with it:
 [code] 
**With the skill** — asked the one question no file could answer, then wrote the answer into the
code:
 [code] 
Every one of the 5 bare runs shipped the first shape; every one of the 3 skill runs shipped the
second. Neither line was written by hand for this README — both come straight out of the runs
that produced the numbers in Evals.
 [code] 
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 belo