Phase 9: Team Workflows & AI-Native Process · 45 min · Claude Code · GitHub Spec Kit · Python

Spec Governance Across Teams

Two engineers changing the same acceptance criterion differently, in parallel, without knowing about each other, is a real conflict — and silently picking one is worse than surfacing it.

Hiring signal: Treating spec conflicts with the same rigor as code merge conflicts — detecting and surfacing them instead of silently resolving them — shows you understand spec governance as real team infrastructure, not a solo-developer habit that happens to also apply to teams.

What you will learn

Explain who owns a spec at team scale and how spec review functions as the primary code review
Apply the spec-as-source model to a multi-engineer team, not just a solo project
Detect a real conflict when two engineers edit the same acceptance criterion differently in parallel
Explain why uneven drift-gate enforcement across a team undermines the gate's entire value

Introduction

Spec Governance Across Teams

Two engineers, working on separate branches for the same refund feature, both edit the spec's "refund cap" acceptance criterion without knowing the other is doing it. Engineer A changes it to allow a full refund for defective items regardless of the standard cap. Engineer B, working from the same original spec, changes it to add a $500 maximum regardless of order size. Both changes are individually reasonable. Neither engineer knows about the other's edit. If whichever PR merges second simply overwrites the first engineer's version — which is what happens by default with a plain text file and no explicit conflict detection — one engineer's real, deliberate decision silently disappears, and nobody notices until a customer hits the case the vanished criterion was supposed to cover.

Spec ownership at team scale

For a solo engineer, "who owns the spec" has an obvious answer. For a team, it needs an explicit answer per domain or module — a spec owner for the payments area, a different one for the notifications area, not necessarily one person owning every spec in the codebase, but always someone explicitly responsible for a given spec's quality and evolution. Spec review, per c12-09-1, becomes the primary code review activity: a spec change gets the same scrutiny a code diff used to get, checked against the same specificity bar from c12-01-2, by whoever owns that domain.

Spec-as-source means the spec is what the team actually coordinates through
At team scale, the spec-as-source maturity level from c12-01-3 stops being a nice-to-have and becomes load-bearing: if two engineers are relying on their own separate mental models of what a feature is supposed to do instead of a shared, current spec, conflicts like the refund-cap example are inevitable — not because anyone made a mistake, but because there was never one source of truth both were actually working from.

Unlock the full lesson

You've read the first 2 sections. The rest of this lesson covers Detecting real spec conflicts, not silently resolving them, Uniform drift enforcement across the team, What resolving a spec conflict actually looks like, This scales the same discipline, not a new one, Build It — plus a hands-on lab, quiz, and project artifact.

Create a free account to unlock Phase 0 and Phase 1 of every course — no credit card.