GTM Vault
gtmvault.co
Menu
LibraryStack IndexOperatorsSkillsConnect to Claudegtmvault.co

GTM Vault playbooks

GTM decisions, run in Claude on the record.

Each playbook is a sequence Claude runs over the GTM Vault record: every operator, tool, episode and transcript. It answers from what operators actually ran, cites the episode and the timestamp, and says so when the record has nothing. 3 are free with a subscription; all 34 come with Pro. Connect GTM Vault to Claude to run them.

Diagnose

Find what is breaking before you buy anything.

  1. /gtm-auditFree

    Revenue system audit

    Run the eight-layer audit on your company and find the layer to fix first.

    You give it: Company name, stage, motion, and anything you already know is breaking.

    How it runs · 6 steps
    1. Call run_layer_audit with no answers to get the eight questions.
    2. Answer each question from what the user has said about their company. List any you cannot answer and ask the user for those only, in one message.
    3. Call run_layer_audit with all eight answers.
    4. Report the breaking layers in build order and name the lowest one as the layer to fix first. Explain in two sentences why a break there contaminates every layer above it.
    5. For the fix-first layer, list the operators and episodes the audit returned, with links.
    6. End with the build_stack_url the audit returned and one question: whether to run build-my-stack next.

  2. /fix-first-layerPro

    Fix-first layer deep dive

    Everything operators have said and run on the one layer you need to fix first.

    You give it: The layer to go deep on, for example Identity or Functional Coherence.

    How it runs · 5 steps
    1. If no layer was given, run the gtm-audit playbook first and use its fix-first layer.
    2. Call search_vault three times with different phrasings of the layer's core problem, for example for Identity: ICP definition, disqualifying accounts, enrichment and data quality.
    3. Call get_operator_stack for the two or three operators who appear most often in those results.
    4. Summarize what those operators changed at this layer, the tools they ran for it, and what happened, with an episode link and timestamp for each claim.
    5. Close with the smallest first change the evidence supports, and name whose evidence it rests on.

  3. /pipeline-stallPro

    Why pipeline stalled

    Diagnose flat pipeline against what operators found when theirs stalled.

    You give it: What you see: flat pipeline, falling conversion, rising CAC, and since when.

    How it runs · 5 steps
    1. Ask for the symptoms if none were given: which number is flat, since when, and what changed around then.
    2. Call search_vault for operator accounts of the same symptom, using two or three phrasings.
    3. Call run_layer_audit and answer the Functional Coherence, Motion and Metrics questions from the symptoms; ask for the rest.
    4. Map each symptom to the layer that produces it, citing the operator who saw the same pattern.
    5. State the likely structural cause in one sentence, then the evidence for it, then what would disprove it.

  4. /motion-stage-checkPro

    Motion versus stage check

    Check whether the way you sell still matches the stage you are at.

    You give it: Revenue band, how you sell today, and when that motion was set up.

    How it runs · 4 steps
    1. Establish the current revenue band and the motion, and when the motion was designed.
    2. Call search_vault for operators describing a motion change at a similar revenue band.
    3. Call build_stack twice: once with the current motion, once with the motion the evidence points to. Compare the two install orders.
    4. Say plainly whether the motion matches the stage, what the operators who changed motion did first, and what the second build adds or defers.

  5. /agent-readinessPro

    Agent readiness check

    Whether your lower layers can carry AI agents yet, since agents inherit what sits beneath them.

    You give it: What you want agents to do, and how your ICP, pipeline and metrics work today.

    How it runs · 4 steps
    1. Call run_layer_audit and answer the questions from what the user has said, asking for the rest.
    2. Read the layers beneath the AI Layer. Any layer breaking below it is a layer the agents will automate as it is.
    3. Call search_vault for operators running agents in production and for agents automating a broken process.
    4. Give a verdict per agent use the user named: ready, ready with a guard, or not yet. For each not yet, name the lower layer to fix first and the operator evidence for doing it in that order.

  6. /signal-readinessPro

    Signal readiness check

    Whether your stack can act on buying signals yet, before you pay for signal data.

    You give it: Revenue band, motion, constraint and budget; The signal sources you run or are evaluating.

    How it runs · 4 steps
    1. Call build_stack and find where the Signal layer falls: Install first, Install next or Not yet.
    2. Call run_layer_audit, answering the Identity and Sequencing questions from what the user has said, since a signal is only useful against a defined ICP and a sequence that can act on it.
    3. Call search_vault for operators who bought signal data early, and for operators who described acting on signals successfully.
    4. Say whether to buy signal data now or later. If later, list what has to hold first and the evidence. If now, name the signal sources operators on the record run, with get_operator_stack for each.

  7. /forecast-resetPro

    Forecast reset

    Rebuild a forecast you would bet on, starting from one pipeline definition.

    You give it: How you forecast today, how far off it runs, and who owns each pipeline number.

    How it runs · 5 steps
    1. Call run_layer_audit and answer the Functional Coherence and Metrics questions from the situation, asking for the rest.
    2. If Identity is also breaking, say so first: a forecast cannot hold while the definition of a qualified account lives in reps' heads.
    3. Call search_vault for one pipeline definition, retiring metrics and forecast accuracy.
    4. Call build_stack with forecast as the binding constraint and take the Measurement and System of Record layers.
    5. Lay out the reset in order: the one definition, the metrics to retire, the ledger it lives in, and the cadence, each step cited.

  8. /win-lossPro

    Win-loss gap

    Find what separates the accounts you win from the ones you lose, the way operators on the record did.

    You give it: What you sell, recent wins and losses, and where deals tend to die.

    How it runs · 4 steps
    1. Call search_vault for win loss, then for propensity and for stage conversion.
    2. Pull the operators who built a win-loss or propensity layer and summarize how each did it: the data they compared, where it lived, and what they did with the difference.
    3. Call get_operator_stack for those operators to show the tools their win-loss work ran on.
    4. Apply their method to the user's situation: which records to compare, which signal to look for, and the first campaign or qualification change the gap would support. Cite each step.

