The Authority Bar: What Makes a Skill Phenomenal

The skill that never fired

Here is a failure you will recognize. You author a skill — say, one that deploys a backend fix to production. You test it: you type its name, it runs the steps, the deploy succeeds. You commit it and move on. Three weeks later you are mid-conversation, you say "ok the PR merged, push this to prod," and Claude Code… improvises a generic deploy. Your skill — the one with the host-check and the post-deploy verification gate you carefully wrote — never fired. It sat dormant because you never typed its name.

That skill is not broken. It works. But it is only adequate, and adequate is the most dangerous tier because it feels like done. The whole craft of skill engineering is the distance between that skill and a phenomenal one — a skill that recognizes the situation and fires itself, then declines the cases it wasn't built for.

This lesson is about that distance: what the authority bar measures, and why two skills with nearly identical instructions can land on opposite ends of it.

The three tiers

Walk the bar from the bottom.

Broken skills don't fire, or fire for the wrong thing. The tell is structural: a description with no trigger phrases, no WHEN-NOT-TO-USE section, and a "done" condition that's a vibe rather than a check. A broken skill is honest about being unfinished — you notice it immediately because it misbehaves.

Adequate skills are the trap. They run correctly when you invoke them by their slash name, and then they go dormant. The triggers, if they exist at all, only match the exact name. The steps describe the happy path the author imagined. The gate is loose: "I think it worked." An adequate skill passes every test you'll think to run, because you test it by invoking it directly — which is exactly the one path that works.

Phenomenal skills fire themselves at the right moment and refuse the wrong one. The description carries the proactive-invocation contract — trigger phrases plus a WHEN clause — so the model recognizes the situation without you naming the skill. Rationalization counters block the adjacent cases the model would otherwise talk itself into. And the verification gate is hard: it proves the specific failure the skill exists to prevent cannot recur.

The gap is authorship, not effort

The uncomfortable truth: you can spend the same hour on two skills and land in different tiers. Effort doesn't move you up the bar — authorship does. Specifically, whether each part of the skill answers a question the model is actually asking.

Read that matrix column by column, not row by row. Every phenomenal cell is an answer to a live question the model has at runtime:

• Should I fire this? Answered by trigger phrases in the description. The adequate version restates the name ("Runs the deploy skill") and answers nothing.
• Is this the right case? Answered by WHEN NOT TO USE. The adequate version has no boundaries, so it happily runs for adjacent wrong situations.
• How do I know it worked? Answered by a hard verification gate. The adequate version checks that the steps ran, which is a different and weaker claim.

This is why authorship beats effort. You can write five paragraphs of beautiful deployment steps — that's effort — and still ship an adequate skill, because none of those paragraphs answer "should I fire this?" Meanwhile a phenomenal skill might have fewer, tighter steps but a description that makes it fire at exactly the right moment.

A worked contrast

Take a real pairing. Knox maintains a skill that deploys backend changes to the persistent runtime that serves production. Here are two versions of its frontmatter.

The adequate version:

name: deploy-prod
description: Deploys a backend change to production.

The phenomenal version:

name: deploy-prod
description: >-
  Deploy a backend or cron fix to the production runtime, end-to-end.
  Use when shipping a backend change after a PR merges to main.
  Triggers: deploy to prod, ship this to production, redeploy the backend.

Same name. Same skill body underneath. But the first description gives the model nothing to match against "ship this to production" — so the skill stays dormant and Claude improvises. The second carries the WHEN clause and the trigger phrases, so the model fires it the instant the situation appears. The body — with its host-check and its "is the service actually serving the new shape?" gate — only matters if the skill fires, and the skill only fires if the description earned it.

That is the entire lesson in two YAML blocks. The body is where the value lives; the description is what unlocks it.

Where each tier shows up in the wild

Most skills people write are adequate, and most never get better — because the author tests them the one way that hides the flaw. They invoke the skill by name, see it run, and conclude it's done. They never check the case that actually matters: does it fire when the situation arises but nobody names it? Does it stand down when a near-miss case shows up?

The fix is to test the bar, not the steps. After writing a skill, ask: would this fire if I described the situation without naming the skill? Would it refuse if I described a case it shouldn't handle? If the answer to either is no, you have an adequate skill, and you have more authorship to do.

Build it: write the bar, not the steps

You're going to author the part of a skill that decides its tier — the description and a single rationalization counter — for a skill that scaffolds a new database migration. The steps aren't the assignment; the firing contract is. Make the description carry trigger phrases and a WHEN clause so the model fires it proactively, then add one WHEN-NOT-TO-USE line that blocks the most tempting misuse.

What's next

You've seen what separates the tiers from the outside. The next lesson takes a phenomenal skill apart from the inside — the six structural parts of a production skill, what the model reads and when, and why progressive disclosure lets a skill be both rich and cheap. After that, lesson 663 goes deep on the single field this lesson kept pointing at: the description, and the proactive-invocation contract that lives inside it.