GitHub Spec Kit for Enterprises: Secure Governance for Presets, Extensions, Bundles and Workflows

The four-layer model​

The post splits customization into four pieces that are easy to blur together:

• Presets change existing behavior. They override templates, commands, prompts and terminology for specs, plans, tasks, checklists and constitutions.
• Extensions add new capabilities, such as a security-review command, an accessibility gate, or a link to an internal work-tracking system.
• Bundles package a curated set of components into one versioned, installable unit.
• Workflows chain commands, prompts, scripts and human checkpoints into repeatable processes. They can branch, loop, and pause for review.

The project's own documentation describes the same split: tune the core with presets, extend it with extensions, orchestrate with workflows, and package it all as bundles. The practical test for choosing a layer is the task. Changing the format of an existing artifact is a preset job. Adding a command or an external integration is an extension job. Provisioning a role-based setup in one operation is a bundle job. Automating a multi-step process is a workflow job.

Presets: priority stacks, with caveats​

The post says teams can stack an organization baseline with domain, technology and project overlays. The documentation backs this up. Presets can supply command, template and script files, and multiple presets can be stacked with priority ordering to layer customizations.

The detail that matters in practice is how files are resolved. Per the preset reference:

1. Project-local overrides win first.
2. Installed presets come next, in priority order.
3. Installed extensions follow.
4. Spec Kit core comes last.

Lower priority numbers win, so a preset at priority 5 beats one at priority 10. Each file is resolved on its own, so one artifact can draw from several layers. The default behavior is replacement. Templates and commands can also be prepended, appended or wrapped, and scripts support replace and wrap.

Commands behave differently from templates, and this is the part that surprises people. Command files are written out for the currently active AI-agent integration. Agents do not re-check the preset stack each time they run a command. Switching the active integration rescaffolds the enabled presets. Disabling a preset also leaves its already-registered commands in place until you remove it. A preset is therefore not a live policy engine. Treat changes to the stack as something to verify, not something to assume.

Extensions: new capability, independent lifecycle​

Extensions can be installed, enabled, disabled, updated and removed on their own. Multiple extensions can coexist in a single project. If two extensions provide a command with the same name, the lower priority number takes precedence. A disabled extension is not loaded and its commands are unavailable. If an extension's command doesn't appear in your coding agent, the docs advise checking specify extension list and restarting the agent.

Bundles: one entry point, with limits​

The post pitches bundles as the way to replace a long list of install steps with one governed entry point. The docs are blunt that bundles add no runtime behavior of their own. They are a distribution and composition layer over the primitives you already use.

Some practical details from the bundle reference:

• Two first-party bundles ship today. bugfix pairs a bug extension with a bugfix workflow for a guided assess, gate, fix and test flow. assess pairs an assess extension with a workflow for triaging ideas before SDD.
• specify bundle info previews the fully expanded component set and pinned versions before you commit to an install.
• Without --refresh, an install skips components that are already present. Components you installed independently are never adopted into bundle ownership. Their installed version must match the manifest pin, or the install stops.
• Version pins are applied at install or refresh time only. Idempotency checks are id-based, not version-aware. Pins therefore don't guarantee reproducible setups unless you re-run bundle update or install --refresh.
• A failed install can leave partial state on disk. Cleanup is best-effort.
• Offline use is limited. Local manifests can install bundled components with --offline, but catalog-discovered bundles need the network today. Step payloads resolve only through step catalogs.

Provenance tracking is real. Still, "pinned and tracked" is not the same as "locked and reproducible everywhere."

Governed catalogs: the security boundary​

The post's two-layer catalog model has an organization catalog that is reviewed and installable, and a community catalog that is for discovery only. The documentation treats this as a security boundary. The built-in official catalog is install-allowed. The community catalog is discovery-only, and the docs explain that it is an open, unvetted list.

For anything you find in the community catalog, the extension docs describe two safe paths:

1. Review one candidate archive yourself, then install it directly with --from.
2. Curate your own catalog, vet it, and mark it install_allowed for organization use.

The docs also warn against flipping a discovery-only catalog to install-allowed, because that would make unreviewed third-party code one command away.

Several other warnings from the docs apply here:

• A project's own catalog configuration under .specify/ can point search and add at sources you did not choose. Before installing from an unfamiliar project, run the catalog list command for bundles, extensions, presets, workflows and steps. A config file existing is not evidence that anything was vetted.
• Bundle submissions need a public repository with a valid manifest and a versioned release artifact. The maintainers' checks cover submission structure and metadata. The docs say they do not audit the behavior of installed code.
• The community overview states that there are 157 community extensions and 33 presets in the project's current listing. That is a large pool of independently maintained code to govern.

Workflows deserve code review​

The post says workflows make checkpoints explicit and do not remove human judgment. The workflow reference goes further. Workflow definitions can contain shell steps, and a shell step runs a local command with your privileges. There is no capability sandbox, and the docs say maintainers do not audit workflow run fields.

Interpolated values are substituted as plain text. Output from an AI agent, which can be influenced by files, tickets or web content, should be treated as untrusted when it reaches a shell step. A gate step does not inspect the command that follows it. Constraining inputs with an allowlist is the strongest control the docs offer, and quoting is not treated as a security boundary.

For a security team, the takeaway is to review workflows as code. Do this before adding them to an organization catalog.

Constitution layering and token tracking: proposals, not features​

The post proposes a layered project constitution: an organization baseline, a domain or technology overlay, and team customizations. It says baseline rules would apply automatically whenever a team drafts a new constitution. It also describes a token-usage extension that collects usage after each run and flags optimization when thresholds are exceeded.

I could not find either capability documented as a built-in Spec Kit feature or a verified shipped extension. The preset documentation does mention constitution synchronization as an option and reconciliation passes after installs and removals. Present the post's layering and token tracking as design patterns an organization could build with these primitives. Don't present them as turnkey governance.

A sensible adoption path​

The post's sequence holds up against the documentation:

1. Set the baseline. Define the organization-level constitution and the controls that apply to every project.
2. Use presets for policy and terminology. Use them to adapt existing templates and commands.
3. Use extensions for new capabilities. Keep each one focused, documented, versioned and testable.
4. Curate an install-allowed catalog. Review ownership, source, permissions, prompts, scripts and update practices.
5. Package proven combinations as bundles. Run bundle info first, and plan for refresh and update.
6. Automate last. Add workflows only once the process, artifacts, checkpoints and exception paths are clear.

I would add a few checks the post doesn't spell out:

• Audit the active catalog stacks in every project, not just the central one.
• Pin the Spec Kit version alongside component pins. Release notes show active changes to exact-release selection for extensions, presets, steps and bundles.
• Test the install path from a clean project.
• Treat preset changes as needing verification in each agent's command directory.

The bottom line​

The post is a vendor-adjacent architecture pitch, but the model it describes matches how the toolkit's own documentation separates the layers. The "keep the core untouched" principle is sound. It also doesn't enforce itself. Catalog policy controls where installs are permitted. It does not verify that code is safe. Expect to staff the review process that makes a governed catalog worth trusting.