# Routing the job

> Know how the skill decides who owns a request (posture, phase, material, companion skills) and run multi-step jobs in an order that doesn't waste passes.

Module: Directing your agent · Level: intermediate · 8 min · https://school.agents.org.in/foundations/agents/routing-the-job

Ask an agent "is this modal animation any good?" and one of two things happens. It hands you a careful verdict. Or it rewrites your modal.

Same words, very different jobs. The skill's first move on any request is to work out which job it is.

*[Interactive demo: Sort the request before reading anything. The posture fixes the shape of the answer.]*

## Four postures

Every request falls into one of four postures (Which of four jobs a request is: Build (make it), Judge (assess it, no edits), Decide (make a call first) or Name (give the word). It fixes the shape of the answer), and each has a fixed answer shape:

| Posture | You want | The answer |
|---|---|---|
| **Build** | UI made or changed | code, using the right values |
| **Judge** | existing work assessed | a table or list, **no edits** |
| **Decide** | a call before building | yes, no or a pick, with the trade named |
| **Name** | the precise word | the term in one line, then stop |

**Judge never writes.** A review request gets a table; a fix request gets code. Turning one into the other silently is how "is this good?" becomes a rewritten file you didn't ask for.

## One entry node, not four

The skill is a graph of small notes called nodes. The routing table (The skill's map from a job to the one note to open first, so the agent doesn't read four clusters to answer one question) maps a job to exactly one node to open first: "pick easing for one animation" opens the easing node, "a dropdown hides under the header" opens the z-index node.

Opening four nodes up front means you skipped the sorting. Start at one, follow its links to the companions it names (the easing node points at reduced motion, for example), and always finish by applying the two override files: your gotchas and your taste.

## The router: phase, then material

Before the routing table, the skill router (What /design-engineering does first for a plain request: find the design contract, work out the phase and the material, then hand the job to one or two owners) asks two questions. First, **what phase is this?**

| The user is saying | Phase | Owner |
|---|---|---|
| "try a few", "not sure which" | undecided | three options behind a picker |
| "something like…" | stuck on a vibe | research, then a generator |
| "build this screen" | foundation | hierarchy and spacing first |
| "feels cheap", "janky" | works, feels off | polish, motion or mobile |
| "review before I ship" | done | the review table |
| "closer, but not quite" | keeps missing | build a tool |

Then, **what is it made of?** Type, colour, motion, sound, SVG, forms. That picks the node or the specialist.

> **Phase beats material.** Polishing a screen whose layout is still wrong wastes the pass. The polish gets thrown away with the layout.

## One or two owners, never five

Loading four craft skills at once spreads attention across four quality bars and applies none of them. The router names **one or two owners** and hands off.

Some owners live outside this skill. A companion skill (Another installed skill that owns one job better, like HyperFrames for launch films or Stageshow for faux product UI. The router hands the job to it when it's installed) is another installed skill that does one job better: HyperFrames builds launch films, diagram-design draws figures, Stageshow builds faux product UI, the AgentsORG `design` skill owns `.design` files. When one is installed, the job goes to it, and the result still passes back through your gotchas, your taste and, for reviews, the table.

Jakub Krehel's interfaces skills are a good example of how the hand-off works. Install them and some jobs move:

| Job | With Jakub's skills | Without them |
|---|---|---|
| Review a branch or PR | `/interface-review` | change-scoped review |
| Stress one component | `/break` | stress scenarios |
| Three variants | `/variant` | the prototype picker |
| How another site was built | `/explain-interface` | reading others' interfaces |

His slash commands are ones *you* start, so the agent tells you the command and stops. Where his values and the skill's disagree, a reconciliation note settles each case. A press scale of 0.96 with no scaling when disabled. A brand focus ring is fine *if* it clears 3:1 against everything it crosses. Unrelated icons (play and pause) cross-fade; related shapes morph.

*(When two owners both seem right, answer from the narrower one and link the other.)*

## Questions that sound the same

Some requests blur together and land on the wrong node. The skill keeps a list of these confusable pairs (Requests that sound alike but belong to different notes, like 'how should this move?' versus 'is this diff's motion good?'. Each pair has a tiebreaker, usually scope) and a tiebreaker for each:

- **Four motion questions.** How should *this one thing* move? Is *this diff's* motion good? What's wrong across the *whole app*? Where is motion *missing*? Tiebreaker: scope.
- **Layout shift has two owners.** Once, while loading: skeletons and reserved space. On every interaction: animating the wrong properties.
- **Looks right, feels finished, should ship.** Designing, polishing, gating. Don't hand a gate verdict to someone still designing.
- **Sound.** Is there a user who can mute it? Product rules. If not, it's a video.

## Chains: the order for a whole job

Single questions go to single nodes. Real jobs chain several, and the order matters. The stacking chains (An ordered route through the skill for a multi-step job, like the screen loop: decide, foundations, one material pass, refine, review, ship. Skip steps; never reorder them) encode orders that survived use.

The screen loop, for one screen:

  **Step: Decide.** If you can't describe it yet, options behind a picker.

  **Step: Foundations.** Hierarchy, spacing, alignment; delete what adds nothing.

  **Step: One material pass.** Forms, surfaces, type, a component's API or a landing page. Just one.

  **Step: Refine.** Polish, then motion, mobile or accessibility only if that's the problem.

  **Step: Review.** The table.

  **Step: Ship.** Once every screen is done, the whole-app pass.

Chains are orderings, not checklists: skip links that don't apply, never reorder them. And don't run a chain on a one-line change; a hover tweak goes to one node and stops.

**Ask who owns it (paste into your agent):**

```text
/design-engineering which "the toast says Saved but screen readers never announce it"
```

**Check yourself:** Someone asks 'Is this dropdown animation any good?' and shares the code. What should the agent return?

- [ ] A rewritten dropdown with better motion
- [x] A Before | After | Why table, without editing the file
- [ ] A list of five skills to install
- [ ] A yes or no with no detail

*Why:* That's the Judge posture. Judge answers with a table or list and never edits unless asked afterwards.

## In the skill

- https://school.agents.org.in/skill/meta/skill-router.md
- https://school.agents.org.in/skill/meta/routing-table.md
- https://school.agents.org.in/skill/meta/disambiguation.md
- https://school.agents.org.in/skill/meta/stacking-chains.md
- https://school.agents.org.in/skill/meta/interfaces-reconciliation.md