Why Skills Beat Long System Prompts

A skill you never trigger costs you about 50 tokens. A system prompt you never need costs you all 8,000 of them, on every single turn, forever. That asymmetry is the whole argument, and once you see the numbers, stuffing everything into one giant prompt starts to look like what it is: paying rent on rooms you don't enter.

The wall of text problem

The naive way to make Claude "know" something is to paste it into the system prompt. Your writing style guide, your company's positioning, your investing thesis, your calendar conventions, all of it, front-loaded. It works in a demo. Then you use it for real work and three problems show up.

First, cost. An 8K-token prompt wall is prepended to every request. Over a 40-turn Claude Code session, that context is re-sent (or at best cache-read) dozens of times, and it crowds the window whether the turn is about your writing voice or about a failing TypeScript build. Prompt caching softens the price but not the second problem.

Second, attention. Models weight instructions unevenly across a long context. Bury "never use em-dashes" at token 6,200 of an 8K wall, between your fundraising history and your calendar preferences, and compliance gets probabilistic. Instructions compete. The more you add, the less each one is worth.

Third, maintenance. A monolithic prompt has no structure to edit. Changing one behavior means re-reading the whole wall to check you didn't contradict paragraph four. Nobody does this. Prompt walls only grow.

How skills actually load

A Claude Code skill is a directory with a SKILL.md at its root. The file has YAML frontmatter with two required fields, name and description, followed by the instruction body:

persona-lautaro/
  skills/
    writing-voice/
      SKILL.md
      references/
        blog-corpus.md
        banned-phrases.md

The loading model is three tiers, and the tiers are the point:

Tier 1: the description. At session start, Claude sees only the frontmatter of every installed skill. Name plus description, roughly 50 to 100 tokens each. Ten skills cost you under a thousand tokens of standing overhead. This is the index, not the content.

Tier 2: the SKILL.md body. When a request matches a description ("write this in my voice", "advise this founder"), Claude loads the full SKILL.md for that skill only. A well-written body is a few hundred lines: the decision rules, the voice constraints, the frameworks. Everything else stays cold.

Tier 3: references/. The SKILL.md can point at files in a references/ directory: a corpus of past blog posts, a table of portfolio companies, a style checklist. Claude reads them with ordinary file reads, only when the task at hand needs that specific material. A 30K-token essay corpus costs zero until the moment a ghostwriting task actually requires studying it.

This is progressive disclosure. The same principle that makes good documentation readable makes skills cheap: show the table of contents always, the chapter on demand, the appendix almost never.

The token math, concretely

Take a persona with five domains of knowledge: writing voice, founder advice frameworks, company context, investing thesis, scheduling preferences. Call it 2K tokens each if written properly.

As a prompt wall: 10K tokens on every turn. A 50-turn session touches that context 50 times.

As five skills: roughly 400 tokens of descriptions always resident. A session where you only ghostwrite loads the writing skill body (say 1.5K) once, plus maybe 4K of reference corpus for that one task. The other four domains never enter the window. You went from 10K standing overhead to 400, and paid for depth only where the work happened.

The kicker is that the skill version can afford to be bigger. Because references/ is free until read, you can ship a 40K-token blog corpus inside a skill, something no sane person would paste into a system prompt. Progressive disclosure doesn't just cut cost, it raises the ceiling on how much a persona can know.

The description is the routing layer

The description field does the work a prompt wall can't: it tells the model when to care. Compare:

description: Lautaro's writing style.

with:

description: Invoke when the user wants Claude to write, advise,
  or decide as Lautaro Schiaffino, pulling from his operating
  history (Rodati, Sirena $30M exit, Darwin AI) and his published
  frameworks. Triggers on "as Lauta", "in my voice", "ghostwrite",
  "advise this founder".

The second one includes trigger phrases, scope, and negative space. It routes correctly. This is the craft that replaces prompt engineering: you're not writing instructions the model must hold in mind constantly, you're writing an index entry the model consults cheaply and expands precisely.

A prompt wall has no routing layer at all. Every instruction is maximally loaded and minimally targeted, which is exactly backwards.

Where this lands for personas

A person is the worst possible fit for a monolithic prompt, because a person is many contexts. How Lautaro writes a cold email, how he evaluates a seed deal, and how he runs a Monday standup are three different skills, triggered by different work, drawing on different source material. Flattening them into one wall means the standup advice contaminates the cold email and the deal memo framework leaks into the blog post.

This is why installs.me synthesizes a persona as a plugin containing multiple skills rather than one mega-prompt: each skill carries its own description, its own SKILL.md, its own references/ folder of real source material. Install it, and your context window stays lean until you ask for the person, at which point exactly the relevant slice of them shows up.

The prompt wall was a workaround for not having a loading mechanism. Now there is one. Use it.

Install a person

installs.me turns your files, calendar and calls into a Claude Code plugin that thinks like you. Anyone installs it with two commands:

/plugin marketplace add https://installs.me/lautaro
/plugin install lautaro@lautaro-installs