Winning by Design / Internal
The architecture in the plan is right, and we verified it costs less than anyone assumed. This adds what we learned after the doc was written, and names the half of the problem it did not set out to solve.
The plan got the architecture right, and we can now say so with evidence rather than confidence. We built a marketplace, installed it, and measured it. The flat-skills-folder constraint the doc identified is real. Distribution costs roughly 30 to 40 tokens per skill and about a week of work.
Because that half is settled, the interesting question is the other half. The plan's own annex tells us where it sits.
| Status | Count | Share | What it means |
|---|---|---|---|
| Live | 3 | 11% | A colleague can invoke it today |
| Draft | 4 | 15% | Written, on one laptop |
| Planned | 20 | 74% | A name in a table |
| Total named | 27 | 100% | WF4 and WF5 have no entries at all |
The plan solved distribution. Authoring throughput is the unsolved half, and nothing in the plan changes the cost or the motivation of writing the next skill.
That is the reframe this brief asks the room to accept, and it is not a criticism of the plan. The plan is the evidence. Its status column is the most honest thing in the document, and it points at the half that still needs a decision: who writes the next skill, and why anyone opens Claude on a Tuesday to run one.
Hiten Shah's answer to the first half is worth stating up front, because it cuts against the obvious instinct and it endorses what the plan already does: everyone should use skills, not everyone should make them. His words are "don't make everyone make skills, then you have a lot of skills spoiled." The plan's read-only-for-most governance is right. What is missing is the drafting path that feeds it.
The eight-step plan costs roughly 3 to 5 hours per workflow owner across eight weeks, plus 10 to 15 hours of setup for the repo owner. Call it 25 to 40 hours. No new headcount. Every one of those hours comes from someone otherwise billable or carrying pipeline, which is the real price and should be stated as such.
One cost this brief has not priced: Path B assumes the audience already holds claude.ai Team or Enterprise seats. Confirm the current seat count before step 4. If they do not have them, reaching non-terminal staff carries per-seat cost that belongs in the decision, not in a footnote.
Hour estimates and thresholds throughout are judgment calls, not measurements. Technical claims are probed or sourced, and marked as such.
Before this reaches the ELT: these four corrections should go to the author of the Plan of Attack first, and the whole thing should be reissued as v3 with both names on it. Two internal experts disagreeing in an executive meeting about internal tooling produces a deferral, not a decision. Aligned first, then presented.
Every technical claim below was tested against Claude Code 2.1.231 on August 13, 2026, or fetched from Anthropic's own documentation. Nothing here is recalled or assumed.
The document states that skills must sit directly inside skills/ because nested subfolders are not read. We built a two-skill plugin, one flat and one nested, installed it, and inspected the inventory:
Component inventory
Skills (1) flat-skill
Agents (0)The nested skill was not discovered. The constraint is real.
Nested folders are not auto-scanned. They can be declared. Adding a skills array to plugin.json registers subfolders while the default flat scan still applies. We tested it:
// plugin.json
{ "name": "wbd-tools", "skills": ["./skills/wf2", "./skills/wf3"] }
Component inventory
Skills (3) core-brand, sow-generator, spiced-diagnoseAll three were found: one from the default flat scan, two from declared subfolders. We can have real workflow folders instead of encoding the workflow in every filename as wf2-spiced-diagnose. Reference: code.claude.com/docs/en/plugins-reference
claude plugin details reports projected token cost per component. We measured 30 to 40 tokens per skill and 16 per agent, always on, against short one-line descriptions. Extrapolated across the annex's 27 items, 22 skills and 5 agents, the library lands somewhere between 740 and 960 tokens per session. Real WbD descriptions will run longer than our probe's, so treat that as a floor.
The number to watch is not this one. Token cost is negligible and now measurable; the cost that actually bites is retrieval accuracy, which is why the next section recommends scoping by role.
Anthropic published enterprise guidance that settles four open questions in the plan. Each is cheap to resolve now and expensive later.
| Open question | What we found | Suggested resolution |
|---|---|---|
One plugin, wbd-tools, everyone installs everything |
"Group Skills by organizational role to keep each user's active Skill set focused" | Ship wbd-core plus one plugin per workflow. Same repo, no extra infrastructure. |
| "Installing skills you rarely use costs nothing" | "Each Skill's metadata competes for attention in the system prompt. With too many Skills active, Claude may fail to select the right Skill or miss relevant ones entirely." | The cost is not tokens, it is the wrong skill firing. Role-scoped plugins solve this. |
| Workflow owners "edit their workflow's skills directly and push to main" | "Establish separation of duties: Skill authors should not be their own reviewers." | Owners review each other. Two owners, one reviews the other's push. |
| "Updates flow automatically from then on" | Auto-update appears to default on only for official Anthropic marketplaces, with third-party and private ones defaulting off. Confirm against the plugin-marketplaces doc before relying on it. | Set autoUpdate explicitly on our marketplace entry rather than assuming the default. |
One naming detail worth settling: section 5 ships everything in one plugin called wbd-tools, while the annex heading reads wbd-core, everyone installs this. Anthropic's role-based-bundle guidance points toward the annex version.
"Custom Skills do not sync across surfaces. Skills uploaded to the API are not available on claude.ai or in Claude Code, and vice versa. Each surface requires separate uploads and management."
Anthropic, Skills for enterprise
The entire plugin and marketplace mechanism is a Claude Code feature. Claude Code is a terminal application. Most of the people the plan is written for, MDs running deal inspections, marketers running content ideation, are not in a terminal and will not be.
There is a second path, and it is the right one for those people. On Team and Enterprise plans an admin can publish skills to the whole organization from Organization settings, Skills by uploading a zip containing SKILL.md. It then appears for every user under Customize, Skills. One caveat matters for governance: there is no approval workflow for org-wide sharing. If peer sharing is enabled, any member can publish to the directory without review, so that toggle should stay off.
Diagram 1. Distribution architecture. The plan describes Path A only, which reaches the smaller audience.
Practically: the repo stays the single source of truth and publishing becomes two acts. Path B is a manual upload through the admin console. At our volume that is fine, and the discipline that keeps the two copies honest is putting the repo commit reference in every SKILL.md header and re-uploading on every version bump, as a checklist item rather than a habit.
The surface split has a second consequence. The people closest to the work are not in a terminal, so if the only path into the library starts at ~/.claude/skills/, their knowledge never arrives. An MD who has just worked out the right way to diagnose a stalled deal holds something the library needs.
That does not mean the MD should write the skill. It means their input should reach someone who will. A shared Drive folder of drafts, plus a claude.ai project whose job is interviewing a colleague about a repeatable task and producing a structured draft, gives the MD a way to contribute in prose about their own work. A skill owner then decides whether it becomes a skill, and writes it properly.
This is the literal answer to "the shareable skills drive." The Drive folder is the intake, where anyone can describe a workflow. The GitHub repo is the library, where a small number of owners publish. Treating the Drive folder as the library is the mistake: no versioning, no review, no path to a machine, and no quality bar.
Our two reference points solved this differently, and the difference is not stylistic. It follows from what kind of company each one is.
| Hiten Shah | GrowthX (Marcel and Daniel) | |
|---|---|---|
| Who authors | A small number of owners. Repo read-only for most. | Subject matter experts author directly. "A vibe coding experience for non-developers." |
| Why | Skill quality determines output quality determines the quality of the work the company ships. | Removing the translation step between the person who knows the job and the artifact that runs it. |
| What it needs | A GitHub repo and a few disciplined owners. | A TypeScript workflow framework, an evaluation harness, traces, and a CTO who maintains it. |
| End state | Skills stay skills, curated. | Skills are the on-ramp. Anything multi-user and repeatable gets compiled into a durable workflow. |
| Failure mode | The library grows slowly and depends on a few people. | "A lot of skills spoiled," and an engineering platform to build and staff. |
Three reasons, and they are all about what WbD is.
Take one thing from GrowthX regardless: their whole library is public at github.com/growthxai/output, 49 skills and 5 agents, prefix-namespaced the same way our plan proposes. Read it before writing ours. And keep Daniel's compile question open for WF2, because deal-inspection running on every deal across every MD is the multi-user, repeatable case he says a skill is the wrong permanent home for.
Accept the Plan of Attack's spine. Change four things.
| Decision | Recommendation | Why |
|---|---|---|
| Repository | One private repo, winningbydesign/wbd-claude-plugins | Unchanged. Correct. |
| Knowledge vs skills | Consider a second repo for knowledge and context, separate from skills | Hiten Shah started with one and split it. wbd-files alone is roughly 40k tokens and changes on a different cadence. |
| Who writes | A small number of named skill owners. Repo read-only for everyone else, with a Drive intake for ideas. | Hiten Shah: "Don't make everyone make skills, then you have a lot of skills spoiled." Quality of the skill sets quality of the work. |
| Build order | Workflow first, let it surface the skills | "Nine times out of ten the new workflow surfaces what the skill needs to be." |
| Plugins | wbd-core plus one per workflow, not one monolith | Role-scoped recall, per Anthropic guidance |
| Folders | Declared subfolders via the skills array | Real folders, verified working |
| Surfaces | Publish to Claude Code and to claude.ai | Skills do not sync; most users are not in a terminal |
| Governance | Cross-review between owners, no self-merge | Separation of duties |
| Promotion | Sandbox first, promote on traction | Anthropic's own internal model |
| Measurement | PreToolUse hook logging invocations from day one | Nothing else makes adoption visible |
wbd-claude-plugins/
.claude-plugin/marketplace.json one catalog, many plugins
wbd-core/ everyone installs
.claude-plugin/plugin.json
skills/wbd-files/SKILL.md
skills/wbd-brand/SKILL.md
skills/wbd-brand-copy/SKILL.md
skills/wbd-sales-process/SKILL.md
wbd-wf2-pipeline/ MDs and AEs install
.claude-plugin/plugin.json { "skills": ["./skills/diagnosis"] }
skills/diagnosis/spiced-diagnose/SKILL.md
skills/diagnosis/decision-map/SKILL.md
skills/proposal-generation/SKILL.md
agents/deal-inspection.md
wbd-wf1-marketing/ wbd-wf3-q2c/ ...
sandbox/ no review, no promises
Two things to check rather than assume. The Claude Code documentation states that plugin subagents ignore the hooks, mcpServers, and permissionMode frontmatter fields for security reasons; we did not probe this, so confirm it before designing deal-inspection around any of them. And keep agent files flat in agents/ for now: our inventory probe surfaced a flat agent and did not surface a nested one.
The plan treats skills as code. They are prompt artifacts containing our methodology, and for a consultancy the methodology is the product. Three questions need an answer before the first push, and each is one line in the PR checklist.
| Question | Answer |
|---|---|
| Repo visibility | Private. A public marketplace repo publishes our frameworks, ICP, Decision Spine, and Do Not Sell list to competitors. Anthropic documents hosting a marketplace in a private repository for exactly this. Confirm the install path works with the auth our non-engineer staff have before step 1 closes. |
| Client data in skills | Never. Someone will paste a client name, a deal value, or a customer's confidential process into an example. Add a secrets-and-client-data check to the PR gate. Anthropic's review checklist already covers credentials; this extends it to client confidentiality. |
| Offboarding | Bind the GitHub org to SSO with 2FA enforced. Otherwise 40-odd non-technical people authenticate with personal GitHub accounts that sit outside our identity provider, and deprovisioning their Google account removes nothing. Read access to our frameworks, ICP, Decision Spine, and Do Not Sell list would survive their exit indefinitely. Add repo revocation to the HR offboarding runbook. |
Auto-update plus peer review alone would push executable code to every consultant laptop on an hourly poll, approved by one workflow owner whose own next change is reviewed by the person he just approved. Plugins carry hooks, and a hook runs on the endpoint. Split the gate:
CODEOWNERS rule requiring an approver from outside the workflow-owner pool.On the claude.ai path, version drift is a real operational problem: a browser user cannot see a version string, so two people can get different answers on the same deal with no way to tell why. Put a version string inside every SKILL.md and build the zip from the same git tag with a script rather than by hand.
Diagram 2. Contribution and governance. Step 3 is the change from the current plan, which promotes on the author's judgment alone.
Diagram 3. Runtime. The agent brain is in the repo; only the trigger lives in n8n. The scoped write is the only path to HubSpot.
This is the workflow the plan does not have, and the one that decides the outcome. A PreToolUse hook logs skill invocations, which produces a weekly number that is currently invisible.
Counting invocations alone would be a mistake, and our own source says why. Anthropic's warning is that a crowded library makes Claude fire the wrong skill. A misfire logs an invocation, so a greedy description that triggers on everything scores well while a precise one scores low. Counting fires rewards exactly the failure we are trying to avoid. Three numbers, not one:
| Metric | How | What it tells us |
|---|---|---|
| Fired | PreToolUse hook | Raw activity. Meaningless alone. |
| Kept | One keystroke, accept or discard the output | Fired over kept is the misfire detector |
| Shipped | Downstream artifact exists: an SOW file, a CRM field changed, a recap sent | The only one with business meaning |
Two supporting reads: the share of invocations by people who did not author the skill, which is the real test of whether this is a library or a personal toolkit, and the should-not-trigger cases from each evaluation suite promoted into production monitoring, so over-triggering becomes visible instead of rewarded.
Resist the obvious rule of deleting anything that has not fired within two weeks. It contradicts the promotion gate, which admits a skill only after it earns traction, and it punishes the many consulting workflows whose natural rhythm is monthly or quarterly. Instead, every skill declares an expected cadence at publish time and is reviewed against it quarterly. A renewal skill that fires four times a year is healthy. A discovery skill that fires zero times in a quarter is not.
Collection, not just reporting, is the control. Log the skill name, timestamp, surface, and a salted per-install pseudonym. Never log tool input, which on a deal-inspection run would contain client names, deal values, and transcript content. Ninety-day retention, a named owner, and a one-paragraph notice ships in the same release as the hook. Report aggregate and per skill, never per person: the moment invocation becomes a performance metric, people invoke to score and the signal is gone.
Owners are named by role because the plan does not name humans. Filling these in is the first decision the ELT makes.
Step 1 · Week 1
Create the private marketplace repo with wbd-core only. Four knowledge skills, one plugin, one command to install. Do not wait for the other 23. Validate with claude plugin validate before the first push, and confirm the install works against a private repo with the auth non-engineers actually have.
Owner: the author of the Plan of Attack. Roughly 4 to 6 hours. Done when three people outside the author have installed it.
Step 2 · Week 1
Migrate the two remaining Live skills. clay-signal-sync and lead-routing-report. wbd-brand is the one Live skill already carried in step 1. These work today, so moving them proves the pipe with zero authoring risk.
Owner: current author of each. Done when each runs from the installed plugin, not from a laptop.
Step 3 · Week 2
Turn on measurement before turning on governance. Ship the PreToolUse logging hook in wbd-core. Aggregate only.
Owner: repo owner. Done when a weekly invocation count exists for all three Live skills.
Step 4 · Week 2
Publish the same skills to claude.ai org-wide. Organization settings, Skills, upload. Confirm an MD who has never opened a terminal can use one. Leave peer sharing disabled, since there is no approval workflow on it.
Owner: Claude.ai org owner. Done when a non-technical colleague invokes a skill successfully.
Step 5 · Week 2
Ship the org-wide CLAUDE.md through managed settings. The plan's content list is right. Set it at Admin Settings, Claude Code, Managed settings. It polls hourly. Set autoUpdate: true on our marketplace entry and use strictKnownMarketplaces to block sideloading.
Owner: Claude.ai org owner. Note this is a client-side control, not a security boundary.
Step 6 · Weeks 3 to 4
Name an owner and a first use for each workflow. Each owner picks the one skill their workflow needs most, states the MD minutes it removes before it is built, and names the week it first runs. A skill with no named minutes and no scheduled first use does not get built.
At least three of the five must eliminate an admin task rather than generate an analysis. SOW draft, call recap, CRM field population. An MD who is handed another thing to review has been given work, not leverage, and the runtime diagram above ends at exactly that human gate.
Hiten's selection test is the fastest way to run this conversation with each owner. His two questions: "What's a job you'd hand off completely if you could trust it to be done your way? Which step in it is really your opinion rather than something the model could work out alone?" His guidance is that "the good candidates tend to be the things you do over and over where you've got a firm opinion on how they should go." The opinion is the skill. Everything the model could work out alone is not worth writing down.
Owner: ELT. Done when five names, five skills, five minute-estimates, and five dates exist.
Step 7 · Weeks 3 to 6
Build those five, not twenty. Each with a Gotchas section and 3 to 5 evaluation queries covering should-trigger, should-not-trigger, and ambiguous. Anthropic's guidance treats the evaluation suite as a precondition for deployment. The plan has no evaluation step yet.
First run goes against a recorded call from last quarter or a closed-lost post-mortem, never a live client call. Ground truth is known, the client is not watching, and the MD is not testing a v1 in front of Global Payments with their own credibility as collateral. Graduate to live once it holds up.
Concentrate the five into two workflows rather than spreading one across each. Five first-time authors writing one skill each teaches nobody how to write a second.
Owner: each workflow owner. Content reviewed by a different owner; anything executable reviewed from outside the pool.
Step 8 · Week 8
Read the numbers and prune. Fired, kept, shipped, plus MD minutes returned against the before estimates. Delete what nobody keeps. Re-plan from evidence rather than from the annex.
Owner: the CLO. Done when the Planned list is shorter than it is today and at least one workflow can name hours returned.
Reference material behind the recommendations above. Two practitioners plus Anthropic's own published guidance. The Hiten Shah material is primary source, taken from our own recording of his session rather than from a summary of it.
The source is his Skills 101 session, June 5, 2026, four hours including a long rapid-fire Q and A. We have the full recording, so the quotes below are primary rather than secondhand. His weekly library is at hiten.com/library. The recording is available internally.
Three of his answers bear directly on decisions in the plan, and one of them cuts against the instinct most teams start with.
"You don't want everyone in an organization creating skills, but you want everyone in an organization using skills. That's probably the biggest learning that I can give you that I haven't shared too much out there. The consensus is don't make everyone make skills, because then you have a lot of skills spoiled."
"I would make the repo read only for most people and then I would let certain people write to it and improve the skills. It's not for gatekeeping at all whatsoever. It's just for control over the quality of the skill, because the quality of the skill basically 100 percent impacts the quality of the output and thus the quality of the work that your company is doing."
This validates the governance table in the plan almost line for line, and it is worth saying plainly that the plan already got this right. It also sharpens the authorship point in this brief: the constraint is not that too few people are allowed to write, it is that too few people are writing. Open the drafting, keep the publishing narrow. Hiten and the plan agree on the second half; the first half is where the work is.
"I usually like a centralized repo with just skills. I had a centralized repo with skills and knowledge, and then for a bunch of reasons we created two. One had skills that we wanted to share, another had knowledge or content or context."
This is a concrete change to the plan worth considering. Our wbd-core bundles four knowledge skills, one of which is wbd-files at roughly 40,000 tokens by the plan's own estimate. Knowledge that large behaves differently from an action skill: it changes on a different cadence, it is owned by different people, and it is read rather than run. Hiten arrived at two repos after starting with one, which is the cheaper lesson to borrow than to repeat.
"Nine times out of ten the new workflow surfaces what the skill needs to be, versus me attempting to try to make a skill first. When skills were early on, a lot of us would build pretty massive skills. What we've learned is for a single workflow, you don't want a single skill. You usually tend to have multiple skills strung together within one single workflow. That's been the current best practice."
Design the workflow first and let it tell you which skills it needs. That is the opposite of the plan's annex, which names 20 skills before any of their workflows have been run end to end, and it is the strongest argument for building five and learning rather than twenty and guessing. It also independently validates the WF2 shape already in the plan: deal-inspection as one workflow calling three lens skills is exactly the pattern he describes.
Two smaller items worth carrying: he recommends scanning any third-party skill before installing it, including by simply uploading the zip to a chat and asking it to check, and he points at skills.sh and the Anthropic directory as the vetted places to start.
The quotes above on authorship, repo structure, and build order come from the session recording. His public material covers the same thesis and is worth sending to anyone who wants the argument in his own voice:
A caution if anyone goes looking. Third-party summaries of his skill-library post are circulating with a fabricated quote, "Access tells the agent where information lives, skills tell the agent how the company works." He did not write that. His actual line is "Access gets agents into the work. Skills teach them how the work gets done." Quote from the original, not from the summaries.
Separately, Thariq Shihipar at Anthropic published the closest thing to an internal playbook from the vendor side, and his guidance appears in the recommendations above.
Source: claude.com/blog/lessons-from-building-claude-code-how-we-use-skills, June 3, 2026.
One identification first, because several unrelated companies use this name: GrowthX Labs and GrowthX are the same company, growthx.ai, and their Maven course sits at the growthxlabs slug. GrowthX Academy, the GrowthX accelerator, and growthx.club, a large AI community in India, are all different organizations.
Marcel Santilli is CEO and co-founder, previously a marketing leader at Deepgram, Scale AI, ServiceTitan, and HashiCorp. The company is an AI-native content and growth business in San Francisco, venture-backed, with Reddit, Webflow, and Superhuman among its named customers. Their whole business is the thing we are proposing to do internally, which makes the comparison worth taking seriously.
One thing to know before the conversation: the public description of their architecture comes from Daniel Lopes, the CTO, not from Marcel. Marcel speaks to strategy; Daniel speaks to systems. Ask for both.
github.com/growthxai/output is an Apache-licensed Claude Code plugin marketplace containing 49 skills and 5 agents as of August 13, 2026. Install it with /plugin marketplace add growthxai/output and read it. Three things in it are worth copying:
output-dev-* for authoring, output-workflow-* for runtime, output-error-* for failure modes, output-eval-* for evaluation, output-meta-* for pre-flight and post-flight. Our wf2- convention is the same instinct.SessionStart hook force-loads the skill inventory into every session, telling the model "there will be a skill and/or agent for every task you will need to complete." Nobody has to remember what exists. This is a direct, cheap answer to our discovery problem."This format that you have with skills is really good for exploring, really good for things that are one-off, or low stakes, or single user. The moment that you need something that requires a bunch of users, or you need repeatability, can we find something else, or can we mix both worlds."
"You start with skills, and then it sort of works, and then we get that from someone else, and then we compile that into a workflow."
Daniel Lopes, GrowthX CTO, Replay 2026
This maps directly onto our WF2 plan. deal-inspection running after every call, across every MD, producing a forecast, is precisely the multi-user, repeatable case Daniel says a skill is the wrong final home for. Skills are the on-ramp. The durable thing that runs on every deal should end up as a compiled workflow with its own evaluations and traces. Worth an explicit decision rather than an assumption.
Their governance is by convention rather than by document: git and pull requests for visibility, Notion as the human source of truth with a named owner per page, and a hard human approval gate. Their phrasing is "agents draft, you decide," and "nothing advances on your behalf, and nothing publishes itself." That is the same instinct as our Ready for Review guardrail.
A widely repeated summary describes GrowthX as using a "four-file structure of prompts, workflows, activities, and documentation." That is an interviewer's paraphrase and the current repo contradicts it. Do not repeat it. The real structure is three files per workflow folder.
Marcel and Daniel taught a course on this at maven.com/growthxlabs/ai-growth-engine. Given the friendship, a 30-minute call with Daniel on authorship and governance is probably worth more than another round of internal design.
Every URL below returned HTTP 200 on August 13, 2026. Probes were run against Claude Code 2.1.231 the same day.