4.5 Packaging the Method as Skills

The method so far has been described as engineering practice: model the relevant knowledge, place authority around stable obligations, evaluate work with independent evidence, and convert recurring judgment into durable structure. Some of that recurring structure can itself be packaged for agents.

A skill is one way to package that structure for an agent. It can carry knowledge, examples, heuristics, decision procedures, triggers, and tools so that a fresh agent does not begin every session cold. A well-maintained skill can become engineering capital when later work benefits from inheriting the packaged judgment enough to justify its creation and upkeep.

Do not confuse packaging with authority. A skill made only of prose is reusable guidance. If it invokes a deterministic checker, restricts an action, or participates in a gate, the surrounding machinery may also carry authority. The distinction from Part III still applies after the procedure is packaged.

The companion repository demonstrates the architecture through three mastery skills: self-governance, self-operate, and self-communicate. Together they show one portable way to preserve recurring engineering judgment.

Tool skill. Teaches an agent how to operate one interface.

Mastery skill. Packages domain knowledge plus a repeatable decision procedure for doing a class of work well, independent of one particular tool.

A mastery-skill specializes commodity intelligence with domain-specific engineering judgment: it gives a fresh agent the abstractions, distinctions, and practices an experienced engineer would bring to the work.

Recent industry examples show related packaging moves.^** Atlassian's Jira team reports a related move: it delegates keep-the-lights-on work — flaky tests, feature-flag cleanup, vulnerabilities, accessibility — by turning each into an explicit work item that carries context plus workflow instructions, so a maintenance class becomes delegable once the tacit repair procedure is encoded, not because the agent got clever ²2. Atlassian, “AI Agents for Jira Engineering Maintenance,” Atlassian, 2026, https://www.atlassian.com/blog/development/ai-agents-jira-engineering-maintenance.. Twilio's public account is sharp: an unguided agent asked to "verify users" hand-rolls a six-digit one-time password, while its skill redirects to a dedicated verification product and inherits rate limiting, fraud controls, and routing the operator never thought to request ¹1. Twilio, “Why Connect Twilio AI Skills,” Twilio, 2026, https://www.twilio.com/en-us/blog/developers/best-practices/why-connect-twilio-ai-skills.. The encoded procedure is the capital; the class of work becomes inheritable.

4.5.1 The Skill Skeleton

The three examples share a construction pattern, drawn in Figure 4.5-1. A mastery-skill begins with a fundamental model: the abstraction through which the domain makes sense. Orthogonal facets capture independent concerns within that domain. A governing principle connects them and tells the agent how to reason across the whole: when to invoke each facet, what questions to ask, which tools to use, and what output must be returned.

The portable idea is the skeleton: tacit practice becomes a bounded reasoning environment that a new agent can enter repeatedly.

4.5.2 Deliver the Right Context—and Measure It

A reusable procedure helps only if the actor reaches it when it matters. Packaging knowledge is not enough; it has to reach the reasoner when relevant, without drowning the reasoner in everything else.

The naive answer is to load everything: put every rule, architecture note, failure lesson, tool instruction, and procedure into the agent's standing context and trust attention to sort it out. That merely moves the navigation problem.

A better pattern separates what should remain continuously salient from what should appear only when the work makes it relevant. Dynamic context injection (DCI) is one realization: the environment observes properties of the task, work surface, or lifecycle state; selects the engineering knowledge relevant to those properties; and places that knowledge into the agent's working context. The trigger might be a file being changed, a component being entered, or a lifecycle transition being reached. The injected material might be a model slice, local constraint, procedure, example, or other guidance. The general pattern is shown in Figure 4.5-2.

Standing context should contain the mission, compact method, and the few policies whose salience must survive every task. Retrieve richer model slices, procedures, examples, and local constraints according to the work. Where relevance can be determined mechanically, inject the appropriate slice rather than relying on the actor to discover and retrieve it.

But context has a cost. More guidance is not automatically better guidance. It consumes tokens, attention, and reasoning capacity, and stale guidance can actively misdirect work.

So treat context delivery as an engineering intervention and measure its effect. Compare performance with and without the added context. Measure task success first; then use diagnostic measures — tokens, navigation steps, tool calls, files opened, retries, or time — where they illuminate why performance changed. A context mechanism that consumes more reasoning budget without improving the engineering outcome has not earned its place.

The model-based software-engineering pilot is one example: run the same task against different model-and-context conditions and reasoner classes, and ask whether the supplied representation actually changes navigation cost or task success. What is portable is the discipline of testing whether engineered context does what we claim it does. Part V carries that pilot with its data and its limitations.

Context delivery changes what the reasoner can see; by itself, it does not change what the environment permits. A richer slice of the right rules makes a good action easier to find; only a constraint, validator, or gate makes a bad action unavailable.

4.5.3 Self-Governance: Engineering the Environment

Self-governance packages Modeling and Alignment as a procedure the agent can apply to its own engineering work. Recognize the situation, decide what to model and what to make authoritative, choose a move, act through the environment, weigh the evidence, and keep what should be inherited. Converting a recurring failure is one branch of that loop, not its definition. A recurrence is evidence the environment may be missing something durable — but the missing thing is not always a new control. It may be a model, an explicit obligation, better evidence, a validator, a constraint, a gate, or simply a decision procedure worth preserving.

