The Method
The working method these layers come from — reusable, inspectable, improvable agent work.
Deep dive · Anatomy of a skill
A skill is not a list of instructions.
It is a layered control structure. Each part of the file steers the model with a different linguistic device, working at its own level of abstraction. This page takes one real skill apart with an interactive x-ray, names each layer and the device it uses, and shows how the same structure runs through the CyberAlchemy method.
Begin with the prevailing assumption
The common reading
A common reading treats a skill — or a prompt, or a system message — as a set of instructions written for a model: a sequence of directions the model is expected to follow in order.
It is a reasonable account. It is how prompting is usually taught, and it is not wrong so much as incomplete. Read top to bottom, a skill file does resemble a long list of instructions, and so competent agent behaviour is naturally attributed to well-written instructions.
The reading fails, however, against a sharper question: why does this directive sit at the top of the file and that one near the bottom? Why is one passage a role assignment ("you are a…"), the next a numbered sequence, the next a hard "stop here", and the next a demand for a citation? Under the instruction model, order and form would be largely incidental. In practice they are load-bearing.
The correction
Stated precisely: a skill file is not a single instruction restated in different words. It is a stack of control layers, and each layer steers the model with a different linguistic device working at a different level of abstraction — a binding contract at the floor, an identity frame above it, a fixed skeleton, bounded discretion, hard stop-gates, proof obligations, and the output shape on top. Read the file as strata rather than as instructions and it becomes legible: its order and form turn out to have reasons.
Inspect the artifact directly
An x-ray of a real skill
The artifact below is the actual /refine skill — one of Arcanum's capabilities — cut into the layers of language it uses to steer a model. The interface is interactive: toggle layers on and off, run the guided tour to assemble the stack one layer at a time, and hover any layer to see the device it uses and a reading of how that device steers the model. Readers are encouraged to examine it before continuing.
Interactive panel not loading? Open the x-ray in its own tab → Use the Guided tour button to build the stack layer by layer, or toggle Stacked deck / Strata to switch views.
A note on how to read it: every quote in the x-ray is lifted verbatim from the skill's source file and is therefore source-backed. The device labels and the "how it steers" column are an interpretation of why the language is shaped as it is. That distinction is itself part of the lesson; it returns below.
Layer reference
The stack, floor to surface.
Seven classes of layer, ordered from the floor of the file to its surface. Each performs a function the others cannot, because each addresses the model at a different level of abstraction. This is the order the guided tour follows in the x-ray above.
-
ContractThe floorAn invocation contract — trigger phrasing plus an allow-list of tools. It binds to the harness, not to the prose. It decides whether this whole frame is entered at all, and limits which actions are available once it is. No other layer applies until this one matches.
-
FrameWho the model is, and what it is working towardAn identity frame ("you are a Sigil…") gives the model a persona, so every later token is generated in-character and the long file stays internally consistent. A mission objective packs the entire end-to-end deliverable into one sentence, so the goal stays in working memory across thousands of tokens.
-
StructureThe spine it can't reorderAn invariant skeleton — a fixed, numbered sequence of stages — plus an ownership partition that says who owns which artifact. Together they prevent the model from defaulting to a single freeform response and force decomposition instead.
-
DiscretionFreedom, but only along defined pathsConditional overlays ("use X when Y") and closed mode enums with defaults. Judgement is allowed — but conditioned on observed evidence, and narrowed to a small set of named choices, so an under-specified request still resolves instead of stalling.
-
ControlThe hard interruptsStop-gates: imperative blocking conditions ("Stop here until the operator confirms"). They interrupt the model's autoregressive momentum at exactly the point where it would otherwise spend tokens or spawn agents without permission. This is where the human stays in the loop.
-
ProofClaims must carry evidenceProof obligations — demands that outputs cite, validate, or leave a trace. The skill won't accept a confident-sounding answer that isn't backed. This is how "sounds right" is separated from "is shown."
-
FormThe shape it must returnThe output contract on top — the exact structure of the final deliverable. It turns a free-flowing reasoning process into something a human or a downstream agent can pick up, review, and continue.
Note the progression: from a hard binding at the floor, up through identity and structure, into bounded discretion, then back to hard control and proof, and finally a fixed output shape. The model is granted latitude precisely where latitude helps, and constrained precisely where it would otherwise drift.
The governing discipline
Source-backed vs. inferred
The x-ray separates two kinds of content, and the separation is deliberate. The quotes are source-backed — lifted verbatim from the skill file. The device labels and the "how it steers" column are inference — this page's reading of why the language is shaped as it is, not something the skill states about itself.
For example: the skill literally contains the line "Stop here until the operator confirms" — that is source-backed. Naming it a "stop-gate that interrupts the model's momentum" is inference: a useful reading, but a claim this page is making, not one the skill makes.
That separation is not presentational. It is the governing discipline.
An explanation that conflates what is established with what is conjectured is the mechanism by which confident, unsupported assertion propagates. The x-ray keeps the two visibly separate, and a rigorous reading does the same. In CyberAlchemy this principle is named claim ≤ proof: assert no more than the evidence carries. The boundary the skill enforces on the model, the explanation enforces on itself.
In the system
The same structure runs through the method.
This layering is not particular to one skill. It is the method made visible.
Consider the argument in full. The common reading held that a skill is a list of instructions. Close inspection broke that reading and replaced it: a skill is a stack of control layers, each operating at its own level of abstraction. This is not an idiosyncrasy of one file — it is what CyberAlchemy means by treating agent work as a governed artifact rather than a one-off reply.
The contract, the frame, the skeleton, the gates, the proof obligations, and the output shape are the same moves the CyberAlchemy method makes throughout: they render the reasoning reusable (the skeleton), inspectable (the x-ray demonstrated here), and improvable (alter a layer, then re-observe). The same instinct runs deeper in the system: a deterministic engine derives tests and contracts from a typed model by rule, not by guess. The x-ray simply makes one instance of that structure visible in a single view.
Read one skill as strata and the system becomes readable. Every capability in the registry is built the same way.
The /refine skill
The capability x-rayed above — and the rest of the registry, built the same way.
The System
How DomainSpec, Arcanum, and Saturn fit together into one closed loop.