Prompting Mechanics / Part III / §20
Section 20 of 45 2 min read

Packaging and Distribution

The distribution problem, what goes in a bundle, versioning and rollout, and what an enterprise sets centrally.

Objective

Cover how configuration moves from one developer’s machine to an organization, and what changes when it does.

20.1 The Distribution Problem #

Everything in Sections 14 through 19 amounts to a file, and files in one repository help exactly one team. The question at organizational scale is how a good instruction file, a validated skill, a vetted MCP configuration, and an enforcement hook reach two hundred repositories without two hundred manual copies.

Three mechanisms exist, each carrying different trade-offs:

MechanismPropagationDriftBest for
Copy into each repositoryManualImmediate and permanentRepository-specific rules
Template repositoryOn creation onlyImmediate after creationBootstrapping
Plugin / packageOn updateControlled by version pinShared standards

The third is what every major surface has converged upon: a versioned bundle containing skills, commands, hooks, subagent definitions, and MCP configuration, installable as a unit and updatable as a unit.

20.2 What Goes in a Bundle #

company-standards/
  plugin.json               # name, version, what it contains
  skills/
    add-a-migration/SKILL.md
    release-a-service/SKILL.md
    security-review/SKILL.md
  agents/
    dependency-auditor.md
  hooks/
    pre-tool-use.sh
    post-write.sh
  mcp/
    servers.json            # vetted servers, pinned versions
  instructions/
    base.md                 # the org-wide always-on rules

The organizing principle is this: shared standards go in the bundle, repository-specific rules stay in the repository. A migration procedure that is identical across forty services belongs in the bundle. A rule about one service’s unusual deployment belongs in that service’s AGENTS.md.

20.3 Versioning and Rollout #

The failure mode here is the same as with any other dependency: a bundle that auto-updates is a standing grant to change every developer’s agent behavior without review.

{
  "plugins": {
    "company-standards": {
      "source": "github:acme/agent-standards",
      "version": "2.4.1",
      "autoUpdate": false
    }
  }
}

Pin the version and roll forward deliberately. Treat a bundle version bump as a change requiring the same evaluation as a prompt change, which is to say, run it against your eval set (Section 34) before it reaches everyone.

20.4 What Enterprises Set Centrally #

Configure these controls once at the organization level rather than negotiating them per repository:

  • Allowed model list. Which models may be used, by which teams.
  • MCP server allowlist. Which servers may be connected at all.
  • Mandatory hooks. Enforcement that repository-level configuration cannot disable.
  • Instruction file inheritance. An organization-level base that every repository inherits.
  • Spend limits. Per developer, per team, per session.

The last of these deserves a note. Uniform caps are the most common response to a cost surprise and the most economically wrong one: they cut the highest-value spend first because the highest-value spend tends to be concentrated in the teams doing the hardest work. Section 25.5 develops the alternative.

PDF↓