packkit

I have been writing project scaffolders for most of my career. At Dealer.com I built the SPA generators that let a team stand up a new app in minutes instead of a week of copy-paste. packkit is the same idea, rebuilt for a moment when the thing running the generator is as likely to be an AI agent as a person. The tagline is "provider-neutral project scaffolding — CLI, MCP, and a web configurator," and every word of it is a design decision.

The mission has not changed, the caller has

A scaffolder encodes a team's opinions once so nobody has to re-derive them. That was true in 2015 and it is true now. What changed is who asks. Today the request often starts inside an agent loop: "spin up a Go service with a TypeScript front end and wire them together." If the only way to do that is an interactive terminal prompt, the agent has to fake keystrokes or give up. packkit was designed so the same generator answers a human at a shell, an agent over MCP, and a person clicking through a web page.

One core, three surfaces

The whole architecture is one sentence: a single generator core, exposed through three thin surfaces.

• The core owns the templates and presets for modern JavaScript/TypeScript, Python, and Go projects, plus the composition logic that assembles a fullstack app out of those pieces. It takes a fully specified configuration and produces a project on disk. It asks no questions. It does not know what a terminal is.
• The CLI (create-packkit, run as npx create-packkit) is the human surface. It collects the configuration interactively or from arguments, then hands the core a complete spec.
• The MCP server exposes every generator in the core as an agent tool, with an input schema derived from the generator's own options. An agent connects, lists the tools, and scaffolds a project by calling one. No shell emulation, no parsing of prompt text.
• The web configurator (packkit-web, hosted on Cloudflare at packkit.danmat.dev) is the browsing surface. Pick a language, a preset, and options; it hands you the exact command. It reads the same option metadata as the other two surfaces, so it cannot drift from what the CLI accepts.

The discipline that makes this work is boring and non-negotiable: surfaces gather intent, the core does the work. The moment a surface makes a generation decision of its own, you have three products that slowly disagree with each other.

Why the MCP surface is the point

The CLI and the web page are table stakes; Yeoman had a CLI a decade ago. The MCP server is what makes packkit belong to this era. Because every generator is registered from the same option metadata, adding a preset to the core means an agent can use it as soon as the server restarts, with no separate tool definition to keep in sync. The agent sees the same options a human sees, described the same way. That symmetry is the feature.

It also changes what "scaffolding" means. A human runs a generator once per project. An agent can run it as one step in a longer plan: generate the service, generate the client, compose them, keep working inside the result. packkit is a building block for that, not a destination.

Provider-neutral, deliberately

"Provider-neutral" is a stance about output. Generated projects do not assume a particular host, cloud, or vendor SDK; where a preset needs a deployment target, the caller chooses it. I run the configurator on Cloudflare because that is what I use, but nothing in a generated Go service or Python API knows or cares.

Dogfooding

This portfolio embeds a native packkit configurator on packkit's own page, driven by the same option metadata as packkit.danmat.dev. If the embedded widget and the CLI ever disagree about what a preset accepts, that is a core bug, and I will see it here first.

What I would tell my Dealer.com self

Build the core with no user interface at all, then bolt on as many as you need. I half-knew that then. Now one of the interfaces is a machine that reads schemas, and designing for it first makes every other surface cleaner.