Build

Install order, budgets and the layers your stage needs next.

  1. /build-my-stackFree

    Build my stack

    Get your install order: first, next and not yet, with the operators behind each tool.

    You give it: For example $2M to $20M ARR; Product-led, sales-led, enterprise or hybrid; The binding constraint, for example pipeline does not convert; Self-serve, mid-market or enterprise.

    How it runs · 5 steps
    1. Collect the four inputs. Ask only for the ones missing, and offer the valid values build_stack accepts.
    2. Call build_stack.
    3. Present Install first, Install next and Not yet as three short sections. For every operator-evidenced tool, name at least one operator who runs it and their episode; mark essay-evidenced tools as essay-recommended.
    4. Explain why the first block carries the binding constraint.
    5. Share the build_url so the user can open the same build on the site.

  2. /not-yetPro

    What not to buy yet

    The tools to defer at your stage, and what buying them early does.

    You give it: Revenue band, motion, constraint and budget, or a build link.

    How it runs · 4 steps
    1. Call build_stack with the user's inputs, asking for any that are missing.
    2. Take the Not yet block. For each deferred layer, call search_vault for operators who bought into that layer too early or described why it waited.
    3. For each deferred layer, give the condition that should be true before buying into it, with the evidence.
    4. If the user already pays for a tool in a Not yet layer, say so directly and what the evidence suggests doing about it.

  3. /budget-rebuildPro

    Rebuild for a different budget

    Compare your stack at two budget postures and see what changes.

    You give it: Revenue band, motion and constraint; The two budget postures to compare, for example mid-market and self-serve.

    How it runs · 4 steps
    1. Call build_stack once for each budget posture with the same other inputs.
    2. Show, layer by layer, which tools swap between the two builds and which stay.
    3. For every swap, name the operators behind each option and anything they said about the trade.
    4. State what the cheaper build gives up, in one sentence per layer.

  4. /next-stagePro

    Stack for the next stage

    See what your stack needs to become at the next revenue band.

    You give it: Current revenue band, motion, constraint and budget.

    How it runs · 4 steps
    1. Call build_stack for the current revenue band, then again for the next band with the same motion, constraint and budget.
    2. List what moves from Not yet into the install blocks, and what becomes admissible.
    3. Call search_vault for operators describing the transition between these two bands.
    4. Give the order to add things in as the company grows, citing the operators who made the same transition.

  5. /first-playPro

    First play to run

    Pick the first play your build supports and outline how an operator ran it.

    You give it: Revenue band, motion, constraint and budget, or a build link.

    How it runs · 4 steps
    1. Call build_stack and read the plays it returns.
    2. Choose the first play whose required layers are all in Install first or already in place. Say why it comes first.
    3. Call search_vault for the operator who ran it on the record and pull the moments where they explain it.
    4. Outline the play: first-party data used, outside trigger, and the measure, with the operator's own numbers where they gave any.

  6. /enrichment-waterfallPro

    Enrichment waterfall

    Design an enrichment order from the providers operators chain together.

    You give it: Revenue band, motion and budget posture; Any data or enrichment providers you already pay for.

    How it runs · 5 steps
    1. Call build_stack with the user's stage and budget, asking for anything missing, and take the tools on the Source and Enrichment and Resolution layers.
    2. Call get_operator_stack for each of those tools to see which ones operators run together.
    3. Call search_vault for waterfall, enrichment order and data coverage to find operators who described their sequence.
    4. Propose an order: the first provider, what falls through to the next, and where resolution happens, citing the operator whose setup each step follows.
    5. Flag any provider the user already pays for that no operator on the record chains in this way.

  7. /crm-choicePro

    System of record choice

    Which CRM fits your stage, from the operators running each one.

    You give it: Revenue band, motion and budget posture; The CRM you run today, if any, and what is wrong with it.

    How it runs · 4 steps
    1. Call build_stack with the user's stage and budget and take the System of Record layer: the tools matched to the budget and where the layer falls in the install order.
    2. Call get_operator_stack for each CRM returned, and for the user's current CRM if it is different.
    3. Call search_vault for CRM migration, moving off and single pipeline ledger to find operators who switched and why.
    4. Recommend stay or move. If move, name the target, the operators behind it, and what they said the migration cost them. If the layer sits in Install next rather than Install first, say what has to hold before the CRM decision matters.

  8. /plays-on-recordPro

    Plays on the record

    Every play your build can support, and which ones an operator ran on the record.

    You give it: Revenue band, motion, constraint and budget, or a build link.

    How it runs · 5 steps
    1. Call build_stack and take every play it returns, with its evidence field.
    2. Sort the plays by evidence. operator: an operator on the show ran a version of it, and the play cites their episode. essay: the play comes from GTM Vault's writing and no operator on the record ran it. Say which is which, plainly.
    3. For each operator play, call search_vault with the operator's name and the play to find the moment they explained it. Do not search for an operator behind an essay play.
    4. Split the plays into runnable now, because every layer they need is installed or in Install first, and runnable later, with the layer each is waiting on.
    5. For each runnable operator play, give the operator, the episode and timestamp, the trigger, the data it uses and how they measured it. For each runnable essay play, give the trigger, the data and the measure, and say no operator on the record has run it yet.

  9. /clay-to-codePro

    Clay to Claude Code

    Whether to move a workflow from Clay or another no-code tool into Claude Code, from the operators who did.

    You give it: The workflow you run today, the tool it runs in, and what is slow or costly about it.

    How it runs · 4 steps
    1. Call get_operator_stack for Claude Code, and for the tool the workflow runs in today. Record every displacement on the record between them.
    2. Call search_vault for terminal, CLI and Claude Code to find operators describing the move and what it changed in time and cost.
    3. Compare the user's workflow with the ones operators moved: volume, how often it changes, and who maintains it.
    4. Recommend move, keep, or split, with the operator evidence for each part. Name what the move costs: who owns the code once it leaves the no-code tool.

  10. /context-layerPro

    Context layer design

    Design the account memory your team and agents read from, from the operators who built one.

    You give it: Where account knowledge lives today: CRM, call recordings, notes, docs, Slack.

    How it runs · 4 steps
    1. Call build_stack with the user's stage and budget, asking for anything missing, and find where the Context layer falls in the install order.
    2. If Context sits in Not yet, say so first and name the layers that have to hold before it pays off.
    3. Call search_vault for context graph and single source of truth, and get_operator_stack for the Context tools the build returns.
    4. Lay out the design: which sources feed it, where it lives, who and which agents read from it, with the operator evidence for each choice.

