Every day on social media, there’s a fresh post celebrating a GitHub repository full of agent skills passing some new milestone of stars or sitting at the top of a trending list. People are trading packs of 50 or 100 skills like baseball cards.
I get why it’s happening. Compared to the MCP context bloat I complained about last November, Agent Skills are a real improvement. Instead of dumping 40 tool schemas into the context window on turn zero, skills use progressive disclosure. The harness loads a short list of skill descriptions at startup and only reads the full SKILL.md file when the task calls for it.
I use skills myself, along with the occasional Model Context Protocol (MCP) server. In fact, a skill helped me structure this post.
But much like “prompt engineering” a couple of years ago, I’m confident this express train to agentic popularity is going to be short-lived. The further humans get away from the agentic loop, the more brutally efficient we have to make that agent’s context.
The nuance: progressive disclosure assumes a human rudder
In Dan Shapiro’s Five Levels of AI coding framework, the spectrum runs from Level 1 (“spicy autocomplete”) all the way to Level 5 (the unattended “Dark Factory”). Even the most experienced agentic developers today still hang out around Level 3 on their good days. They’re managing agents in a terminal or an IDE, directing multi-file work, reviewing diffs, and nudging the session along turn by turn.
At Level 3, you are the unconscious brake pedal and rudder. When a model misinterprets a prompt, pulls in a 7,000-token community skill about “clean architecture,” and starts inventing a three-layer abstraction for a twenty-line helper, you notice. You hit Esc, tell it to stop over-thinking, and steer it back onto the road. When I’m talking to customers, I often compare it to walking an overeager puppy through a park full of distractions.
Because that human correction happens in seconds, we barely register it as work. It hides how much noise our interactive harnesses are actually carrying.
The smart money for 2027 is that humans are going to step further away from more of the agentic loops, pushing past Level 3 toward true Level 5 workflows. Take the human out of the loop, and those unconscious brake pedals disappear. If you give an unattended model an opportunity to run off into the tall grass, it will inevitably happen. And when it does, it costs you time, money, and blood pressure.
Progressive disclosure reduces the upfront token tax, but it doesn’t eliminate distraction. Every skill sitting in your global catalog still injects its description into the startup context. Every description is a doorknob in the room, inviting the model to open a door that won’t get you closer to your goal.
What wakes up on turn one
I wanted to see how wide the gap actually was between my Level 3 interactive sessions and Leaf, my local Level 5 dark software factory. So I pulled the numbers off my own laptop and out of the factory’s source tree.
First, I parsed all 385 interactive Claude Code sessions on my laptop from October 2026 and summed the input tokens on the very first assistant turn (input_tokens plus cache_creation_input_tokens plus cache_read_input_tokens). Claude is my default interactive session for getting work done. So it’s a good live average of an experience, heavy AI user. It includes everything from heavy debugging to marketing research to figuring out Christmas present ideas for my kid.
Across those 385 sessions, the median interactive session started Turn 1 at 45,136 tokens (with a minimum of 25,144 tokens, an average of 43,480, and a maximum of 60,696). Why? Because interactive harnesses front-load a massive general-purpose system prompt, built-in subagent and connector schemas, the full catalog of global skill descriptions, and whatever repo context or initial skill gets triggered on the first message.
Now compare that to what wakes up inside Leaf when a worker pod starts a node:
| Context Layer | Interactive Session (Claude / AGY) | Leaf Dark Factory (Worker Pod) |
|---|---|---|
| System Prompt | Default harness prompt (~15,000 to 20,000 tokens) | 2,666 tokens (_base.md + worker.md + engineering.md) |
Role Core (worker.md) | Bundled into general assistant instructions | 353 tokens (9 lines of markdown) |
| All 18 Role Prompts Combined | N/A | 15,511 tokens across all 11 factory roles |
| Repo Context File | Legacy CLAUDE.md files up to 8,101 tokens | Onboarded AGENTS.md trimmed to 639 to 1,910 tokens |
| Turn-1 Total Footprint | 45,136 tokens (median across 385 sessions) | ~6,200 tokens (system + AGENTS.md + 1 to 2 node skills + brief) |
Every single prompt file in my entire dark factory combined (15,511 tokens across 18 files and 11 distinct agent roles) is roughly a third of the Turn 1 context of one interactive coding session.
To be fair to the math, my file-size token figures for markdown files on disk use the standard four-characters-per-token estimate (bytes / 4), while the 45,136 Turn 1 number comes directly from the provider’s tokenizer usage logs. And as I noted in Part 4 of the Loops series, my interactive setup is already leaner than most because I keep almost no MCP servers enabled. A developer running five MCP servers and a trendy 80-skill GitHub pack is waking up well north of my numbers. No wonder the model forgets what file you asked it to edit by turn four.
Manuals vs. trap-notes
The system prompt is only half the story. The bigger surprise in my local data was the difference in how skills themselves are written for interactive work versus unattended factory work.
On my laptop right now, between my interactive Claude Code setup (34 active skills across ~/.claude/skills and four enabled official plugins) and my interactive Antigravity setup (19 global skills across ~/.gemini), I have 53 active global skills sitting on disk.
Just the SKILL.md entrypoints for those 53 interactive skills total 123,110 tokens. Once you include their companion references/ and docs/ markdown files, there are 323,249 tokens of interactive skill prose waiting to be loaded.
In my interactive Claude setup, the average SKILL.md is 2,685 tokens (median 1,964 tokens). Official plugin and synced skills regularly run the size of a short novella: skill-creator is 9,081 tokens (507 lines), pptx is 7,218 tokens, and Stripe’s connect-required-verification-information skill is 7,057 tokens. Even in this blog repository, triggering my draft-blog skill loads SKILL.md plus style_guide.md for 3,686 tokens. That single writing skill is 38% larger than an entire Factory worker’s system prompt.
Now look at the 45 skills across the 6 software repositories onboarded to my dark factory (acetag, binpacker, brandcast, brandcast-sentinel, bark-v3, and sadie):
- Median Factory skill: 954 tokens (65 lines of markdown)
- Mean Factory skill: 1,073 tokens
- Smallest Factory skill: 259 tokens (22 lines,
agent-docsinbrandcast-sentinel) - Largest Factory skill: 2,450 tokens (118 lines,
building-svg-renderersinbrandcast) - Extra reference markdown files: Just 1 file (388 tokens) across all 45 skills
Interactive skills are written like manuals.
Factory skills are written like trap-notes.
Why are community skills on GitHub so big? Because a general-purpose skill written for strangers on the internet doesn’t know your codebase, so it pads itself with tutorials, API restatements, and generic best practices. Frontier models already know how to write React components, SQL queries, and FastAPI routes from pre-training. Paying 6,000 tokens to re-explain standard library syntax doesn’t make the model smarter. It just crowds out the local constraints that actually matter.
When I onboard a repository into Leaf, the onboarding skill enforces a strict rule for what belongs in .agents/skills/<name>/SKILL.md:
- Frontmatter is `name` and `description`; the folder is named after `name`.
- The description names the paths it governs: that is how the planner matches it to a node.
- The body is what the code will not tell you: the trap, the reason, the thing that looks right
and is not. Not a restatement of the API.Even my own /leaf skill, which I use interactively to scope issues and plans for the factory, wasn’t immune. When I wrote Loops Part 4 two weeks ago, /leaf had ballooned to 7,400 tokens. Since then, I cut it down to 80 lines (1,421 tokens) by stripping out duplicated instructions and pointing directly at the factory’s core prompt files.
Subtraction is the architecture
When a pod spins up inside Leaf, it doesn’t rely on progressive disclosure to keep its head clear. It relies on architectural subtraction.
In src/runtime.ts, the factory’s container bridge strips the harness down to the studs before the first turn starts:
export function claudeArgs(o: Pick<Opts, "system" | "model" | "effort" | "tools" | "session" | "env">): string[] {
const args = [
"-p", "--input-format", "stream-json", "--output-format", "stream-json", "--verbose",
"--dangerously-skip-permissions",
// Strip default MCP servers and connectors
"--strict-mcp-config",
// Unlike an appended prompt, this replaces Claude's default identity.
"--system-prompt", `${o.system}\n\n${CLAUDE_TOOL_NAMES}`,
];
// ...
args.push("--disallowedTools", "SendMessage", "ListAgents", ...(o.env.ROLE === "foreman" ? ["Agent"] : []));
return args;
}Four mechanical choices keep the unattended loop from wandering into the weeds:
- Replace the system prompt instead of appending to it. Passing
--system-promptto Claude (ormodel_instructions_fileto Codex) wipes out the harness’s 15,000-token general-purpose persona. A worker pod gets_base.md(1,788 tokens),worker.md(353 tokens), andengineering.md(524 tokens). Nothing else. - Isolate
$HOMEinside the container. Every pod runs withHOME=/home/agent. None of the 53 global skills, plugins, or MCP configs on my laptop exist inside the container. There are no extra doorknobs to pull. - Move skill selection upstream to the Planner. A worker pod never browses a catalog of skills to decide what’s relevant. During the planning phase, the Architect/Planner matches the repository’s skills to the exact file paths a node will touch and writes
"skills": ["inventory-data", "spool-screens"]into the node contract. The worker reads only the skills named on its node. - Cut every line a reader would act the same without. That’s line six of
factory/AGENTS.md. Before a repository is onboarded to Leaf, its old interactiveCLAUDE.mdfile is often a graveyard of past incident postmortems and repetitive rules (pnc-analysis/CLAUDE.md(a small local app used to help my wife’s small business banking … lack of enthusiasm) is 8,101 tokens;brandcast-public/CLAUDE.md(the site for https://brandcast.app) is 7,942 tokens). Neither of these are currently in my Leaf factory. Onboarding cutsAGENTS.mddown to 600 to 1,900 tokens: what the codebase is, the exact shell command to run a single test file, and the architectural boundaries that would take an hour to infer from code.
So what?
If you’re only running agents interactively while you watch every turn in a terminal, a bloated skill repo mostly just costs you cache-read tokens and the occasional Esc key press.
If you’re building toward where agentic engineering is going in 2027, with humans stepping further out of the execution loop, you have to treat context like a tiny memory budget on an embedded controller:
- Stop hoarding general-purpose skills from GitHub. If a skill is 4,000 words of generic advice that a frontier model already knows from pre-training, it isn’t helping. In an unattended run, it’s just high-minded ceremony that dilutes your actual requirements.
- Write 60-line trap-notes, not tutorials. Scope every skill to specific file paths in its frontmatter description. In the body, write only what the code itself won’t tell a capable reader: the non-obvious trap, the migration quirk, or the invariant that looks wrong at first glance.
- Assign skills during planning, not execution. Don’t hand an unattended coding worker a catalog of 50 skills and hope progressive disclosure saves you. Let your planning step attach the 1 or 2 skills that govern the files being changed, and hide the rest.
- Replace the default harness bloat. When running CLI harnesses headlessly in containers, use
--system-promptormodel_instructions_fileto replace the default chat persona, disable unused connectors, and run in a clean$HOME.
The star count on a public skills repo measures how good the markdown looks to a human browsing GitHub. The only metric that matters in an unattended loop is whether the agent finishes the node without wandering into the tall grass.