Org-wide standardization strategy

No official source exists for this module — stated plainly

Unlike modules 01 and 03, whose success criteria are mechanically verifiable against precise official documentation, no source documents "the" right way to standardize Dev Containers and pre-commit across an entire organization. Neither containers.dev nor pre-commit.com publishes a guide for this exact use case — because the answer structurally depends on factors specific to each organization: number of repos, how much autonomy teams have, appetite for centralized governance, CI/CD tooling already in place.

So this module trains something different from recall: judgment. There's no "correct" answer to find, only traceable reasoning to produce — and the checklist at the end of this module assesses the quality of that reasoning, not conformance to an answer key.

The scenario

On a single repo, you've built a multi-service devcontainer (module 01), decided between prebuilt images and building on demand (module 02), mirrored your pre-commit hooks in CI (module 03), audited your references for pinning risk (module 04), and diagnosed I/O performance (module 05). Your organization now has twenty other repos, each with its own devcontainer.json (or none), its own .pre-commit-config.yaml (or none), written independently, with no consistency between them.

Your VP Engineering asks: how do we standardize this, without forcing every team to rewrite everything by hand, and without creating a central bottleneck nobody wants to maintain?

Available raw material: two mechanisms, two different confidence levels

Dev Container Features — official, documented mechanism

A Feature is a reusable installation module (for example, "install the AWS CLI", "install Node.js at a given version") that a devcontainer.json references by name, with its own version:

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/your-org/features/pre-commit-tooling:1": {}
  }
}

containers.dev precisely documents how a Feature is distributed: it publishes as a tarball artifact to an OCI-compliant registry (GitHub Container Registry, for example), under the <registry>/<namespace>/<id>[:version] convention, versioned with SemVer. Any repo in the organization can then reference the same Feature, at the same version, without duplicating its content.

A homegrown "pre-commit-tooling" Feature could, for example, install pre-commit itself, drop a baseline .pre-commit-config.yaml into the repo if one's missing, and register the Git hook — standardizing the tooling, while leaving each team free to layer their own project-specific hooks on top.

Shared pre-commit config — practitioner approach, not an official pattern

There is no mechanism documented by pre-commit.com for natively sharing a .pre-commit-config.yaml across repos. In practice, teams solving this problem do so through means the tool itself doesn't guarantee: a central repo holding a reference config, synced out to consuming repos by a script or a scheduled CI action; or a repository template (a GitHub repository template) that ships a starting config, copied once at repo creation and diverging afterward. These are reasonable, commonly observed solutions, but none is "the" documented way to do it — treat them as decision material, not a ready-made answer.

Task: write your strategy memo before reading on

Write a strategy memo that explicitly names three things:

1. The chosen mechanism — Dev Container Features, a shared pre-commit config, both combined, or something else you justify yourself. Say why that one over another, for YOUR hypothetical context (twenty repos, autonomous teams).
2. One concrete implementation step — not "we centralize things", but a specific, verifiable action: for example "we publish a pre-commit-tooling:1 Feature to GHCR, and add it to the devcontainer.json of the three most active repos first, to validate before a full rollout."
3. The maintenance trade-off you're explicitly accepting — every standardization effort has a maintenance cost somewhere (who updates the Feature when a new pre-commit rule needs to roll out everywhere? who handles repos that deliberately diverge from the baseline config? what breaks if the OCI registry is down the day a team onboards?). Name that cost, don't leave it unstated.

Don't move on in this module until you have those three things written down.

---

Reasoning-quality checklist, to self-assess

There's no exact match to look for here — compare your memo against these quality criteria, not an answer key:

• Does your chosen mechanism rest on what's actually documented? If you're relying on Features, did you cite the real naming/versioning convention rather than an approximate simplification? If you're relying on a shared config, did you explicitly acknowledge that this isn't an official pre-commit.com pattern?
• Is your implementation step verifiable? "We centralize the config" isn't a step — "we publish X, roll it out to Y repos first, and measure Z" is.
• Did you name a real maintenance trade-off, not a generic one? "It requires maintenance" doesn't count; "the platform team must approve every change to the shared Feature before publishing, which adds latency to any pre-commit rule change" does.
• Did you anticipate the divergence case? A team with a good reason to deviate from the standard config (a legacy repo with different constraints, say) — does your strategy break outright in that case, or does it provide an explicit opt-out mechanism?
• Does your memo clearly separate documented fact (Features, OCI, SemVer) from your own judgment (the choice to lean on a shared pre-commit config, the sync cadence)?

End of track

You've now worked through the six surfaces of a Dev Container + pre-commit setup that goes beyond a single workstation: multi-service architecture, the build decision, the CI mirror, the supply-chain audit, performance, and org-wide standardization. The first five modules had verifiable answers; this one didn't — and that was deliberate. The skill this final module trains, producing defensible reasoning in the absence of an established standard, is probably the one you'll use most often once you're outside a training track.