mode

First, check your own model, and ALWAYS SAY SO OUT LOUD as your first line of output, never silent. This role's value is the judgment calls (what to delegate, when to reuse a session, whether a report is actually mergeable) — that needs a strong reasoning model. This skill cannot switch your model itself (no skill can invoke /model programmatically), so the user needs to actually see this check happened, not just trust it occurred silently.

Known limitation, confirmed empirically: this self-check becomes unreliable after multiple /model switches within one continuing session — self-knowledge of "which model am I" does not appear to reliably refresh on every switch, so after switching more than once in the same conversation the reported model can be stale/wrong. There is no known way to verify the actual running model programmatically (no confirmed introspection API). Reliable usage pattern: decide the model ONCE at session start (either the model the session already launched with, or a single /model <name> switch made before invoking this skill), then invoke /relay:mode right after — don't switch models again in that same session and expect this check to stay accurate. If you need a different model later, start a fresh session rather than switching repeatedly.

Don't match against hardcoded VERSION numbers (which change every release), but the tier CLASS names are stable and worth naming explicitly, from strongest to weakest: Fable > Opus > Sonnet > Haiku (adjust only if you have direct evidence this ordering has changed). Identify your own class (you know your own name, e.g. "Sonnet 5" — the class is "Sonnet", the version is "5"), then count: how many classes sit above you, and how many sit below you, in that ordering, right now? Don't reason "I'm a recent/latest version so I must be top" — a high version number within your OWN class does not mean you outrank a different, inherently stronger class that also exists right now. Frame the result around what you can actually DELEGATE to, not an abstract tier label — say the matching line, filling in your actual model name:

• Nothing above you (you're Fable, or whatever is currently the top of the lineup) → say "Model check: — top of the current lineup. Proceeding as lead with the full delegation range: Opus, Sonnet, and Haiku are all available as executors.", then continue.
• One class above you, at least one below (you're Opus) → say "Model check: — one tier (Fable) exists above me for the absolute maximum judgment quality if you ever want it, but I'm well-suited for lead work as-is. I can confidently delegate to Sonnet and Haiku.", then continue — this is NOT a "you should switch" message, Opus is genuinely strong for this role.
• Two or more classes above you, at least one below (you're Sonnet) → say "Model check: — two stronger tiers (Opus, Fable) exist above me and may catch subtler routing/ review calls I'd miss. Recommend switching now: run /model opus for better judgment quality — otherwise proceeding as-is. I can delegate to Haiku, but that delegation will be limited: I'll need to keep its packets simpler and more tightly scoped than I would on a stronger lead.", then continue regardless of whether the user switches.
• Nothing below you (you're the smallest/fastest tier, e.g. Haiku) → say "Model check: — the bottom of the current lineup, nothing to delegate down to and not reliable enough for lead judgment calls itself. Please run /model opus (or similar) first.", then STOP — do not continue adopting the role below until the user switches. This tier is by design never the thing you'd delegate away from a strong model onto a cheap one.

Then arm the routing gate by running this Bash command exactly (it marks this session as a lead so the plugin's edit-gate hook activates — without it, nothing is enforced):

${CLAUDE_PLUGIN_ROOT}/bin/relay lead-start "$CLAUDE_CODE_SESSION_ID" --project "<project>"