1,700 skills.
One answer.
One repository, four levels, exactly one skill per capability. The consultant who opens her laptop on Monday never wonders which deck skill is the right one, because there is only one. The librarian did the hard part.
Product capability today — configuration, not construction
We build this. Days to weeks, no new infrastructure
Open item — depends on Q.Eval supporting skill artefacts
Priya, Deb and Raj in chat; Marcus in Claude Code. Three skills do the interviewing — no forms, no YAML, no GitHub account.
Every path terminates in Slack, never at github.com. Harvest by nomination, not by sweep — the 1,400 we don't capture dying quietly is the success metric.
One private repo, four levels, one set of machinery. Personal skills are registered — name, owner, hash, proposed slot — never stored.
Lint and collision are days of work. Whether Q.Eval takes skill artefacts as an evaluation target is the one genuine open item in the proposal.
Already product capability. Distribution, versioning, group scoping and drift prevention — roughly 70% of what we would otherwise have built.
One bundle set, group-targeted once, carried across all three surfaces. Users cannot edit org-managed skills, which kills silent forking at the source.
Four moments, none of which involve GitHub.
Everything a user touches is either Claude or Slack. The machinery in the middle is invisible to every person in these scenes.
Priya has never chosen a skill.
She opens her laptop for the first time and the skills her role needs are already installed and enabled. She took no action, made no choices, read no documentation. There is exactly one presentation skill, one document skill, one client-proposal skill. The question “am I using the right one” does not occur to her, because there is only one.
A skill is wrong. It is fixed by Thursday.
Priya notices the deck skill used last year's client palette. She says so, in chat. Claude captures the skill version and what went wrong, files it, and posts it to #skills-feedback tagged to Deb. Deb replies in Slack. Neither opens a browser tab they didn't already have open.
The best contribution is the one that doesn't happen.
Deb asks Claude to turn a prompt she keeps re-pasting into a skill. Claude interviews her, writes it to the house standard, checks the taxonomy, and tells her the truth: we already have an official board-pack skill; yours does one thing ours doesn't. Want me to propose that as a change to the official one instead?
Nobody applied for anything.
Raj's team has been using their client-reporting skill for two months. Two other teams have independently adopted it. The monthly sweep flags it, Q.Eval runs it against the reporting slot, and a curator confirms. It becomes an org standard. Raj is notified; he remains the owner.
Two surfaces. No third thing to learn.
Priya never installs anything and never picks a skill. Marcus runs one command. Neither of them sees the repository, the CI gates or the marketplace — and neither of them needs to.
I need a readout deck for the Meridian insurance engagement on Thursday.
Using the firm's client-readout skill. I'll pull the house template, flag every figure that needs a source, and leave the commercial slides for pre-send-review.
Installed by your organisation. There is one readout skill, so there was nothing to choose.
The count is not the problem. The duplication is.
Most of these are forks of each other, each carrying one small improvement that never made it back. At current growth this becomes unmanageable within two quarters. The window to standardise cheaply is now, while the volume is still mostly noise.
Users can't tell what's right
Every task starts with an unspoken “am I using the right skill for this?” and there is no answer.
Fixes don't propagate
When a client template changes, it gets fixed in one copy and stays broken in forty.
Nothing is owned
No one can say who maintains a skill, whether it works, or whether it is safe.
The distribution layer already exists.
Roughly 70% of what we would otherwise have built ships in the box.
Organisation plugin marketplaces distribute curated bundles from a private repo that syncs automatically, to everyone or to specific IdP groups, across chat, Cowork and Claude Code. Users cannot edit org-managed skills, which eliminates silent forking at the source. Per-skill usage and cost telemetry is already collected. That is distribution, versioning, auto-update, group scoping, drift prevention and measurement — none of it ours to build.
What is genuinely missing: curation, a quality bar, an ownership model, a contribution path for non-technical staff, and a defect loop. Process problems with a small amount of glue around them.
Don’t buy a registry yet
AWS, Google, JFrog and TrueFoundry all ship one. They are built for multi-vendor agent and MCP sprawl, which we do not have. Revisit when provenance and signing become an AIMS requirement, or when we are genuinely running three or more agent vendors in production.
GitHub is a database, not an interface
If a non-technical person ever has to open github.com, that is a design defect, not a training gap. Everything a user touches is either Claude or Slack.
The tooling is itself four skills
skill-author, donate-my-skill, report-skill-issue and skill-telemetry — distributed by the marketplace they govern. There is no web application to build, log into or maintain.
Four levels, one set of machinery.
Levels differ only by folder and distribution preference. One linter, one eval harness, one telemetry join. The complexity is in the rules, not the machinery.
How Quantium does this
How this team does this
Someone found this useful
Mine
Thresholds trigger evaluation, not promotion.
Usage measures popularity, not correctness. A widely used skill producing subtly wrong output is worse than an unused one. The sweep nominates, Q.Eval decides, a curator confirms. Demotion is the row nobody builds and everyone needs.
Three gates, all blocking.
Structural lint
Frontmatter, kebab-case name within 64 characters, description within 200, CODEOWNERS entry, version bumped. Mechanical, seconds. It matters more than it sounds: an increasing share of skills are written by agents, and structural checks are exactly what neither the contributing agent nor the reviewing human reliably catches.
Collision & sub-slot
Org level takes exactly one skill per capability slot. Team and community may claim a sub-slot only — not deck but insurance-client-deck. This is what makes four levels safe: without it, selection between an org and a team skill becomes a coin flip, rebuilding the original problem inside a single session.
Behavioural evaluation
Trigger accuracy — does it fire when it should and stay quiet when it shouldn't? The description is the routing table, and this is how we test it. Plus output quality against owner-supplied fixtures. Eval also depoliticises contested slots: two teams both certain theirs is right run against the same set.
I believe the internal tool here is Q.Eval, listed under Enabler C.1. This needs confirming, along with whether it supports skill artefacts as an evaluation target or needs an adapter. If the latter, that adapter is the only meaningful software build in this proposal.
Eleven weeks. Three phases.
No new infrastructure, and nothing that waits on the vendor roadmap. Telemetry arrives with the contribution loop rather than after it, because the underlying data is already being collected.
Foundations
Tenancy prerequisites enabled. The capability taxonomy and sub-slot naming convention written — one page. Harvest by nomination, not by sweep.
Taxonomy agreed. Candidate list under 100.
Day one works
Repo live. The twelve launch slots filled. Required bundles mapped to IdP groups. Structural lint and the collision check blocking in CI.
A new starter is productive with zero setup.
Contribution, feedback and the gate
The four skills shipped. Community and team levels open. Personal registration live. Owner digest and the monthly sweep running. Q.Eval wired in as a blocking gate.
First defect resolved without anyone opening GitHub. First promotion decided on evidence.
Five decisions.
- Endorse the approach: curate and govern, do not build distribution infrastructure.
- Approve the four-level model with personal registered rather than stored, and evidence-driven escalation including demotion.
- Confirm Q.Eval as the quality gate and fund any adapter work in Phase 3.
- Approve federated (publisher) ownership rather than centralised ownership.
- Nominate the taxonomy authors — the one piece that is genuinely intellectual work and cannot be delegated to tooling.