The Container Problem

WHY

We had years of development threads, online and offline, containing real thinking about real tools — but no reliable way to surface what was worth showing, or to produce something publishable without a full day's writing effort.

WHAT IT IS

A structured prompt dropped into any development thread — Claude conversation, notes, working document — that extracts an artifact-first piece in a fixed format: why the thing was built, what it is, one design decision, one observation. The output is a draft, not a finished piece. The editing is the work. Total time from thread to publishable: thirty minutes if the thread is rich enough.

DESIGN DECISION

The format was designed around a specific failure mode: without a defined container, nothing is clearly showable. Every development thread contains potentially interesting material but no obvious signal for what deserves attention. The container — four fixed sections, each with a specific job — does the editorial work that judgment alone couldn't do consistently. The sections aren't arbitrary: Why separates motivation from description. Design Decision names the thing that's invisible in the finished artifact. One Observation stops before the general principle. Each constraint exists because the output drifted toward something wrong without it.

ONE OBSERVATION

The first outputs were too stiff — accurate but written in a register nobody would choose to read. The fix wasn't better instructions about quality. It was specific counter-instructions about what not to do: don't write like a case study, don't state the general principle, stop at the finding. The prompt works less by directing toward the right output and more by blocking the default wrong ones. Claude's default register — complete, resolved, slightly formal — is the opposite of what the format needs. Every instruction in the current prompt exists because the output went wrong in that specific direction first.

Built: April 2026