Emily Kramer’s July 2026 MKT1 newsletter on moving marketing teams from single-player to multiplayer Claude is, read sideways, a change-management specification for an AI function. It names a single accountable owner. It puts the shared artifacts in a git repo packaged as a plugin. It gates publishing behind a step that has to pass. It requires review before release. It measures staleness from commit history. The word governance never appears.
The omission is the most useful thing about the piece. Marketing leaders will adopt a system described as collaboration hygiene and refuse the identical system described as governance. Kramer wrote the version people install.
What she wrote is also half a system. The change-control half is unusually complete. The risk half is absent, and the absence has a specific shape.
The Translation Table
Take the operational rules of the piece and rename them in the vocabulary a platform team would use.
“Give the system an owner: a growth lead, ops lead, GTM or marketing engineer, gen marketer, or your resident AI enthusiast.” That is single-owner accountability, with an explicit escalation problem attached. Kramer names the failure mode directly: “The person running the team usually isn’t the AI super user.” Her framing of the analogy, borrowed from sales, is “when the champion is not the decision maker. In this case the builder is not the decision maker.” Anyone who has watched a platform initiative stall inside a company knows that sentence by heart.
“Set up a shared GitHub repo as your team’s one home for skills, packaged as a plugin. Everyone installs it once, and one person’s push updates the whole team.” That is a versioned artifact store with an audit trail and a distribution channel. The tooling ruling is explicit and, for a marketing audience, brave: docs in a GitHub repo, an Obsidian vault, or Notion, and specifically not Google Drive or Docs. She also names the anti-pattern that most teams are currently living: “Most people are just trying to get Claude to connect to a million sources and they’re not making a specific source of truth.”
The Publish meta-skill, which “confirms a skill is ready, then ships it to your computer or shared team repo the right way every time,” is release control. The Review meta-skill, which “tests your skill before publishing by running evals with Claude,” is acceptance testing. The Repo stats skill, which “reads your team’s git history to flag which skills are getting updated versus going stale,” is a real staleness metric derived from evidence the team already produces rather than from a survey.
There is one operational rule sharper than anything else in the piece, and it is not Kramer’s. It comes from Slava Baranskyi, in a comment on her LinkedIn post, quoted in the body: no skill ships without an eval list, five or six expected outputs written down before anyone runs it. That one step kills the “looks impressive, behaves like a horoscope” class of skills before a team wastes a month on them. Attribution matters here, because it is the rule most worth stealing.
The Mechanism, Not Just the Diagnosis
We argued earlier that a skills library is a second codebase with no garbage collector: it accumulates, it rots, and nobody owns deletion. That post named the problem and left the mechanism open.
MKT1 supplies the mechanism. Seven meta-skills in three tiers, skills whose job is maintaining skills. Primary: Build, Review, Publish. Helper: Dupe check (“checks you’re not rebuilding something that already exists, whether locally, in your team repo, or in an MCP”) and Update (“catches the fixes you make in a live session and asks before pushing them into the skill, so they don’t die in the chat”). Audit, on a schedule: Maintain, which sweeps past sessions for fixes never saved, and Repo stats.
The Update skill is the interesting one, because it targets where team knowledge actually leaks. Kramer’s example: “You tell Claude stop using em dashes for the tenth time. That correction belongs in the shared voice skill, that everyone’s Claude.md references, so it applies for everyone, not in a chat that ends.” Corrections made in chat are the single largest source of unbanked institutional learning in any team using these tools. A skill that harvests them, with a confirmation prompt before it writes, is a maintenance loop rather than a maintenance intention.
Her framework calls this the fourth C. Claude, Context, Capabilities, Collaboration, and her claim is that “Collaboration is what turns those individual pieces into a team system, and it’s the C almost every team is missing.” Her negative definition is the part to keep: multiplayer is not paying for a team Claude plan, not dumping docs into a shared drive, not letting everyone build skills that never leave their laptop, not one AI enthusiast making tools nobody adopts. Four things teams do instead of the work.
Before You Cite This As Evidence
The piece has no adoption statistics. No team-versus-individual split, no productivity measurement, no percentage of anything. Its only numbers are structural: 100-plus LinkedIn replies, 84,000 subscribers, 30-plus skills, 100-plus templates. Anyone repeating this framework in a leadership deck should know they are repeating a taxonomy, not a result.
The closest thing to evidence is qualitative, and it is honest about being qualitative. Kramer reports that most of the 100-plus replies echoed the same sentiment: the hard part of multiplayer Claude is only partly the technology, and mostly getting teammates to use what other people built, figuring out who owns the system, and keeping it from going stale when everything moves this fast.
Devon Watts, Head of Product Marketing and Partner Marketing at Mercury, describes the failure state precisely: “We have a shared skills library, but the way those skills get created, tested, and used is pretty inconsistent. That leads to low confidence and low adoption (i.e. people just building their own skills & agents instead of using what other people have built).” Ting Ting Luo, who has built and led marketing teams at Clay, Orum and Flexport, names the resourcing trap: “The thing that will actually make you more efficient is building the system, but that’s the part there’s never time for.”
One disclosure the reader deserves: the newsletter is sponsored, and it closes by selling the paid MKT1 MCP, so the framework being taught and the product being sold are the same object.
The Inversion the Piece Never Reaches
Kramer does not make this argument, and it should not be attributed to her.
The property that makes the shared repo valuable is that one person’s push updates the whole team. That property is blind to content: it treats a fix and a fault identically, at the same speed and the same reach. A shared skill library takes an individual’s error rate and multiplies it by headcount, then applies it to work that leaves the building: customer emails, landing page copy, competitive claims, pricing language.
Now look at what the spec covers. Change control, release control, acceptance testing, staleness measurement, duplicate prevention. Now look at what it leaves out. Missing: an approval boundary naming which skills may act alone and which require a human in the loop. The review requirement covers the skill and goes quiet on the output that reaches a customer. Missing: a record of which factual claims an agent asserted, which leaves a wrong number in three campaigns orphaned from the skill that generated it. And missing: rollback. The repo propagates a change to everyone in one push and stays silent on how to un-propagate it.
Compare this to engineering, where the same substrate carries a deploy pipeline, a staging environment, a code owner requirement on sensitive paths, and a revert button. Marketing is being handed the propagation mechanism without the containment that makes propagation safe. That is the same asymmetry we traced in the tooling deficit outside engineering and the same reason an executable recipe changes blast radius even when the recipe itself is correct.
Kramer’s own strongest structural idea supports the point. She reaches back to the SDR model of three to seven years ago as the precedent failure: “Companies hired armies of reps to build workflows in silos. Scaling individual behavior in silos instead of turning the best workflows and learnings into team gains is just silly.” She is right about the waste. The lesson the SDR era also taught is that centralizing a bad script scales the bad script. Danny Lambert of LangChain frames the upside version, wanting agents to “take what the best people are doing and make it so that that’s the default standard for everybody.” Defaults propagate in both directions.
Do This Now
Adopt the seven meta-skills. Adopt Baranskyi’s eval rule as a hard gate. Then add the four controls the spec is missing, which cost one afternoon of writing and no new tooling:
- An action boundary in the repo README. List which skills may run unsupervised and which require a named human before their output leaves the company. Two columns.
- A review requirement on customer-facing output, not just on skills. The Review meta-skill tests the skill. Nothing tests the artifact that ships.
- A claims log. When a skill asserts a number, a competitor fact, or a customer name, it writes the assertion and its source to a file in the same repo. This is how a wrong figure gets traced instead of argued about.
- A revert procedure with a named owner. One person, one command, documented. If the mechanism can push to everyone, it must be able to pull back from everyone.
Then run one measurement Kramer’s framework already makes possible. Use the Repo stats skill on your own history and count how many skills have been touched in the last 30 days. A library where most skills are cold is not a team system yet. It is a shared folder with better packaging.
This analysis synthesizes Marketing teams are stuck in single-player Claude mode. Here’s how to go multiplayer. (MKT1 Newsletter, July 2026).
Victorino Group helps non-engineering teams add the missing risk controls to the AI systems they have already built. Let’s talk.
All articles on The Thinking Wire are written with the assistance of Anthropic's Opus LLM. Each piece goes through multi-agent research to verify facts and surface contradictions, followed by human review and approval before publication. If you find any inaccurate information or wish to contact our editorial team, please reach out at editorial@victorinollc.com . About The Thinking Wire →
If this resonates, let's talk
We help companies implement AI without losing control.
Schedule a Conversation