Distribute

Channels, outbound and getting cited by AI search.

  1. /aeo-planPro

    Get cited by AI answer engines

    What operators did to get their company cited when buyers ask ChatGPT, Claude or Perplexity.

    You give it: What you sell, who buys it, and the questions buyers ask an AI before they buy.

    How it runs · 4 steps
    1. Call search_vault for GEO, then for AI search and for citations.
    2. Summarize the operators' method: how they made the company understandable to AI systems, where they seeded evidence such as review sites, and how they measured it.
    3. Call get_operator_stack for the tools they named, such as review sites and search measurement.
    4. Turn it into a plan for the user: the buyer questions to own, the sources to seed, and the measure, each step cited.

  2. /channel-choicePro

    Channel choice

    Which distribution channel your stage can carry, from the operators who built demand on each.

    You give it: Revenue band, motion, who you sell to, and the channels you use today.

    How it runs · 4 steps
    1. Call build_stack with the user's stage and read the Channels and Content layer and where it falls in the install order.
    2. Call search_vault for the channels the user is weighing, one keyword at a time, for example LinkedIn, Reddit or launch.
    3. For each channel with operators on the record, give who built demand there, what they did, and what it produced in their own numbers where they gave any.
    4. Recommend one channel to start with and the one to defer, with the evidence. If Channels sits in Not yet, say what has to hold first.

  3. /outbound-stackPro

    Outbound sending stack

    The sending, calling and routing setup operators run, matched to your stage and budget.

    You give it: Revenue band, motion, budget, and your outbound volume today.

    How it runs · 4 steps
    1. Call build_stack and take the Action Surface layer: the sending, calling and routing tools matched to the budget.
    2. Call get_operator_stack for each of those tools to see what operators pair them with and any displacement.
    3. Call search_vault for deliverability and for sequencing to find what operators said about running outbound at volume.
    4. Recommend a sending setup and the order to add to it, noting where the build says the layers beneath the Action Surface must hold first.

