- In short
- Choosing a Skill distribution mechanism means matching a scenario to org-provisioned, plugin, project Skill, or API Skill by weighing three factors: audience scope, governance needs (versioning, rollback, group targeting), and whether the consumer is a human team member or another product. Org-wide with no governance need points to an org-provisioned Skill; a must-be-identical, centrally revocable procedure across specific departments points to a plugin; a single-repository convention points to a project Skill; a capability called by partner products points to an API Skill.
The decision is a match on three factors, not on audience size alone
Once you know the four distribution mechanisms and what governance a plugin adds, the Claude Certified Architect - Professional (CCAR-P) exam asks you to analyse a scenario and pick the right one. This is the analyse-level payoff of the two knowledge points before it. The trap the exam sets is picking on a single dimension - usually audience size - while ignoring a stated need for governance or a detail about who actually consumes the capability.
The reliable method weighs three factors together: how wide the audience is, what governance the situation demands (versioning, rollback, group targeting), and whether the consumer is a human team member or another product calling it in code. Any one of these can be decisive, so you read the scenario for all three before committing.
- Choosing a Skill distribution mechanism
- Selecting org-provisioned, plugin, project Skill, or API Skill for a described scenario by weighing audience scope, governance needs (versioning, rollback, group targeting), and whether the consumer is a human or another product. The decision follows the binding constraint, not audience size alone.
The four canonical matches
Org-wide, no governance need, to an organization-provisioned Skill. When a capability genuinely should reach every member and the scenario states no need for versioning, rollback, or group targeting, the simplest correct answer is an org-provisioned Skill. It reaches everyone at once with the least machinery.
Must-be-identical and centrally revocable across specific departments, to a plugin. When a procedure has to run identically across several named groups and be updatable and revocable from one place, only a plugin provides the group targeting, version-controlled updates, and rollback that requirement demands. Audience width does not decide this - the governance requirement does.
Single-repository convention or tool set, to a Claude Code project Skill. When the capability is a coding convention or tool set that belongs to one codebase and should version with it, the project Skill in .claude/skills/ is the natural home. It is scoped to the repository and travels with it.
Called by partner products, to an API Skill. When the consumer is not a human in a chat interface but another product invoking the capability programmatically, the API Skill is the only fit. The consumer type, not the audience size, is the deciding factor here.
What the CCAR-P exam trips candidates on
Two traps recur. The first is picking a mechanism that matches on audience size while ignoring a stated governance need. A scenario might describe a capability used by a large group and tempt you toward org-provisioning because it is broad, when the scenario also says the procedure must be centrally revocable - which org-provisioning does not provide and a plugin does. Read the whole requirement before matching.
The second is choosing a project Skill for a capability that must be identical and centrally revocable across several departments. A project Skill versions with one repository and is scoped to it; it cannot enforce an identical, revocable procedure across four departments. When those governance words appear alongside multiple groups, the answer is a plugin, not a project Skill.
Worked example
An Architect faces four requests: (A) a compliance-review procedure every one of four departments must run identically, centrally updatable and roll-back-able; (B) a capability that genuinely should reach every member with no versioning need; (C) a coding convention the engineering team should share on every project; (D) a reusable capability several of the partner's own products must call in code. Which mechanism fits each, and what makes it the deciding factor?
A is the governance case. The words that decide it are "identically," "centrally updatable," and "roll-back-able," across specific departments. Only a plugin provides group targeting, version-controlled updates, and rollback together, so A is a plugin distributed to those departments. The audience being four departments is not what decides it - the revocability and versioning requirement is.
B is the pure-breadth case. It should reach every member and explicitly needs no versioning or rollback, so the simplest correct mechanism is an organization-provisioned Skill. Reaching for a plugin here would add governance machinery the scenario says is unnecessary.
C is the repository case. A coding convention shared on every project the engineering team works in belongs in the codebase and should version with it, which is exactly a Claude Code project Skill in .claude/skills/. The deciding factor is that it is a convention tied to repositories, not an org-wide capability.
D is the consumer-type case. The consumers are the partner's own products calling the capability programmatically, not humans in a chat interface, so it is an API Skill. Audience size is irrelevant here; the fact that a product invokes it in code is the whole decision.
The pattern across all four: identify the binding constraint - governance, breadth, repository scope, or programmatic consumer - and let that constraint pick the mechanism. A right mechanism chosen for the wrong reason is exactly the mistake the exam is built to catch.
Common misreadings to avoid
Misconception
Pick the distribution mechanism based on how many people need the Skill.
What's actually true
Misconception
A project Skill works fine for a procedure that must be identical and revocable across four departments.
What's actually true
How this shows up on the exam
Domain 7 questions on this knowledge point present a scenario and a set of mechanism options, sometimes requiring you to also name the deciding factor. The reliable method is to find the binding constraint - breadth, governance, repository scope, or programmatic consumer - and match it: org-provisioned for broad-and-ungoverned, plugin for identical-and-revocable-across-groups, project Skill for single-repository conventions, API Skill for product consumers.
This knowledge point is the synthesis of the two before it: skills distribution mechanisms gives you the four options, and plugin governance for shared assets tells you what makes a plugin the answer when governance is at stake. Together they turn a memorized list into a decision you can defend.
A compliance-review procedure must be run identically by four departments and be revocable from one place. How should it be distributed?
People also ask
How do I choose a Skill distribution mechanism for a scenario?
When should I use a plugin instead of an org-provisioned Skill?
When do I use an API Skill?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.