Field report · · AgentConn Team
Stackable Skills: One Prompt, Your Whole Team
Composition patterns for agent skills — when stacking beats one fat skill, ownership rules, and why double-runs silently break pipelines.
Stackable Skills: One Prompt, Your Whole Team
Bolt shipped stackable team skills today. One prompt, every skill on your team fires. The feature dropped without much fanfare — a tweet from @boltdotnew, a repost from @_akhaliq — but the implications land harder than the announcement suggests. Because “one prompt fires everything” is exactly the pattern that separates teams running ten skills cleanly from teams drowning in silent double-runs, context collisions, and a harness that degrades under its own weight.
The agent-skills explosion solved availability. 500,000 GitHub stars across three repos. Over 280,000 public skills indexed. The Cambrian phase is over. What it did not solve is composition — the problem of making skills work together rather than merely work alongside each other.
This is an operator article. If you have 10+ skills and you are hitting orchestration mess — steps running twice, skills stomping each other’s output, context windows bloating because every skill dumps its full prompt — this walks through the composition patterns that actually hold up, the ownership contracts that prevent collision, and the research that explains why flat invocation was never going to scale.
The Research Frame: Self-Improvement Is a 1991 Idea
The timing of Bolt’s feature is coincidental but instructive. The same week, Schmidhuber and eleven co-authors published a 97-page survey — Self-Improvements in Modern Agentic Systems — that formalizes exactly what skill composition is doing at the harness layer.
The survey’s core model is clean: an agent is a dual-component system coupling foundation model parameters with operational scaffolding — prompts, memory, tools, and control logic. Self-improvement is a self-induced update operator that modifies either the model or the scaffold. Skills are scaffold components. Composing skills is scaffolding improvement. Schmidhuber traces this lineage back to Godel machines and meta-learning from 1991.
The practical translation: when you stack three skills and the harness picks the right one per subtask, you are doing scaffolding-level self-improvement. Not because the model got smarter, but because the system around the model got more capable. The ArXivIQ analysis put it directly: “self-improving agents continuously rewrite their own logic — they must be treated as untrusted code execution engines.”
That framing matters for operators. A composed skill stack is not just a convenience feature. It is a system that modifies its own execution path based on what it encounters. The failure modes are recursive, not linear.
Why Flat Invocation Breaks at Scale
The most important empirical result on skill composition came from the AgentSkillOS paper in March 2026. The researchers tested skill execution across ecosystems of 200 to 200,000 skills and found a result that should be on every operator’s wall:
DAG-based orchestration substantially outperforms flat invocation — even when given the identical skill set.
Read that again. Same skills. Same model. The only difference was how the skills were composed. Flat invocation — where the harness dumps all retrieved skills into the prompt and lets the model sort it out — produced measurably worse results than structured DAG composition that managed execution order, dependencies, and data flow.
Key finding from AgentSkillOS: The bottleneck has shifted from skill availability to skill orchestration. Flat agents dump all retrieved skills into the prompt, causing distraction and hallucinated action sequences. DAG compilation acts as a structural filter to exclude irrelevant skills. The gains are not marginal — they are structural.
This matches what Addy Osmani documented in The Code Agent Orchestra after his O’Reilly AI CodeCon talk. His framework identifies the core coordination hazards: “Never let two agents edit the same file. Conflicts kill velocity.” His three-pattern framework — subagents, agent teams, and the Ralph Loop — all share one assumption: composition requires explicit ownership boundaries. The model will not infer them.
Three Composition Patterns That Hold Up
After reviewing the AgentSkillOS results, Osmani’s orchestration tiers, and the practical lessons from teams running 10+ skills, three patterns emerge as production-viable.
Pattern 1: Sequential Pipeline (Chain)
Skills fire in order. Each skill’s output feeds the next skill’s input. The simplest pattern and the one most teams should start with.
When it works: Linear workflows where each step depends on the previous one. Code review pipelines. Research-then-write sequences. Build-test-deploy chains.
When it breaks: Any workflow with steps that could run in parallel. The pipeline serializes everything, and a slow skill in position 3 blocks skills 4 through 10 even if they have no dependency on skill 3.
Ownership rule: Each skill owns a defined output artifact. Skill N reads from skill N-1’s artifact and writes to its own. No skill reads or writes artifacts owned by non-adjacent skills.
Pattern 2: Fan-Out / Fan-In (Parallel Composition)
A coordinator decomposes the task, fans out to specialized skills running in parallel, then fans in the results.
When it works: Tasks with independent subtasks. Multi-file code changes where each file has its own specialist skill. Research tasks where different skills query different sources simultaneously.
When it breaks: When the subtasks are not actually independent. If skill A and skill B both need to modify db.js, you get write conflicts — Osmani’s “conflicts kill velocity” warning. Also breaks when the fan-in step cannot reconcile contradictory outputs from parallel skills.
Ownership rule: File-level or artifact-level locking. Before fan-out, the coordinator assigns each skill a non-overlapping file set. Git worktrees enforce this at the filesystem level.
Pattern 3: DAG Composition (Directed Acyclic Graph)
The most flexible pattern and the one AgentSkillOS proved outperforms the others. Skills are nodes in a graph. Edges encode dependencies. The orchestrator executes skills in topological order, parallelizing where the graph allows.
When it works: Complex workflows with mixed dependencies. A code change that requires linting (independent of tests), testing (depends on build), documentation (depends on code change), and PR creation (depends on all three).
When it breaks: When the DAG has cycles — which means you have a design problem, not an orchestration problem. Also breaks when skills have undeclared side effects that create implicit dependencies the graph does not encode.
Ownership rule: Every skill declares its inputs and outputs explicitly. The orchestrator builds the graph from these declarations. Undeclared side effects are the primary source of DAG failures.
The Double-Run Problem: Composition’s Quiet Killer
Here is the failure mode that nobody talks about until it bites them. When you stack skills and fire them from one prompt, two skills can independently decide they need to run the same preparatory step. Skill A runs npm install. Skill B also runs npm install. Maybe that is harmless. Maybe it is not — if A installs a specific version and B overwrites it with latest, you have a silent version conflict that manifests three steps later as a test failure with no obvious cause.
The double-run problem is worse than it sounds because it is invisible. Both skills complete successfully. Both report success. The conflict only surfaces downstream, and by then the execution trace is too long to debug efficiently.
This is the practical expression of what Schmidhuber’s survey calls the “scaffold update problem” — when multiple improvement operators target the same scaffold component without coordination, the result is undefined. The survey proposes formal update semantics. Operators need something simpler: three mechanical rules.
Three Rules That Prevent Double-Runs
1. Idempotency contracts. Every skill must declare whether its setup steps are idempotent. npm install from a lockfile is idempotent. npm install latest is not. The orchestrator should deduplicate idempotent steps and sequence non-idempotent ones.
2. Ownership declarations. Each skill publishes a manifest of what it reads, writes, and executes. The orchestrator validates that no two skills in the same stack claim write access to the same resource without explicit conflict resolution.
3. Step hashing. Before executing a step, the orchestrator hashes the step’s command and inputs. If a previous skill in the stack already executed an identical step (same hash), skip it. This catches the npm install case mechanically rather than relying on skill authors to coordinate.
The Contrarian Corner: Most Skills Are System Prompts With a Name. An analysis of 881 ClawHub skills found that 46% scored poorly on functional depth. The observation was damning: “Claude performed identically with or without these poorly-designed skills.” Composition amplifies mediocre skills — it does not fix them. Before you invest in a composition layer, audit your skills for functional depth. Stacking ten skills that each do nothing meaningful gives you a very sophisticated way to do nothing.
The Orchestration Layer Is a Control Point
Elvis Saravia flagged the strategic dimension of this problem in a thread about Cursor Router: “Is anyone building this open-source? It feels like this is something you don’t want to offload to an API.”
His point applies directly to skill composition. The orchestration layer sees every skill invocation, every input, every output. It decides execution order and can suppress or inject steps. Whoever controls the orchestrator controls the behavior of every skill in the stack. For teams running sensitive workflows — code that touches production, agents that access customer data — outsourcing the orchestration layer to a vendor API is handing them a control point over your execution pipeline. This is the same argument we made about the harness being the real guardrail stack, applied one layer up.
David Ha from Sakana AI made the broader case: “The future is defined not by a single frontier model but by how intelligently many models work together.” Replace “models” with “skills” and the statement is even more true. The skill is the atomic unit. The composition layer is the product.
What the Community Is Saying
The practitioner discourse is split between enthusiasm and skepticism — which is healthy.
On the enthusiasm side, the Skills Manager discussion on HN highlights the practical pain of managing skills across Claude, Cursor, and Copilot — each stores skills in different locations and formats. Composition adds another layer: not only do you need skills to work within one agent, you need them to compose correctly when an orchestrator fires multiple agents that each bring their own skill sets.
On the skepticism side, the “Are most agent skills just fancy system prompts?” thread on HN raised a point that composition advocates need to confront: if nearly half of public skills lack functional depth, then skill composition is optimizing for quantity over quality. The response from one commenter is worth engaging with: “while many skills are essentially structured system prompts, the surrounding configuration and orchestration matter more practically.” That is both a defense and an indictment — it says the value is in the composition layer, not the skills themselves.
The AgentSkillOS research confirms this empirically. Their ablation study showed that DAG-based orchestration is the critical contributor to performance — vanilla agents with the identical oracle skill set performed significantly worse without structured composition. The skill is necessary but not sufficient. The composition is where the value lives.
The nine open-source agent orchestrators tracked by Augment Code tell the same story from the tool side: every serious orchestration framework now treats skill composition as a first-class concern, not a plugin. The agent fleet orchestration problem is what happens when composition scales beyond a single session.
The Ownership Declaration Checklist
If you are building skills that will be composed — and in 2026, every skill should assume it will be composed — here is the minimum viable ownership contract:
# skill-manifest.yaml
skill:
name: "code-review"
version: "1.2.0"
ownership:
reads:
- "src/**/*.ts" # What files this skill reads
- ".eslintrc.json"
writes:
- "review-report.md" # What files this skill creates/modifies
- ".github/pr-review.json"
executes:
- "npm run lint" # What commands this skill runs
- "npm test"
side_effects:
- "Posts GitHub PR comment" # External effects
composition:
idempotent_steps:
- "npm run lint" # Safe to deduplicate
non_idempotent_steps:
- "Posts GitHub PR comment" # Must not run twice
requires_before:
- "build" # Skills that must run first
conflicts_with:
- "auto-fix" # Skills that cannot run in the same stackThis is not a standard — no standard exists yet, and the fragmentation problem is real. But the fields are the minimum set that an orchestrator needs to compose skills without collision. If your skills do not declare what they own, the orchestrator must guess. And orchestrators guess wrong at exactly the frequency you would expect from a system that cannot read your mind.
Quick audit for your existing skills: For each skill in your stack, can you answer these four questions? (1) What files does it read? (2) What files does it write? (3) What commands does it execute? (4) Does it have external side effects? If you cannot answer all four for every skill, you are not ready for composition. You are ready for a debugging marathon.
What This Means for You
If you have fewer than 5 skills: You do not have a composition problem yet. You have an authoring problem. Write skills with functional depth — not system prompts with a name — and composition will take care of itself when you get there.
If you have 5-15 skills: Start with sequential pipelines. Define which skills feed into which. Add ownership declarations even if your orchestrator does not enforce them yet. The declarations are documentation that prevents future you from debugging a double-run at 2 AM.
If you have 15+ skills: You need DAG composition. Flat invocation is provably worse. Invest in an orchestrator that reads ownership manifests, deduplicates idempotent steps, and rejects stacks with unresolved write conflicts. The harness matters more than the model.
If you are building a skill for others: Your skill will be composed. Assume it. Declare your inputs, outputs, and side effects. Mark your steps as idempotent or non-idempotent. List your conflicts. The skill that plays well with others will win the ecosystem. The skill that assumes it runs alone will break every stack it joins.
The Schmidhuber survey calls this “scaffolding improvement” — updating the operational components around the model rather than the model itself. The practical version is simpler: the model does not improve when you stack skills. The system does. But only if the skills know how to share the stage.
The security surface of skills that execute code is a related but distinct problem — config files that run code are an attack surface, and composition multiplies that surface by the number of skills in your stack. Audit before you compose.
Composition is where agent engineering meets distributed systems. For the fleet-level view of this problem — what happens when your composed skills run across multiple background agents — read The Agent-of-Agents Problem.