A SKILL.md file with good instructions is the beginner tier of Claude Code skills, and staying there caps what skills can do for you. The advanced tier is architectural: where a skill runs (your context or a fork), what it sees (static instructions or live state), and when it works (inline or in the background). Get those three decisions right and skills stop being prompt shortcuts and start being systems.
I learned each of those decisions the expensive way. The tuition story: I wrote a research skill that pulled a GitHub repository's issue history to gather competitive intelligence before drafting an article. It worked — the way a fire hose works when you are filling a coffee cup. Forty-seven thousand tokens of raw issue data hit my main session in seconds and killed it mid-sentence. The rebuilt version of that same skill runs in its own forked context, pre-processes data through shell scripts before the model ever sees it, and executes in the background while I keep working. Token cost: about 3,200. Same output. That rebuild is the whole playbook in miniature, so let me unpack it properly.
Two kinds of skills, two different architectures
Before the mechanics, a distinction that decides everything downstream. Maintaining a 53-skill marketplace has taught me that every skill worth shipping is one of two species:
Capability-uplift skills make the agent able to do something it could not: parse a proprietary format, drive an external tool, run a domain workflow. These tend to be heavy — scripts, reference files, multi-step procedures — and they are the ones that want forking and background execution, because their working data does not belong in your conversation.
Encoded-preference skills make the agent do something your way: commit format, testing conventions, review checklists. These are light, and they want the opposite architecture — inline, always-visible, cheap. Forking a preference skill is pointless; the preferences need to live where the work happens.
Most skill-quality problems I see in marketplace submissions trace to species confusion: a heavyweight capability skill built as an inline instruction dump (my 47K blowup), or a preference skill bloated with machinery it never needed.
Context forking: give heavy skills their own room
A forked skill executes in an isolated context. It does its reading, tool-calling, and intermediate reasoning in its own space, and only the result returns to your session. The fire hose sprays into a separate room; you get the coffee cup.
When to fork, from my working rules:
- The skill ingests bulk data. Repo histories, scraped pages, long documents. Raw input should never transit your main context — that is what killed my research skill.
- The skill produces noisy intermediate steps. A multi-stage workflow with a dozen tool calls pollutes your conversation with output you will never reread but will keep paying for, because everything in context is rent.
- The skill's work is self-contained. Forking has a real cost: the fork does not deeply share your session's accumulated nuance. If the task depends on conversation history, forking is exactly wrong — I mapped that boundary in detail in my forked subagents breakdown, and the same logic governs skills.
When not to fork: quick lookups, preference application, anything where round-trip overhead exceeds the work itself.
Dynamic context injection: skills that see the present
Static skill instructions describe your project as it was the day you wrote them. Dynamic injection runs commands at invocation time and puts the current state in front of the model: the branch you are on, the files that changed, the test results from thirty seconds ago.
The pattern is mundane and powerful — the skill shells out before it reasons:
## Current project state
- Branch: !`git branch --show-current`
- Changed files: !`git diff --name-only HEAD`
- Failing tests: !`php artisan test 2>&1 | tail -20`
The deeper version of this idea is pre-processing: use scripts to reduce data before the model sees it. My rebuilt research skill does not hand Claude the issue history; a script fetches it, filters to the last 90 days, buckets by label, and emits a summary table. The model reasons over 3K tokens of structure instead of 47K of raw JSON. This is the single most transferable trick in this post: any time a skill touches bulk data, insert a deterministic reduction step between the source and the model. Scripts are free; context is not.
Combine the two — a forked skill whose first act is a reducing script — and heavyweight workflows become almost embarrassingly cheap.
Background agents: skills that work while you work
The third leg. A forked skill can run asynchronously: kick it off, keep coding in your main session, collect results when it lands. My rebuilt research skill runs this way — by the time I finish outlining an article, the competitive summary is waiting.
Background execution changes which skills are even worth writing. Anything long-running that you would previously not bother automating — nightly-style audits, bulk checks, research passes — becomes viable because it no longer holds your session hostage. The operational habits that matter: give background skills explicit completion criteria (more below), have them write results to a file rather than only returning prose, and check on them rather than awaiting them. My broader notes on async and background agents in Claude Code cover the orchestration side.
The three patterns that separate working skills from toys
Whatever the architecture, the SKILL.md content follows rules I now apply to every skill I ship to the marketplace:
Specificity over volume. A 40-line skill with exact commands, exact file paths, and exact output format outperforms a 400-line essay. Models follow concrete instructions and skim abstract ones — the same as junior engineers.
Exit conditions, not just entry conditions. Every skill states what "done" means and what to do when done: where the output goes, what format, what to report. Skills without exit conditions produce agents that keep helpfully doing things. My worst background-agent incidents were all missing exit conditions, not bad logic.
Error recovery instructions. What should the skill do when the API call fails, the file is missing, the test suite will not run? Unstated, the answer is "improvise," and improvisation with your permissions is not a feature. Two or three lines of "if X fails, stop and report Y" convert flaky skills into dependable ones.
Test skills like software, because they are: invoke them against a contrived scenario, check the output against the exit conditions, and rerun after every edit. The skill-creator tooling can scaffold this loop, and it is the part everyone skips right up until a skill misfires inside real work.
Quick answers
What is context forking in Claude Code skills? Running a skill in an isolated context so its data-loading and intermediate steps never enter your main session; only the final result returns.
When should a skill run in the background? When it is self-contained, long-running, and produces a result you can consume later — research, audits, bulk processing. Interactive or nuance-dependent work stays inline.
How do I stop a skill from eating my context window? Fork it, and put a reducing script between the data source and the model. Raw data into a model context is almost always a design smell.
Do these techniques apply to marketplace skills or only custom ones? Both — but you will mostly meet them writing your own. If you are still choosing your foundation set, start with the skills actually worth installing and graduate here when the basics stop being the bottleneck. The craft lessons from shipping skills to real users are in what building Claude Code skills taught me.
The advanced tier is not clever prompting. It is boring systems discipline — isolation, reduction, explicit contracts — applied to instruction files. Skills built that way hold up when the task gets real, and the ones that are not fall over exactly when you need them.
I design skill architectures like these for teams shipping real agent workflows — if yours are still at the prompt-shortcut stage and you want the systems version, get in touch and tell me what your agents need to do.
