Governance that raises quality without blocking creativity
The buttons are simple; the judgment is the hard part. This page explains the publishing lifecycle, what each toggle actually does, and a starting configuration that works for most teams.
1The governing idea
Restricting skill authorship is a trap. Lock creation down and the skills get worse (the people closest to the work stop contributing) while a shadow library grows in gists and chat threads. Governance here works by a different mechanism: the registry wins by being the easiest good starting point.
- Base skills live in the registry: reviewed, owned, current.
- Personal variants belong to individuals: anyone extends a base skill with their own tone and workflow, with no review and no friction.
- Review applies at the moment of sharing, not the moment of creation. Ownership and approval attach when a skill becomes something colleagues rely on.
2The publishing lifecycle
Draft → Pending review → PublishedTwo flows feed the review queue:
- Creation:a new skill wants to publish. Approval publishes it; rejection leaves it in Draft with the reviewer's note.
- Modification: a published skill has a new version. The new version is held while the current one stays live, so review never breaks an installed skill. Approval promotes the held version.
Every request, approved or rejected, becomes a permanent audit record: who created, who reviewed, what was decided, when, and with what note. The trail can reconstruct the full lifecycle of any skill in the registry.
3The five settings
All on the Governance page, all effective immediately, none retroactive.
| Setting | ON means |
|---|---|
| Require approval for new skills | Members' new org skills queue for review before publishing (Org Admins always publish directly) |
| Require approval for modifications | New versions are held for review; the live version keeps serving installs |
| Member approvals allowed | Any member may review requests (never their own); otherwise only Org Admins and the skill's Department Admins review |
| Cross-department sharing | Department-scoped skills become visible org-wide |
| Cross-team sharing | Team-scoped skills become visible org-wide |
Reviewer authority follows the skill: a Department Admin reviews requests for skills scoped to their department; Org Admins review anything. The sharing toggles are deliberately org-wide: "Team A wants to share one skill with Team B" is better solved by republishing that skill at Department or Organization visibility than by opening every team's library to everyone.
4A starting configuration
For a team new to shared skill governance, this posture works: approve at the front door, stay out of the workshop.
| Setting | Start | Why |
|---|---|---|
| Approval for new skills | ON | The registry's credibility is set by its first months; a light review keeps "base skill" meaning something |
| Approval for modifications | OFF | Owners iterating on their own published skills should be frictionless; the held-version mechanism makes turning it on later low-risk |
| Member approvals | OFF | Let standards form consistently with admins reviewing; delegate once volume justifies it |
| Cross-department sharing | OFF | Sharing should be an explicit act; scoping is the point |
| Cross-team sharing | OFF | Same reasoning |
| Install policy | Open | Restriction before evidence of a problem is friction without benefit; blocklist a specific problem if one appears |
5Reviewing well
Review answers one question: can colleagues rely on this? A checklist that keeps it honest:
- Does it work? Run it once against a realistic case if in doubt.
- Is it findable? Name and description should match what a colleague would search six months from now.
- Is it scoped right? Team-specific content should not publish at Organization visibility, and vice versa.
- Does it duplicate? Prefer a new version or a variant of an existing skill over a second near-identical one.
- Is ownership right? The author should be the person who will actually maintain it.
Rejections must carry an actionable note ("needs a security section", not "no"). The note is permanent in the audit trail, which keeps review culture honest in both directions. And agree a review-latency expectation with your admins; a queue that sits kills contribution faster than any restriction would.
6The install policy
Separate from skill review: the install policy governs which public catalogskills members can install inside the organization. Open allows everything, Allowlist permits only listed skills, Blocklist permits everything except listed skills. The organization's own skills are always installable, and a blocked install tells the member which policy blocked it and who to ask.
7Keeping it healthy
Revisit the toggles quarterly against two numbers on the Analytics page: skills published per month (creativity) and installs per member (reliance). Governance is healthy when both rise together. If publishing stalls, loosen the front door; if trust complaints appear, tighten review or delegate more reviewers.