The_Prompt_Engineering_Frame_Was_Always_Temporary

In April 2026, a paper out of arXiv introduced Skill Retrieval Augmentation - the idea that agent capability should be encoded as discrete, retrievable skills rather than monolithic prompts. At runtime, relevant skills are retrieved from a large skill corpus and injected into context. The agent doesn't need to carry everything it knows all the time. It pulls what it needs for the task at hand.

The paper treats this as a systems architecture proposal. I read it as a vocabulary update. Because the structure it's describing - discrete capability definitions, distributed across locations, retrieved by context rather than bundled by default - is what I've been running for months. I just wasn't calling it that.

The canonical move in prompt engineering is to reach for the system prompt when you want the model to behave differently. You write better instructions. You structure them more carefully. You test which phrasing produces the output you want. The whole field is about crafting the signal that goes before the conversation.

That frame worked when agents were single-task tools. It starts to fail when agents run across multiple projects, interact with other agents, need context that changes depending on what they're touching. A system prompt that governs everything flattens all the variation; a system prompt that tries to account for all the variation exceeds the cognitive load ceiling before it's half-written.

The CLAUDE.md rule cascade was the first real correction to this. Instead of one prompt that does everything, you build a hierarchy: a global file that sets the baselines, project files that override where necessary, scoped rules that activate only when the agent is in a specific directory. The capability is still defined in text. But the structure changes from "one big instruction block" to "an inheritance tree." The rules that govern how Nix commits code in the FitChecker repo are not the same rules she reads when she's working in the Labs repo, even though she's the same agent both times. The deviation is explicit: "Override: this project uses manual versioning steps" - one line that states the divergence without restating the entire git workflow.

That's already not prompt engineering. That's a governed rule system. The unit of capability has shifted from the prompt to the rule.

Where_Skills_Actually_Live

The SRA paper models skills as embeddings in a vector store. The unit is portable, retrievable, composable. Reasonable architecture for a system being built from scratch. But before you design the container, you need to answer a prior question: what is the capability's cadence?

Not all capability should be retrieved on demand. Some rules need to be active on every single turn. Some procedures should fire only when invoked. Some checks shouldn't involve the model at all. When you force everything into a single skills directory, you lose the distinction between these modes - and you pay for it in cognitive overhead, latency, and correctness.

The useful frame isn't "where do skills live" but "what load profile does this capability have?" The answer determines the surface.

CLAUDE.md cascade - always-on rules. The global file and its project-level overrides are loaded on every turn, by every agent, in every context. This is the right home for capability that must be universally active: UK English spelling, the no-any TypeScript rule, the conventional commits requirement, the voice vocabulary that can't slip even once. These aren't retrievable on demand because they can't afford to be missing on the turn you forgot to retrieve them. The cascade is a skill-inheritance system - global rules as base capability, project files as specialisations, scoped overrides as the narrowest definitions - but its defining property is that it's always loaded.

