Skip to content

Intent Routing

Mandatory module

This module installs on every platform and cannot be declined.

How a user's expressed wish about functionality routes to a skill, and why planning happens inside the develop skill rather than in the harness planner.

Related artifacts:

  • skills/develop
  • skills/using-skills

Rule Content

<CRITICAL>
### Intent Routing

The skill check comes FIRST, before responding, exploring, or clarifying: if any skill plausibly applies, load it before acting. "I'll read the file first" and "this one is simple" are the two rationalizations that bypass it. Skip the check only on low-signal turns — status questions and short clarifications. Load `using-skills` for the threshold and the full routing flow.

When the user expresses a wish about functionality ("Would be great to...", "I want...", "We need...", "Can we add..."), invoke the matching skill IMMEDIATELY. Do not ask your own clarifying questions before loading the skill. Once loaded, follow the skill's instructions exactly, including any confirmation steps or quality gates the skill defines. "Invoke immediately" means load the skill without delay, not skip the skill's own phases.

For ANY substantive code change (new features, modifications, refactoring, multi-file changes, or anything requiring planning), invoke the `develop` skill. Do NOT use your platform's planning mode or plan independently. The develop skill is a thin entry gate: it asks which ceremony path you want (full ceremony, fast path, or skip develop entirely) and then handles planning through its own phases. It exits only when the operator chooses to skip it.

**Standing exception — the Nord Modular G2 project.** In `axiomantic/nmg2-tools`, `axiomantic/nmg2-artifacts`, `axiomantic/mcf5307`, `axiomantic/mc68k`, `axiomantic/dsp56300`, `axiomantic/gearmulator` and `axiomantic/G2-Edit`, I select `skip develop entirely` at the entry gate. This is standing, for every session, and it does not need restating per session. Those repositories carry an `AGENTS.md` and a roadmap that define the process, and that process is the whole of it. Do not invoke `develop` there. Do not add a phase, a gate, an approval step or a checkpoint ladder to what those documents describe, and do not build a linter, a register or an audit script for them — that project removed seven such instruments deliberately and they are not to come back. This overrides, in those repositories only, the general allowance elsewhere in these rules for mechanizing a verification table or pinning a count that a test checks. That is the exact shape that kept regrowing there: a pinned number fails whenever the thing it measures improves, so it converts progress into a red build and someone into a maintainer of the pin. If something in those repositories looks like it needs checking, say so and let me decide. Do not write the check.

You do NOT know what the user wants until they tell you. Do NOT guess, infer a design from a wish, or skip to implementation. Do NOT independently explore or plan before invoking the skill. Do NOT start designing or building until the skill's quality gates are passed.
</CRITICAL>

<FORBIDDEN>
- Using EnterPlanMode for any implementation task
</FORBIDDEN>