Governing customizations

Why it matters

One member’s skill can become everyone’s workflow, reviewed or not. An architect decides how far a customization may spread before anyone checks it.

What to practise

Work through the three governance questions: what a customization may do when it runs, who can create and use it, and how it reaches everyone else. Separate the four distribution controls — Owner provisioning, direct skill sharing, sharing with groups, and Publishing set to Off, Requires review or Open — and note that skills only run with code execution turned on. Follow one skill through the build, review and publish loop under two postures: open building with reviewed spread beyond the group, and approve-first. Notice that tightening Publishing later removes nothing already published.

How it fits

This is 7.1.4’s distribution decision on the claude.ai side: a review gate before broad spread, bounded by group, and checked on the surface members actually use. Compare it with the Claude Code routes 7.1.4 covers, where a plugin’s source is what you review. The rule that some settings apply organization-wide rather than per group echoes 7.1.2’s question of which scope enforces a policy.