Where the Skill Stops and the Project Begins

I noticed it on the second project. The first project, it had been invisible — there was only one Claude project, the V8 Global one, and the skills I’d built for it slotted neatly into the work. The persona-alan skill produced Alan-voice content. The outreach-intelligence skill ran outreach messages. The proposal-workflow skill drove proposal builds. Triggered, loaded, executed. Clean.

Then I opened a second Claude project for V8 Nexus, the community side run by Gina, and the same skill library produced something subtly off. Not wrong — the voice mechanics still worked. But the persona-alan skill, the one designed for the V8 Global commercial side, was carrying assumptions about audience and platform and topic scope that it should not have been carrying. The voice fit. The context did not. And when I checked, I realised those assumptions had been quietly written into the skill itself — Alan-voice for LinkedIn, Alan-voice with V8 Global’s audience in mind, Alan-voice for technical-build content.

That was the trigger.

What the Off-the-Shelf Pattern Does

Anthropic’s skills feature is a file-based primitive. You write a SKILL.md that contains a description and a body. Claude reads the description on every relevant request and loads the body when the trigger condition matches. The skill executes against the current task. The pattern is straightforward and it works for most cases.

The implicit assumption is one-skill-one-task. Skill loads on trigger, does its work, returns. The skill is self-contained — it has everything inside it that it needs to produce the right output for the task at hand.

This is right for most of what skills are used for. A skill that fills PDFs only needs to know how to fill PDFs. A skill that creates Excel files only needs the Excel logic. The context the skill operates in does not change from request to request in a way that affects how the skill should behave. The skill is the work.

But the personas, the workflow skills, the content production skill — those are not the work. They are primitives. They produce different outputs depending on what they are being asked to produce them for. Alan-voice on LinkedIn is different from Alan-voice in a client proposal. Alan-voice for V8 Global is different from Alan-voice for a future client engagement where Alan is the architect, not the front-facing operator. Outreach intelligence on V8 Global’s behalf is different from outreach on behalf of a different organisation entirely.

The off-the-shelf pattern said: write one skill, bundle the context inside. The work I was actually doing said: that breaks the moment you have more than one project.

The Architectural Decision

I split skills from projects.

Skills became pure primitives. The persona-alan skill stopped carrying assumptions about platform, audience, or topic. It defined Alan’s voice — register, rhythm, vocabulary, instincts on the page — and nothing else. It explicitly stated that platform defaults, audience context, and topic scope come from the project, not from the skill.

The project overlay became the routing layer. The V8 Global project knows what platforms it operates on, what audiences it serves, what topics are in and out of scope, what its brand voice constraints are. When a content task fires inside V8 Global, the project routes the persona-alan skill to produce Alan-voice content shaped by V8 Global’s specific context. When the same skill is invoked inside a client project, the project routes it differently — same voice underneath, different platform defaults, different audience, different topic scope.

The two layers do different jobs. Skills define the what. Projects define the where and how. The boundary between them is where the routing happens.

Putting it in writing later, the persona-alan skill ended up with this sentence at the top: “This skill defines his voice only. Platform defaults, audience context, and topic scope are defined by the active project overlay.” Every persona skill ended up with a version of that line. The discipline of writing it forced the discipline of keeping the skill clean.

What It Looks Like Now

The library has fourteen skills. None of them carry project context. The persona skills define voice. The workflow skills define process. The platform skills define platform-specific norms. Each skill is small, focused, and reusable across multiple projects without modification.

Each Claude project I run is a different overlay. V8 Global routes the skills for the commercial-side work. V8 Nexus routes them for the community-side work. Client projects route them for the specific client’s deployment. The same persona-alan skill runs in all of them, doing different work in each, without drifting from itself.

When I deploy a new project — a new client, a new internal initiative — I do not rewrite skills. I write a project overlay that routes existing skills to the new context. The skill library is the substrate. The project is the routing decision.

The Mechanism Underneath

Looking at this with the discipline I apply to V8’s client builds, the architecture is the same shape. The skill is the reasoning primitive — the part of the system that does interpretive, voice-driven, contextual work that cannot be reduced to a rule. The project overlay is the mechanism — the part of the system that routes which primitive applies and how the output should be shaped. Mechanism on the outside, reasoning on the inside. The mechanism does the routing decision deterministically. The reasoning happens only inside the bounded scope the mechanism defined.

This is the same architecture V8 builds for clients. Workflow scaffolding at the top — rules, routing, deterministic logic. LLM reasoning called precisely where the workflow needs interpretation. The reasoning step is scoped tightly by the mechanism around it. The mechanism is what makes the reasoning trustworthy in production.

I did not set out to build V8’s own internal Claude setup this way. I built it that way because the alternative did not work past the first project. The discipline emerged from the failure mode, not from a theoretical preference. That is usually how this works. You build something, you ship it, you watch it break under load, you redesign the boundary, you ship again. The architecture that survives is the one that has been through the break.

The skill library is now stable in a way the first version was not. Each new project is faster to set up than the last. The primitives compound. The routing decision lives where it should live — at the project boundary, not inside the skill. That was the trigger and that was the fix.