The skill carries a model of the engineering method rather than a catalogue of preferred controls. Its fundamental model is the Modeling–Alignment loop; its facets organize the recurring questions the agent must answer to apply that loop: what to represent; how the representation corresponds to the system; what evidence exists; what authority is justified; how changes should be introduced; and when existing structure should be reconciled or retired. Where useful, the skill can query the environment's governance catalogue of existing mechanisms. Concrete system knowledge comes from the models and tools of the environment rather than being embedded in the skill. Its value is to give a fresh agent MAGE-specific judgment without embedding knowledge of the particular system in the skill itself.

The project's boot context can preserve mission, method, and concise rules, but treat those rules accurately. Mission orients. Method teaches judgment. Rules state project policy. They bind only where an environmental mechanism gives them consequence. A numbered sentence in an always-loaded file is still guidance unless something outside the producing agent enforces it.

Underneath the method sit the operating rules the skill applies on every touch, the same set the companion skill carries:

Self-governance — operating rules

• Model before guessing. Reach concrete system knowledge through a provider; do not reconstruct it from memory or raise confidence by rhetoric.
• Ask what should become machinery. At every failure, ask whether the lesson is durable — and default to nothing.
• Method before tool. Choose the move the situation calls for, then the capability that performs it.
• Right-size the fix. Prefer the smallest sound change that closes the class; propose a larger intervention rather than installing it reflexively. Prefer prevention where the legitimate action space can honestly be narrowed.
• Escalate a genuine judgment, not an inconvenience. A real authority-or-consequence boundary earns a prepared decision handed upward; a merely hard problem does not.

A skill on its own is passive: it sits and waits to be invoked, and an agent heads-down in the work will not stop to invoke it. A hook brings the skill into the work while the evidence is still fresh enough to diagnose the episode; the skill applies the MAGE procedure to the episode and surfaces the relevant design forks — "we keep hitting this; here are two ideas, which should I try?" — then waits. It may recommend changing a model, an obligation, evidence, a mechanism, or nothing at all. The engineer retains the judgment about what matters enough to preserve.

Governance must earn its carrying cost

Governance mechanisms and other durable engineering assets can become capital when their continuing value exceeds their carrying cost; they can also depreciate. Over-investment turns governance maintenance into its own recurring cost. Three symptoms say the return has gone negative: upkeep crowds out product work; the checks cry wolf, flagging more than they catch; or the guarded failure is both cheap and rare. Each is a control whose upkeep outweighs its benefit. Size it the way Migrating to MAGE sizes any control — against the cost and the frequency of the failure it prevents — and retire the assets that no longer earn their cost.

Even a soft mechanism can be governed like a hard one. NVIDIA's public account describes treating a skill as a deployable capability rather than a static prompt, run through an eight-stage supply chain — source, review, scan, evaluate, skill card, sign, catalog, sync — where scanning looks for agent-specific threats (hidden instructions, trigger abuse, excessive agency, tool poisoning, purpose/access mismatch), not only conventional software risk ³3. NVIDIA, “NVIDIA Verified Agent Skills Provide Capability Governance for AI Agents,” NVIDIA, 2026, https://developer.nvidia.com/blog/nvidia-verified-agent-skills-provide-capability-governance-for-ai-agents/.. The prose is a reusable knowledge asset; the signing and gating around it add authority to its distribution and use.

4.5.4 Self-Operate: Running the Environment

Self-operate packages the previous chapter's lifecycles, recovery paths, runbook step types, and operating heuristics. Its fundamental model is the operational lifecycle; supporting facets distinguish the lifecycle class a symptom belongs to, the typed runbook action, and the trigger that fires it. Its procedure tells an agent how to orient against the healthy path, run deterministic steps through tools, dispatch delegable judgment with a prepared brief, and surface irreducible judgment to the operator.

The skill is useful because operating procedure otherwise has to be reconstructed at every fresh session. It does not replace the underlying tools, state machines, validators, or gates. It makes their use repeatable.

Its boundary with self-governance is explicit. Self-operate routes an operating condition to a typed runbook and runs it; when a condition instead exposes a deficiency in the models, mechanisms, skills, or lifecycle itself, self-operate returns the engineering problem — with evidence, not a redesign — up to self-governance. It runs the environment; it does not re-engineer it.

The two mastery skills divide the work by the question each answers. Table 4.5-1 sets the split side by side.

The interface is two-way and explicit: self-governance delegates execution downward; self-operate returns engineering problems upward. Neither absorbs the other: self-governance decides how a mechanism should exist; self-operate uses it at runtime.

4.5.5 Self-Communicate: a Boundary Test

Self-communicate packages a different craft: engineer-facing prose and technical drawing. Its value here is as a boundary test for the architecture. Governance and operations sit close to the method's core; technical communication is farther away, yet the same skeleton still works — a domain model, orthogonal representations of the craft, and a decision procedure that tells the agent how to apply them.

Self-communicate is not a third pillar of MAGE; it shows that the same skill architecture can extend beyond governance and operations. The appendix and companion repository carry the procedure itself.

Reusable agent procedures can become engineering capital when later work inherits them, and the industry is finding the pattern in parallel. Part V's MAGE in the Wild sets six such systems side by side.