Intent-Router — скилл

---
name: intent-router
description: >-
  Converges an underspecified request into a typed IntentSpec before planning or acting. Use when
  the user asks to implement, add, change, refactor, fix, migrate, configure, handle, triage, sort
  out, look into or decide something and the request leaves decisions open (which objects, which
  approach, what happens on failure, which trade-off), contradicts itself, admits two readings, or
  rests on an approach its sources may rule out — in a codebase, a ticket queue, a research brief
  or a runbook — or when the user says "clarify the intent", "what do you need from me", or
  invokes intent-router. Looks up what its sources hold (code, history, decision records, a ticket
  log, an order record, the policy in force) before asking; asks only preference or irreversible
  questions, one at a time, with a recommended default; halts instead of guessing; checks the
  delivered work against the spec. Silent on a fully stated task its sources do not contradict.
  Not for explaining existing state ("what does X do", "why is Y slow").
license: MIT
metadata:
  version: "1.3.0"
  author: angel291592
  homepage: https://github.com/angel291592/Intent-Router
---

# Intent-Router

A compiler does not guess the address of an undefined symbol. Do not guess the user's intent.

This runs one layer *before* planning, routing or coding. It converges a request into an
`IntentSpec` — a typed, machine-readable statement of what is actually being asked — and hands
that off. It does not implement anything itself.

## 1. Purpose and when this fires

Three passes, in compiler order: **Parse** the request into a draft spec, **Resolve** every
open question by looking it up or asking, then **Typecheck and emit** — route, ask, or halt.

Start when **both** hold:

1. The request is a *do-something* request: implement, add, change, refactor, fix, migrate,
   configure, handle, triage, sort out, look into, decide, write, set up, wire up, rename, remove,
   upgrade, optimise.
2. A quick scan finds **at least one decision-bearing unknown** — an answer that would change
   which files are touched, which approach is taken, how failures behave, or what counts as done.

Do not start when: the request asks you to explain existing state ("what does X do", "why is Y
slow") rather than to find something out and produce a deliverable; the silence check below passes
and its premise check finds no contradiction — every decision-bearing item is already stated, so
there is nothing to converge; or the request is trivially scoped and reversible (fix a typo).

**Look for a saved contract first.** Before probing, look for earlier work on this same request:
`<workspace>/.intent/<intent>.intent.yaml`, stem = the `intent` slug, matching on
`request`/`objects`. Its `verification_status` decides: