scaffold-thinking is open source

The thinking layer in Scaffold — Frame, Clarify, Diverge, Decide — is now a standalone open source package. You can install it, fork it, and use it without building a web app.

The decision to extract it was easy to justify but took a while to make. The harder question was what to actually ship.

What's in the app vs. what's in the package

Scaffold the web app has things that belong to it: the Supabase instance, the Drizzle schema, the auth flow, the regeneration history UI, the project-level storage. None of that has value outside the app. It's infrastructure.

The thinking layer is different. The four stage functions — clarify, diverge, decide and the Frame input that drives them — don't depend on any of that. They take a problem description and a model provider, run a prompt, and return structured data. The extraction was clean because the separation was already clean.

What went into the package: the prompt construction, the JSON schemas that enforce output structure, the four stage functions as TypeScript with proper types, a CLI that walks through all four stages interactively, and two provider implementations (Anthropic and OpenAI) behind a simple interface you can implement yourself.

What stayed private: everything that makes it a web app.

Two distribution modes, one reason

The package ships two things that look redundant but aren't.

First: the npm package itself. You can npm install scaffold-thinking and call clarify(input, provider) from TypeScript. This is for people building tools — a CI step that generates a decision brief before a deployment, a script that runs a problem through the pipeline and writes the output to a file, an internal AI assistant that wraps this as a workflow.

Second: prompts-md/. Three plain Markdown files — one per stage — with {{PLACEHOLDER}} notation and the JSON schemas embedded. No code. Copy them into a CLAUDE.md, a .cursorrules, a Cursor custom instruction block. The model running in your editor gets the same prompt architecture without any npm dependency.

The reason both exist is that they serve different workflows. If you're writing code that calls a model, you want the npm package. If you're a human working in an AI-native editor, you want the prompts injected into your context — not a package.json dependency. An engineer who does most of their work in Claude Code or Cursor doesn't need to import { clarify } from anywhere. They need the structure available to their model, which means they need it in the files their model reads.

That's a real difference, not just a packaging choice. The model that generates your options is the same one in both cases. What changes is how the forcing functions reach it.

Why this follows from the thesis

The original Scaffold post ended with this: the model is a commodity. The intake is the product.

If that's true, then the prompts and the schemas and the forcing functions are the thing with value — not the deployment, not the UI, not the database schema. Those belong open. Anyone building with AI should be able to use the same intake structure. Anyone who disagrees with how the Diverge stage works can fork it and change it, which is more useful than a feature request.

The web app can keep the parts that are genuinely app-specific. The thinking layer is not app-specific. It's a structure for a conversation between a human and a model, and that conversation can happen anywhere.

What I cut from the first version

The initial extraction had a fourth distribution mode I dropped: a shareable link that would let you send someone a specific stage prompt pre-filled with your problem. The idea was that you could fill in the Frame fields in the web app and hand the resulting Clarify prompt to a colleague who uses a different tool.

I cut it because it added surface area without adding clarity about the package's scope. The package is a thinking layer, not a collaboration product. Scaffold the app handles collaboration. The package handles the pipeline.

The bet on prompts-md/

I'm more confident about the npm path than the prompts-md/ path. The npm case is simple: if you're building an AI tool and you want structured divergence in your pipeline, you install the package.

The prompts-md/ bet is that engineers who work in AI-native editors will make better decisions if they have a structured intake rather than just describing their problem ad hoc. I think this is true — the original Scaffold post argues it, and my experience building the tool is consistent with it. But the adoption pattern is different. Nobody installs a CLAUDE.md snippet the way they install a package. You paste it in, or you don't.

The test will be whether the structure in prompts-md/ is tight enough to be worth the copy-paste. If the prompts are good, they'll spread. If they're not good enough to be worth pasting into your config, no amount of documentation will fix that.

The package is on GitHub. The README has the install instructions, the CLI walkthrough, and the provider docs. The prompts-md/ directory is in the repo root.