Extension Points and Seams

This skill scopes itself by project fit: it answers when a capability warrants a seam and how to build one. It applies to swappable capabilities. A capability with a single fixed implementation and a single consumer is outside its scope — for those a seam is needless indirection, and the honest design choice is to keep it a single unit.

The defining constraint: a seam is the place where a swappable capability lives — the contract, the implementation, and the consumer are separated so they can vary independently. If nothing can plausibly vary, there is no seam to build.

Decide: does this capability warrant a seam?

Build a seam only when at least one of these is true:

• Multiple implementations are real or imminent — a second backend, provider, or adapter is already planned or shipped (local vs remote, mock vs real, one vendor vs another).
• Multiple consumers exist — more than one caller uses the capability, and they must not each couple to one implementation.

If there is one conceivable implementation and one consumer, keep it a single unit. Split only when a second implementation or consumer appears — never preemptively. The seam's whole value is independent variation; without variation there is nothing to buy.

The three roles

A seam has three distinct concerns that change at different rates: