Recommend plugins for an organization

Some plugins are useful enough, or important enough for consistency, that you want everyone to have them rather than hoping word of mouth carries them. Recommending plugins at the organization level lets an administrator push a curated set to the whole fleet, so a new developer starts with the right tools already suggested and a standardized workflow is the default rather than something each person has to assemble.

Recommend versus require

There are two strengths of central endorsement. A recommendation surfaces a plugin prominently and makes it a single click to install, but leaves the choice with the developer, which suits tools that help most people without being mandatory. A requirement installs and enables a plugin for everyone and does not offer a way to skip it, which suits plugins that enforce policy, such as one that applies a security check or a house style. Choose the lighter touch by default and reserve requirements for cases where consistency genuinely matters.

Pushing a recommended set

Define the recommended and required plugins in a managed configuration that Syntic Code applies across the fleet, pinning versions so everyone gets the same release:

{
  "recommendedPlugins": ["issue-linker@2.3.1", "changelog-helper@1.4.0"],
  "requiredPlugins": ["security-scanner@3.0.2"]
}

Distribute this through the same server-managed settings mechanism as your other central policy so it arrives automatically and cannot be quietly removed.

Curating the list over time

Keep the organization list small and high-value; a long list of recommendations reads as noise and gets ignored. Use adoption analytics and CLI recommendations to decide what belongs: a plugin that spreads widely on its own is a strong candidate to promote, while one nobody adopts should be dropped. Review the list on a regular cadence, retire plugins that are no longer maintained, and treat changes to it as reviewed configuration so the fleet’s standard toolkit evolves deliberately.