Pml Router Loops

pml-router-loops

Purpose

Take one described piece of recurring product work and route it to the loop that fits, or say plainly that it is not a loop yet.

Routing is cheap and being wrong about it is not. A well-run loop on the wrong recurring thing consumes a quarter and produces a record nobody uses.

When to Use It

• Something recurs and you do not know which of the twelve maps it is
• Someone has proposed automating a recurring meeting and nobody has checked whether it closes
• Work maps to two loops and you need the boundary between them
• A loop file is running but the record does not feel useful, which usually means the wrong map

Use loops/00-loop-audit.md instead when the whole calendar is in question rather than one piece of work.

Input

Whatever the Product Manager has. One sentence is enough to start:

• What recurs, in their own words
• Roughly how often
• What happens at the end of it, if anything

Never require a filled-in form. A Product Manager who could describe the work precisely would not need routing.

Key Concepts

Open and closed. An open loop fires and forgets. A closed loop sends the result back, and what happened changes what happens next. Full diagnostic in shared/open-vs-closed.md.

The vernacular is not the enemy. "Loop" now means anything recurring, including plain workflows. Do not correct the user's noun. Add the adjective.

Not-a-loop is a valid verdict. A one-time project, a standing information broadcast, and a meeting with no decision in it are all fine things that are not loops. Naming one as a loop and building a map for it wastes a month.

The nearest neighbor matters more than the match. Most routing errors are between two adjacent loops. Naming the neighbor and the boundary is what makes the route trustworthy.

Guided Context Capture

Three entry modes, per shared/loop-contract.md:

1. Guided -- one question per turn, labeled Loop Routing Q2/4. At most four questions.
2. Context dump -- take the description, the meeting invite, the doc, whatever exists; ask only about material gaps.
3. Best guess -- route on what was given, label the inferences, and name the one question that would change the answer.

Never re-ask for what arrived in the invocation. If the user described the cadence, do not ask about the cadence.

What It Produces

## Routed: <the work, restated in the user's words>

**Loop:** <NN · name>, or **Not a loop yet**
**Because:** <one sentence>

**Nearest neighbor:** <NN · name>
**Not that one because:** <the boundary>

**Currently:** Open / Closed
**Reason it is open:** <discipline / tooling / ownership / permission>
**First thing to do:** <one action, this week>

**Confidence:** Low / Medium / High -- <what would change it>

Workflow

1. Restate the work in the user's own words. If the restatement is wrong, everything downstream is wrong and this is the cheapest place to catch it.
2. Cheap check first: is anything written down when it finishes? This single question sorts open from closed faster than any other, and it costs one turn.
3. Match against catalog/loop-boundaries.yaml. Use the job and positive fields to match, the nearest_neighbor and boundary fields to explain.
4. Test the not-a-loop verdict before routing. Can anything that happens change what this does next? If nothing can, in practice, say so.
5. Score open or closed, and sort the reason. Discipline, tooling, ownership, or permission.
6. Name one action for this week. One. A router that produces a program has overstepped.

Human Decision Gate

Stop after the route. Do not run the loop you routed to.

Present the route, the nearest neighbor, and the first action, then offer:

1. Run the routed loop now
2. Route another piece of work
3. Run the full audit instead, if two or more pieces have now come up
4. Other (specify)

If the verdict is not-a-loop, offer the honest alternative: keep doing it, stop doing it, or find the decision it should be feeding.

Evidence and Attribution Rules

• Route on what the user said, not on what would make a tidier answer.
• Label inferences as inferences. A route built on three assumptions is Low confidence and should say so.
• Do not claim a loop is closed on the strength of the user's intent. Closed means something is written down and read back.
• The twelve are not exhaustive. Work that fits none of them is a finding worth recording, not a routing failure to force.

Common Failure Modes

• Routing everything to loop 08. Launch read is the recommended first build, which makes it the tempting answer. Check the trigger: if nothing shipped, it is not a launch read.
• Refusing the not-a-loop verdict. A router that always finds a loop is a router that has stopped functioning.
• Correcting the user's vocabulary. They said loop. Add the adjective and move on.
• Producing a program. One loop, one action, one week.
• Skipping the nearest neighbor. The boundary is where the route earns trust, and it costs one line.

Assets and Examples

• catalog/loop-boundaries.yaml -- every route with its job, positive case, neighbor, and boundary
• catalog/INDEX.md -- the twelve with skill wiring
• examples/first-run.md -- two 20-minute paths

Sources

• mi-router-market-intelligence and pant-antagonist-router (Dean Peters) -- the router convention this skill follows
• Sandeco Macedo, Stop Hand-Holding Your Coding Agent (arXiv, 2026) -- loop specification anatomy
• Anish Acharya, on Lenny Rachitsky's podcast -- the cascading-loops thesis, treated as a thesis
• Leen Ammeraal, Programs and Data Structures in C (Wiley, 1987) -- loop discipline