Before you buy

Test a tool or a vendor claim against who runs it.

  1. /tool-checkFree

    Tool due diligence

    Before you sign, see who runs a tool, what it did, and what it runs next to.

    You give it: The tool you are evaluating.

    How it runs · 5 steps
    1. Call get_operator_stack with the tool.
    2. If it is not on the record, say so plainly and call search_vault for the tool name in case it was mentioned without being placed. Absence of operator evidence is part of the answer.
    3. If it is on the record: list every operator who runs it, what it did in their system, the layer it serves, and what runs alongside it.
    4. List the displacements get_operator_stack returned: what the tool replaced and what replaced it, with the operator and episode for each. If there are none, say nobody on the record has swapped it.
    5. End with the questions the evidence says to ask the vendor before signing.

  2. /displacement-checkPro

    Displacement check

    Has any operator replaced this tool, with what, and why.

    You give it: The tool you want to know about.

    How it runs · 4 steps
    1. Call get_operator_stack with the tool and read its displacements: what it replaced and what replaced it, with the operator and episode for each.
    2. For each displacement, call search_vault with the other tool's name to find the operator explaining the switch.
    3. For each displacement, give who, what they moved to, why, and the episode and timestamp.
    4. If nobody has replaced it on the record, say so.

  3. /layer-shortlistPro

    Shortlist for a layer

    The tools operators run on one layer, filtered to your budget.

    You give it: The layer or sub-layer, for example Enrichment and Resolution; Self-serve, mid-market or enterprise.

    How it runs · 4 steps
    1. Call build_stack with the user's stage and budget, asking for any missing inputs, and find the layer in the output.
    2. List the tools matched to the budget on that layer, with operator counts.
    3. Call get_operator_stack for the top two tools to show what runs alongside each.
    4. Recommend a shortlist of at most three, each with the operator evidence behind it.

  4. /vendor-claimPro

    Check a vendor claim

    Test what a vendor told you against what operators said on the record.

    You give it: The vendor's claim, pasted as said.

    How it runs · 4 steps
    1. Restate the claim as one testable sentence.
    2. Call get_operator_stack for the vendor's tool and search_vault for the specific outcome claimed.
    3. Sort the evidence into supports, contradicts, and silent.
    4. Give a one-line verdict and the citation it rests on. Do not overstate: if operators are silent, the verdict is unverified, not false.

  5. /stack-teardownPro

    Tear down my stack

    Map your current tools onto the layers and find gaps and overlaps.

    You give it: Every tool you pay for today.

    How it runs · 4 steps
    1. Call get_operator_stack for each tool the user lists and record the layer it serves. Mark any tool not on the record.
    2. Lay the stack across the eight layers in build order.
    3. Flag empty layers, layers with two or more tools doing the same job, and tools sitting in a layer the build would defer.
    4. Call build_stack with the user's stage and compare it with what they have. Report what to add, what to cut, and the operator evidence for each.

  6. /compare-toolsPro

    Compare two tools

    Two tools head to head: who runs each, what each did, and any displacement between them.

    You give it: First tool; Second tool.

    How it runs · 5 steps
    1. Call get_operator_stack for each tool. Record the layer each serves, the operators who run it, and what runs alongside it.
    2. If either tool is not on the record, say so plainly. A comparison with one side missing is a finding, not a gap to fill from general knowledge.
    3. Read the displacements get_operator_stack returned for each tool: what it replaced and what replaced it, with the operator and episode. For each one, call search_vault with the other tool's name to find the operator explaining the switch; if no passage turns up, cite the episode alone.
    4. Compare side by side: layer, operator count, what each did in those operators' systems, the tools each pairs with, and every displacement with its episode and timestamp.
    5. Close with the conditions under which the evidence favours each tool. Do not declare a winner the evidence does not support.