Skill files (SKILL.md) - on-demand procedures. Some capability is expensive to carry all the time but must be executed precisely when invoked. The handoff procedure is a clean example: a multi-step process for writing session state, cross-linking scopes, and surfacing blockers. It doesn't need to be in context when Nix is reviewing a PR. It needs to be in context when a session is ending. A SKILL.md file loads just-in-time - either explicitly invoked or matched by the agent's recognition that this moment calls for it. Routine prompts (routines/*.md) follow the same pattern: scheduled invocations of formalised capability, each file a standing instruction with a trigger condition rather than an ad hoc prompt.

Hooks - automated, model-free. Some capability shouldn't involve Claude at all. A pre-commit hook validating that manifest files aren't missing, or a CI check enforcing that test coverage hasn't dropped below the ratchet threshold - these are event-fired, shell-level triggers. Forcing them through the model adds latency and a failure surface with no benefit. The capability is still encoded and retrievable by humans reading the repo; it's just not retrieved by the agent at runtime because the agent isn't the right executor.

Subagents - delegated, scoped execution. When a task requires domain specialisation - a QA pass after a code change, a voice check before content goes live, a security audit against a specific surface - spawning a specialist agent is the right architecture. The specialist carries its own scoped tools and persona definition. The capability is real and precisely bounded; it runs in a separate context by design, not because context was tight.

Here's what this looks like across the actual stack:

The voice system (voice-system.md) lives in the CLAUDE.md layer - not as a file in a skills directory, but as a cross-project document loaded whenever an agent produces public-facing copy. The reason isn't just that it's "important." It's that voice rules need to be active on every turn a drafting agent takes. A brand slip isn't recoverable by retrieving the rule after the fact. The load profile mandates always-on.

Agent persona definitions (Team/*.md) sit at the boundary between always-on and on-demand. The scope contract - what Nix owns, what Vera declines, where each agent's capability ends - is loaded when the agent is invoked. Twelve agents, twelve skill definitions, each encoding capability and its limit in the location where the agent's operational context is established.

Module manifests (manifest.yaml per repo) are on-demand: an agent navigating to a module reads the manifest before the code. The rate limiter's manifest documents that it fails closed when Redis is unavailable. That sequencing is structural - the skill definition arrives before the implementation, and co-location enforces it. A centralised skills store breaks this: you'd have the capability definition elsewhere and the implementation here, with no structural guarantee that anyone reads one before the other.

Briefs (Owner-Inbox/{project}/briefs/) are skill specifications for one-off operations. The spec-before-code requirement means any change touching more than two files needs a brief: task description, affected modules, delegate, acceptance criteria. The brief defines the capability for that operation - who can do it, what they need to know, what success looks like. It's not retrieved at runtime; it's read at the start of the task and governs the work.

None of these files is labelled a skill. All of them are encoding discrete capability in a location matched to its load profile.

Why_Distribution_Is_the_Right_Architecture

The SRA-style centralised skills store has an obvious appeal - one location, queryable by vector similarity, portable across systems. That's worth building if you're starting from scratch with retrieval infrastructure.

But the centralised model has a structural problem: it treats all capability as retrieval problems. Some capability isn't. A voice rule that fires on every turn isn't a candidate for vector retrieval - the retrieval step itself introduces the failure mode you're trying to eliminate. A manifest that governs how an agent touches a specific module is most correctly placed in the module's directory, not in a remote store the agent has to remember to query. These aren't edge cases; they're the majority of what a real system runs on.

Distribution isn't a compromise imposed by organic growth. It's a consequence of load-profile correctness: skills that live in the right surface for their cadence are harder to misapply, easier to maintain, and naturally retrieved by the agents that need them - or bypassed by the agents (and automated systems) that don't.

There's a second argument for distribution: capability inherits meaning from its location. The voice system isn't just a file of rules. It lives in the same directory as the agent roster, the routing map, and the cross-project decisions log. When Vera reads it, she reads it in the context of who the agents are, how they coordinate, and what decisions have already been made about the brand. The location is part of the skill's context. A centralised skills store severs that relationship - you'd have the rule in one place and its surrounding rationale nowhere near it.

The CLAUDE.md cascade makes this concrete in a different dimension. A scoped rule about admin module conventions only loads when the agent is in the admin directory. It doesn't exist as noise in every other context. You don't build this with a centralised store - you build it with an inheritance system sensitive to where the agent is working and what it's currently touching.

What_This_Means_for_Builders

When the next "skills" abstraction ships - whether it's SRA-native tooling, OpenClaw-style community skill libraries, or something Anthropic builds directly into the agent runtime - the question builders will face is: where do my skills live?

The wrong version of that question is: which directory do I put them in?

The right version is: have I already defined what my agents can do, in a form that's coherent and locatable wherever capability needs to be established?

If the answer is no - if agent behaviour is currently governed by one large system prompt, or by rules that are duplicated across projects with no inheritance structure, or by conventions that exist in someone's head but not in any file - then the skills problem is real. The abstraction, whatever form it takes, won't help. You'll be migrating undefined capability into a new container, which is just the same absence with a new file format.

If the answer is yes - if your agents operate against a rule hierarchy, if the scope contracts are written down, if the voice and operational knowledge live in files that agents actually read - then you're already running a distributed skill architecture. The vocabulary from the SRA paper names what you built. The community skills libraries that emerge next will be extensions of a structure you already have.

The unit of agent capability has been shifting for a while. Prompt → rule → skill is not a dramatic discontinuity. It's a progression toward smaller, more composable, more precisely located definitions of what an agent knows how to do. The builders who are already working at that level of definition won't need to rebuild. They'll need to recognise what they have.