Your Skills Are Not a Stack
The Skill Stack, and why composition compounds where isolation does not
👋 Hi, it’s Rick Koleta. Welcome to GTM Vault - a breakdown of how high-growth companies design, test, and scale revenue architecture. Join 26,000+ operators building GTM systems that compound.
I built my first four GTM Vault skills over a quarter. A writing skill that encoded my voice and structural rules. A thumbnail generator wired to the brand templates. An engaged-subscriber outreach workflow. A sponsor outreach pipeline. Each one worked. Each one saved real time on the recurring task it was built for. I was running all four every week.
Two months in, I noticed something. The leverage had stopped growing. The fourth skill produced roughly the same incremental gain as the second one had. Each skill kept saving time on its specific task. The team and I were operating better than before, but not differently. The compounding curve I expected had not shown up.
The diagnosis was structural and I had not noticed it. The four skills were not a stack. They were four tools sitting next to each other. Each one had been designed to be run alone. The thumbnail skill had no idea what the writing skill had produced. The sponsor outreach pipeline did not reference the same brand context as the subscriber outreach. Each skill was carrying its own snapshot of voice, ICP, and format. When I updated one, I had to remember to update the others. The skills were running. They were not composing.
The constraint is not the number of skills. It is whether the skills compose. A skill is a tool. A stack is a system. The math between the two is not similar.
The Skill Stack
The Skill Stack is a coordinated set of skills designed to compose, where the output of one skill is structured to be the input of the next. The skills share context. They reference each other. They participate in workflows that fire them in sequence. The leverage produced by a stack is multiplicative, not additive, because every skill operating on the output of an earlier skill is operating on work that has already been leveraged.
The math is non-linear, not multiplicative.
Five isolated skills, each saving 30 minutes on a single task, produce five separate 30-minute savings. Real productivity. The operator still has to run each skill, copy outputs into inputs, switch tabs, and reformat data between them. The savings cap at the time each individual task takes to manually run, plus the orchestration overhead between them.
Five stacked skills produce a different kind of leverage. The skills do not just save time on individual tasks. They run as a single workflow that the operator no longer has to orchestrate. The cycle time of the entire workflow collapses, because the manual handoffs between skills disappear. An isolated skill saves time within a task. A stack saves the operator entirely from the workflow.
The arithmetic difference is not 5 × 30 minutes versus 32 × 30 minutes. It is 5 × 30 minutes of operator-attended task work versus a workflow that runs ambient and produces a finished output the operator only has to review. The chain that took an hour and a half to manually run on isolated skills runs in under ten minutes on a stack, and most of that time is the operator reading the output. The leverage is not in the multiplication. It is in the disappearance of the operator from the loop.
This is the math most operators have not seen because the question of whether their skills compose has never been asked.
Why most operators build isolated skills
The default mode of skill-building is the worst possible mode for composition. The operator notices a recurring task that takes too long, builds a skill that does that task, ships it, and moves on. Every skill is built in the context of the single task that prompted it. The output format is whatever was convenient for the operator to read. The context the skill loads is whatever the operator typed into the SKILL.md file in that session. The skill never imagines being called by another skill. It is a tool built to be run alone, and the tools you build to be run alone do not compose.
The pattern is sticky for three reasons.
First, building a skill feels like the unit of progress. The operator can demo “I built a skill” but cannot demo “I designed a stack.” The visible output of building maps to one skill at a time, so the operator’s instinct to ship pushes toward isolated artifacts.
Second, composition requires upfront architecture. To build a stack, the operator has to decide in advance what the output schema of each skill should be, what shared context will be referenced across the stack, what workflows will fire the skills in sequence. This work has no immediate payoff. The first skill in a stack costs more to build than the first isolated skill, because the architecture has to be designed before the implementation. Most operators do not pay this cost because they do not see the payoff yet.
Third, the team usually does not have the discipline to enforce composability across multiple operators’ skills. One operator builds the research skill. A different operator builds the outreach drafter. They do not coordinate. The two skills cannot consume each other’s output because nobody designed them to. Building stacks requires either a single architect or a team-level convention, and most teams have neither.
The four design principles for stacks
Stacks are not built. They are designed. Four principles separate a designed stack from a pile of co-located skills.
The first is output schemas. Every skill in a stack has a defined, structured, predictable output. Not a paragraph. A specified format that downstream skills can consume without parsing. An account research skill that outputs an unstructured page is a research skill. An account research skill that outputs
{company, signal, buying_committee[], hook_angles[], next_step}is a stack-ready research skill. The schema is the contract that makes composition possible.The second is shared context. Stacks reference a single set of context files (icp-definition.md, positioning.md, competitor-radar.md, anti-positioning.md) that every skill in the stack pulls from. Skills that each maintain their own context fragment the team’s knowledge into N copies and guarantee drift. Stacks share context the way well-designed software shares dependencies: one source of truth, referenced by everything that needs it. This is the structural shift I named in the context layer becoming the operating system, now applied at the skill layer.
The third is composability by default. Every skill is designed assuming it will be called by another skill. The skill receives structured input and emits structured output. It does not require the operator to manually copy/paste between skills. It does not assume a human reads the result before the next skill runs. The composition test is whether two skills can be chained without manual intervention. If not, they are not a stack.
The fourth is workflow orchestration. Stacks are fired by workflows, not by individual skill invocations. The workflow defines when the stack runs (a new account is added, a call is completed, a deal closes) and which skills participate. The operator does not pick which skill to run next. The workflow does. This is the difference between owning five skills and operating a system.
The four failure modes
Stacks fail in predictable ways. The four failure modes are recognizable from the outside, and each one points to which design principle is missing.
The first failure is skill silo. The operator who built the skill is the only person using it. No other operator on the team has adopted it. The skill has a Build Reach of one. By the Build Reach test, the skill is producing personal leverage and zero team leverage. Silos are the precondition for stacks failing because composition requires multiple skills sitting in the same workflow, and skills that nobody else uses are not in any workflow.
The second is output mismatch. Skill A emits text. Skill B expects structured fields. The chain breaks at the seam. The operator works around it by manually translating between formats, which means the stack runs only when the operator is in the loop, which means the leverage caps at the operator’s calendar. Output mismatch is the single most common reason stacks designed on a whiteboard never run in production.
The third is context fragmentation. Each skill maintains its own version of the ICP, the positioning, or the competitor list. When the team updates the canonical ICP, half the skills get updated and half do not. The outputs drift apart. The operator running the stack gets contradictory positioning recommendations from two skills that should have produced consistent output. This is not a new failure mode. It is the Reference-Feedback Split appearing at a different layer of the system. Context that lives in N places drifts. Context that lives in one place can be kept current. The pattern recurs because the structural claim is the same: reference material that is not paired with a feedback loop decays, regardless of which layer of the system it sits in.
The fourth is no orchestration. The skills exist. The composability is technically there. But nothing fires the chain. The operator has to remember which skill to run next, copy the output into the input of the next skill, and so on. The stack only runs when the operator is doing the orchestration manually. The leverage is real but capped by the operator’s bandwidth. Without orchestration, a stack is a sequence of well-designed skills that almost never run together.
A working example
A stack-ready outbound sequence inside a GTM org looks like this.
Trigger. A new account is added to the prospecting list, fitting the ICP definition stored in /context/icp-definition.md.
Skill 1, account-research. Pulls firmographic data, recent news, technographic signals, hiring patterns, and existing tech stack. Output schema: {company, employees, recent_signals[], current_stack[], buying_committee[]}. Reference: /context/icp-definition.md, /context/competitor-radar.md.
Skill 2, signal-scoring. Takes the research output, scores the signals against the signal-performance log. Output schema: {account, top_signal, hook_angle, expected_reply_rate}. Reference: /feedback/signal-performance-log.md.
Skill 3, outreach-drafter. Takes the scored signal and hook angle, drafts a personalized sequence respecting positioning and anti-positioning rules. Output schema: {subject, email_1, email_2, linkedin_message}. Reference: /context/positioning.md, /context/anti-positioning.md.
Skill 4, post-call-summary. Runs after a discovery call. Takes the call transcript and outputs structured notes including which positioning landed, which objections came up, and what competitor was in the room. Output schema: {landed_messaging[], objections[], competitor, next_step}. Reference: /context/positioning.md.
Skill 5, deal-retrospective. Runs after a deal closes (won or lost). Takes the full deal history and writes a structured retrospective that updates the signal-performance log, the competitor radar, and (if the pattern is consistent across deals) the ICP evolution log. Output: appends to /feedback/signal-performance-log.md, /context/competitor-radar.md, /feedback/icp-evolution-log.md.
The stack composes. The output of skill 1 is the input of skill 2. The output of skill 2 is the input of skill 3. The shared context files are referenced by every skill that needs them. The orchestration fires when the trigger conditions are met. The retrospective at the end of the chain updates the same files that skill 1 reads from at the beginning of the next chain.
This is what compounding looks like in operator terms. Every cycle of the stack improves the inputs of the next cycle. The signal-performance log gets sharper after every deal. The ICP evolution log updates from outcomes. The positioning file gets refined when post-call summaries surface drift. The system is not just running the stack. It is improving the stack.
Channel Drag applies to stacks too
A stack designed for last quarter’s workflow is the same kind of decay artifact a channel mix from two stages ago is. The signals the stack scores against were the signals that worked in Q1; by Q3 they have aged out. The positioning the outreach drafter references was the positioning that landed in Q2; by Q4 the buyer has stopped responding. The ICP evolution log has been updating, but the skills have not been re-pointed at the new segments.
This is Channel Drag at the skill layer. The stack that collapsed a 90-minute workflow to 10 minutes three quarters ago is now producing outputs the team has to manually rework, which restores the operator to the loop and erases the leverage. The operator does not notice because the stack is still running smoothly, the outputs are still landing in the inbox, and the failure mode is silent.
The maintenance discipline at the stack layer is the same as at every other layer. A feedback file that tracks the actual conversion rate of the stack’s outputs over time. A quarterly review that compares the stack’s current performance to its peak performance. A set of triggers (drop in reply rate, drop in qualified meetings) that kick off a stack audit. Stacks that are not maintained are reference artifacts. Stacks paired with feedback files compound.
What this changes for an operator
Pull the skills you have built. List them. For each one, ask three questions.
What is the output schema? If you cannot describe it precisely, the skill is not stack-ready. The first move is to define the output format and refactor the skill to produce it.
Which other skill could consume this output? If the answer is none, the skill is a tool, not a stack member. The next move is either to build the consumer skill or to redesign the existing skill to produce output that the rest of the team’s skills can use.
What workflow fires this skill? If the answer is “I run it manually when I remember,” the orchestration is missing. The next move is to define the trigger condition and either build the workflow file that fires it or wire the trigger into an existing workflow.
The audit usually surfaces that the operator has been building skills the way you would build a Swiss Army knife. Many tools, all separate, each useful, none composing. The shift is from accumulating tools to designing systems, and that shift is structural before it is technical.
What this changes for a leader
Stop counting skills. Start counting compositions.
The right metric is not how many skills the team has built. It is how many skills are in workflows that fire automatically and produce structured output that downstream skills consume. A team with twelve isolated skills is a team that built twelve tools. A team with five stacked skills connected by two workflows and three shared context files is a team that built a system. The second team produces compounding leverage. The first team produces twelve separate productivity bumps.
The leadership move is to enforce a stack-design convention before the team has finished building the first stack. Output schemas in every SKILL.md. Shared context files referenced by everything. Workflows that orchestrate skill chains. The convention costs upfront speed and pays it back the first time two skills compose without manual intervention.
The teams that figure this out first will look like they are operating at a different multiplier than their peers. They are. The multiplier is the stack.
The constraint reframed
The operator with five isolated skills is saving time inside five separate tasks. The operator with five stacked skills has removed themselves from the workflow that strings those tasks together. The same person, the same model, the same prompts, a non-linear difference in cycle time, all of it produced by a design choice the operator made before they wrote the first SKILL.md. The architecture you build is what AI amplifies. Isolated skills get amplified into isolated leverage. Stacked skills get amplified into compounding workflow gains.
The constraint is not the skill. It is whether the skills compose into a system that runs without the operator in the loop and improves itself with every cycle.
The skills you have are the inventory. This is not a quantity problem. It is a composition problem. The system is what you have not built yet.