Your AI Skills Have Two Dials. Most Ship With One Turned Off.

I have spent the past month reading skill libraries, and I kept feeling like I was comparing things that would not line up. One guide would compress six books on legacy code into an ordered playbook. Another would define a seven-phase chain where each phase writes an artifact and refuses to advance until a gate passes. Both are called skills. Both are instruction files you drop into a repo. And they are not doing the same job at all. The word hides the split. Once I saw it I could not unsee it, and it explains most of the ways these setups fail. Two dials, not two bins The clean way to say it is that a skill can carry two different things, and they are independent dials rather than a pair of boxes. Content is knowledge packed into steps. It tells the agent what to do, in the right order, distilled from someone who knows the domain. The Wondel guides are a clear example. Their legacy-code playbook (checked 2026-07-17) compresses canon like Feathers' Working Effectively with Legacy Code, Fowler's Refactoring, and Ousterhout's A Philosophy of Software Design into a sequence: characterization tests first, then readability, then restructure, then scale. The value is that you carry a shelf of canon in your pocket. The content tells you the move. Control is evidence discipline packed into gates. It does not tell you what to do in the domain. It tells you what a move has to leave behind before anyone trusts it. Jeel Vankhede's seven-skill workflow (checked 2026-07-17) is the sharpest version I have seen. Each phase has a distinct role and writes an artifact the next phase reads instead of trusting chat memory. Its review skill maps every requirement to covered, partial, or missing, and its rule is to trust evidence, not claims. Control does not name the move. It names what the move must produce. One caveat before the dials feel too separate. They are independent in strength, not in operation. Control can enforce only the criteria that content, a spec, or an operator handed it. The dial that decides what deserves a gate is content. So a skill can be strong on either dial alone, but a control gate with nothing to enforce is as empty as domain advice no one checks. These are two dials, and a skill can sit anywhere on both. Control-light Control-heavy Content-heavy domain playbook, no gates (Wondel-ish) knowledge inside gates Content-light thin and ungated, avoid process scaffold, no domain (Jeel's chain leans here) I place the examples loosely on purpose. Wondel leans content with light enforcement, Jeel's chain leans control and stays domain-neutral by design. Neither is a pure corner, and neither is trying to be. A single skill does not need to max both dials. A narrow skill can supply exactly one on purpose, and the surrounding system supplies the rest. The failure does not begin when one skill scores low. It begins when nobody in the stack owns the missing dial. Why the missing dial costs you The failure modes are quiet, and they look like success right up until they don't. Content with no control lets an agent produce a well-structured but unverified answer. It recites the architecture playbook, names the bounded contexts, cites the Dependency Rule, and produces something that reads like it was built by someone senior. Nothing checked whether it works. Nothing mapped the output back to what you asked for. You get the vocabulary of rigor with none of the evidence, because a skill with no gate lets a plausible answer and a correct one exit through the same door. Domain-neutral control audits a shallow result as cleanly as a deep one. This is the narrow claim, and the narrowness matters. A control layer that verifies only process and traceability, that a decision was made, recorded, and mapped to a requirement, cannot judge whether the decision was any good. Control can be domain-aware: a gate can embed validators, policy checks, or an expert review criterion, and then it does test quality. But a domain-neutral chain does not, by construction. It confirms the shape of the work, not its substance. There is a sharper trap inside the control dial, worth stating plainly: a gate is only as strong as the evidence it demands. An artifact that records "tests pass" because the agent typed those words proves nothing. A gate that checks the wrong behavior passes while the real requirement fails. A gate that trusts self-report is theater. The gates that count demand evidence that could have come back negative, and the strongest evidence comes from a mechanism the agent cannot quietly rewrite: an immutable fixture, a separate runner, CI, or an accountable human. That last requirement is doing more work than it looks. Between ordinary drift and outright fabrication sits a quieter failure: honest evidence that inherits the blindness of the thing it checks. A receipt drawn from the same inputs as the claim it verifies, or a consensus where both reviewers carry the same stale assumption. Nothing is faked and nothing is careless, yet the gate passes on a check that could never have failed. That is the sharper reason constrained verification asks for a mechanism that does not share the claim's blind spot, not merely one the agent did not rewrite. The scorecard targets that case along with ordinary self-reporting error. Adversarially fabricated evidence, where the agent actively forges the artifact, is a harder threat and needs more than a rubric. Running both dials, concretely The two combine instead of competing, and it is worth seeing one small change move through both. Say the request is "add per-IP rate limiting to the API." The content dial supplies the domain move, and a good content-skill forces the real decisions rather than assuming them: which layer enforces (edge proxy, gateway, or app), what identifies a client (IP often starts there but breaks behind shared proxies or for per-user limits), where shared state lives, the threshold, the burst policy, and whether the limiter fails open or closed. None of that is automatic. The control dial pins the outcome as a requirement you can check. R1: with the same resolved client IP, the first 100 requests in a 60-second window succeed and the 101st returns HTTP 429, and the counter resets cleanly at the window boundary. Build implements it and records the changed files against R1. Review reads the diff and marks R1 covered, meaning the change plausibly satisfies it. Then, separately, a test phase drives a load generator through that exact sequence and the gate passes only if it observes the 429 and the reset. Notice the split in the last two steps. Review checks correspondence. Test observes behavior. One read the code and it lines up with R1. The other ran the code and watched the 429. They live in different phases on purpose, so no single artifact blurs "I read it" into "I ran it." That split clarifies how the verdicts nest. A phase exit gate is binary: R1 either meets its gate or it does not. The three-way covered/partial/missing lives one level up as a review finding, and a "partial" counts as a failed exit gate, not a soft pass. The review's overall recommendation is a further aggregate, and it is deliberately ternary: pass, pass-with-risk, or hold, because a reviewer can flag real residual risk without a hard failure. Binary checks feed findings, findings feed the verdict. Do not confuse the per-check gate with the summary call. A scorecard, not an impression Score both dials before you trust a setup, and score the stack, not only each file. Do not just ask whether every skill carries both dials. Ask whether your system does, and name which component owns each one: a content library, a workflow chain, CI, an operator. Three rows per dial, 0 to 2 each. Any zero must be supplied elsewhere in the stack or explicitly accepted before you rely on it. Content dial Provenance and basis. 0: no stated basis. 1: named source or internal practice, but no reason it applies here. 2: traceable source, standard, or retained internal evidence, plus why it fits your case. Applicability. 0: one-size prescription. 1: a few defaults with escape hatches. 2: explicit branch points for the decisions your case turns on. Maintenance. 0: no version scope where the domain can move. 1: dated or versioned, but no review trigger. 2: version scope plus a review or invalidation rule sized to how fast the domain changes. Control dial Traceable requirements. 0: none. 1: prose goals, no IDs. 2: every change names the requirement ID it serves. Durable artifacts. 0: chat only. 1: notes that need the session to interpret. 2: a fresh session reconstructs state from files alone. Constrained verification. 0: self-report. 1: the acting agent runs and records a check it could edit. 2: evidence from a mechanism it cannot quietly rewrite, an immutable fixture, separate runner, CI, or accountable human. Most setups score high on one dial and leave the other near zero. The ones that hold up score across both, on purpose, and can name which component owns each. The word "skill" will not tell you. You have to. Content tells the agent what move to make. Control decides what evidence must exist before the system is allowed to trust that move. No single skill has to carry both. Your stack does.