Research

Operators, comparisons and the exact moment someone said it.

  1. /operator-profilePro

    Operator profile

    One operator's full stack by layer, what they replaced, and their key moments.

    You give it: The operator's name.

    How it runs · 3 steps
    1. Call get_operator_stack with the operator.
    2. Call search_vault for the operator's name to pull their strongest moments.
    3. Present their stack across the layers in build order, then three moments with timestamps, then the displacements get_operator_stack returned: what they replaced and with what.

  2. /compare-operatorsPro

    Compare two operators

    Two stacks side by side, layer by layer, where they agree and differ.

    You give it: First operator; Second operator.

    How it runs · 4 steps
    1. Call get_operator_stack for each operator.
    2. Compare layer by layer: shared tools, different tools, and layers only one of them instrumented.
    3. Call search_vault for each operator on the layer where they differ most, to explain why.
    4. Close with what the difference suggests for a company choosing between their approaches.

  3. /find-the-momentPro

    Find the moment

    Find exactly where an operator said something, with the timestamp.

    You give it: What was said, in your own words.

    How it runs · 2 steps
    1. Call search_vault with the topic, restricted to transcripts, then again with a second phrasing.
    2. Return the best three matches as short excerpts, each with episode code, operator and timestamp link.

  4. /topic-briefPro

    Topic brief

    Everything operators have said on one GTM topic, synthesized with citations.

    You give it: The topic, for example outbound deliverability or RevOps hiring.

    How it runs · 4 steps
    1. Call search_vault four times with different phrasings and angles on the topic.
    2. Group the findings into positions operators hold, noting where they disagree.
    3. Write the brief: each position in two or three sentences, every claim cited with operator, episode and timestamp.
    4. End with the open question the evidence does not settle.

Decide

Hires, agents and memos with every claim cited.

  1. /agent-or-hirePro

    Agent or hire

    Whether to fill a GTM role with an agent, a person, or both, from operators who made the call.

    You give it: The role or task you are deciding on, and what the person or agent would do each day.

    How it runs · 4 steps
    1. Call search_vault for agents replacing headcount, then for agents and BDR.
    2. Call run_layer_audit with the user's answers: an agent inherits the state of the layers beneath it, so a breaking lower layer argues for a person first.
    3. Summarize what the operators on the record did: which work went to agents, which stayed human, and what happened.
    4. Recommend agent, person, or a split for the role named, with the evidence and the lower layers that have to hold for the agent option.

  2. /decision-memoPro

    Evidence-backed decision memo

    A one-page memo on a GTM decision, every claim cited, for your board or team.

    You give it: The decision on the table and the options being weighed.

    How it runs · 4 steps
    1. State the decision and the options in two sentences.
    2. For each option, call search_vault and get_operator_stack for operators who took that path.
    3. If the decision touches tooling or sequence, call build_stack with the user's stage.
    4. Write the memo: recommendation, the evidence for it, the evidence against it, and what would change the call. Every claim carries an operator, an episode and a link.

  3. /first-gtm-hirePro

    First GTM or RevOps hire

    What operators say about the hire, the timing, and what the system needs first.

    You give it: The role you are considering, for example first SDR, first RevOps, head of growth.

    How it runs · 3 steps
    1. Call search_vault for operators on hiring this role, and on hiring it too early.
    2. Call run_layer_audit with the user's answers to check whether the layers this role depends on hold.
    3. Say whether the system is ready for the hire, what to install before it, and what the operators who made the hire learned, each with a citation.
Run one in two minutes. Connect GTM Vault to Claude, then ask: Run the GTM Vault revenue system audit on my company. Pro opens all 34, transcript search and weekly office hours: $99 a month or $999 a year.